Skip to content

Failing At Microservices

Take note all things things are bad things, do the opposite if you want to implement microservices correctly

10. Go Full Scale Polyglot#

  • Different tech stacks with different programming languages (react, angular, elixir, postgres, mongo, hapi, spring boot)
  • Exciting cause you can’t transfer knowledge between the stacks - new tools, new build environments
  • groundhog code - common solutions delivered in every new tech stack
  • Give everyone a puzzle
  • Polyglot JS UI frameworks in beta status
  • Keep ops on their toes delivers logs in different formats

9. Data Monolith#

  • One huge data store shared amongst everything
  • No permissions - share everything
  • All microservices share the database

8. Event Monolith#

Time series and publishing of events. Other microservices subscribe to that “topic” and get informed of that event.

  • Don’t change messy past events
  • Don’t plan Data fields beforehand
  • Copy and paste solutions around

7. Home Grown Monolith (Build your own framework)#

a.k.a pure PHP

  • Using a homemade framework tool
  • Forces a monolithic release plan
  • Job insurance - build framework

6. Think of the Meat Cloud#

Optimise your revenue:

  • Who Want the work done?
  • Who Knows how to do the work?
  • Who has the required Privileges?
  • Who has the Time to do the work?

4 people, 4 x the day rate + program manager

  • Infrastrcuture is expensive be proud to take care of it (by hand)
  • Avoid openshift and automation
  • Microsoft work macros

5. The Distributed Monolith#

Combine the complexity of a microservice architecture with the rigidity and fragility of a monolith

  • Assume the network is reliable
  • Dependencies indicate good design - be proud of dependency injection
  • Synchronous dependencies are easy

4. The SPA monolith#

Giant monster UI that calls these micro services

  • Single point of failure
  • Keep the testers busy
  • Avoid self container microservices with their own UI like tailorJS
  • Avoid hyperlinks

3. The decision monolith#

Sieve of sanity

  • Frustrate our coworkers
  • Irritate motivated colleagues
  • Older than 30 - Say “This is real complex enterprise kid”
  • Ivory towers are beautiful
  • Assume people are dumb and you are smart

2. The monolithic Business#

Requirements pingpong

  • One person says we must only allow valid addresses
  • Other person says we must be lenient and allow partial addresses

  • Slow means more time for twitter

  • Servant of many kings is a free man

1. Use a HR driven architecture#

It is far easier to find React developers than to find general craft women

Have seperate siloed teams that enver speak to eachother Business or IT Analyst writes the specification document

  • Avoid spread of knowledge
  • We are proper complex enterprise people - frontend are just pencil pushers
  • Business knows the domain, devs know tech
  • Nobody should have a big picture