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