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