I recently watched this brilliant, snarky, cynical and humorous video of a session presented by David Schmitz in 2017 about how undermine a micro-services approach. He does such a great job promoting the anti-patterns that I had to continually remind myself that he was cleverly telling us what not to do.
Here are his approaches listed in reverse order of impact (i.e. #1 is the most nuclear)
(NB: these are David Schmitz’ original ideas, I am just summarizing)
10. Go all-in on the polyglot approach. We want as many stacks (languages, libraries, programming paradigms) as possible to maximize entropy and keep everyone on her toes, especially op’s, with whom he continually reminds us to never talk to.
9. Embrace the Data Monolith. All micro-services should share the same database, tables and schemas. This maximizes tight binding and incites arguments over field types, table names, etc. Oh and when you make a schema change for your service, be sure to not communicate that to any other impacted team.
8. Embrace the Eventing Monolith. In a similar vein this maximizes binding among the event subscribers b/c when you change an event’s name or semantics every dependent service must accommodate that change typically by copy-pasting a hack into each service. Here he promotes the concept of WET (We Enjoy Typing) as the successor to DRY (Don’t Repeat Yourself)
7. You should always build bespoke Frameworks because there’s really nothing out there good enough to fit your unique situation. Start by writing your own collections framework (because the one provided in Java isn’t good enough). While you’re at it, build your own message queue and operating system. These are all very fun for developers and deliver no business value.
6. Apply a consultative approach to maximize revenue (of the consultants). Divide the team into four units: one who WANTS it done, one who KNOWS how to do it, one who has the PRIVILEGES to do it, and one who has the TIME to actually do it. Throw in a Project Manager and you can now bill 5X the hourly rate. Make sure no code gets written.
5. Embrace the Distributed Monolith paradigm. This is simply achieved by maximizing the dependencies that the micro-services have on one another. As he says, this approach gives you the “complexity of a micro-service architecture with the rigidity and fragility of a monolith”. It really doesn’t get any better than this.
4.SPA (Single Page Architecture) is a great way to increase productivity and impress your bosses. Simply throw random business logic into the UI layer where it’s easier to change vs. in the micro-services that actually are responsible for implementing that business logic. Your managers will love you for efficiency improvement.
3.The Decision Monolith promotes making arbitrary decisions based on nonsense (e.g. chasing the newest shiny thing, doing things the old way). He reminds us that Ivory Towers are actually beautiful (“Have you ever seen one?”). This approach will lead to frustrated and de-motivated colleagues. Perfect for decreasing morale and dampening innovate thinking.
2. The Business Monolith encourages management to get involved in technical and design decisions. The managers must also engage in “requirements ping-pong” (aka design by committee). This will ultimately result in a Waterfall approach which, due to its blocking and serial nature gives the developers lots of time to catch up on social media.
1.Use an HR-driven Architecture. This means making location decisions for the various teams (e.g. data scientists, UI designers, testers, ops) that will minimize the timely flow of information across the teams and insure that no one has a clarity of the big picture.
In conclusion, you should embrace the monolithic approach in all aspects of software development. And forget about micro-services entirely — they’re just a fad. “Wait for SOAP 4.0"
