Monolith vs. Microservice

As any developer who's worked on a large, monolithic system will know; they can be pretty ugly beasts. They aren't fans of being scaled, they chew up your code and make it look like spaghetti, and when you come to test and deploy a single, simple change you have to step back and treat the whole thing as one, monstrous unit.

Complex, interconnected webs of tightly-coupled classes and functions sitting on sets of mega-servers. Product Owners screaming for changes. SysOps crying into their dashboards. It's not a fun world.

Now, I'm not saying that monoliths are evil; far from it. In fact from my own bitter experience I know that new software projects tend to survive by using the counter-intuitive Monolith First pattern. As an enterprise grows, applications are more heavily utilised, and more and more features are added by ever expanding dev teams, complexity and cost of change begin to escalate rapidly. There is a balance to strike here. A trade-off between flexibility and simplicity, a function of base complexity and the chosen architecture. It's only after the base system complexity reaches a certain critical mass that development productivity on microservices overtakes that of the monolith (The Microservice Premium).

Large, complex projects can leverage cross-functional project teams to work on single service applications with well-defined boundaries, following the "you build it, you run it" mantra. These domain teams have total control and accountability for the specification and delivery of the service. The reduced reliance on other teams and the replacement of traditional integrations with well-structured API contracts can rapidly decrease delivery time and risk.

Microservice Architecture is most certainly not a silver bullet. It doesn't remove integration problems, it changes it. It doesn't decrease complexity, it increases it. The decision to use microservices should be made consciously, as an organisation, and with full access to the facts (and other teams' experiences). It requires a reasonably high degree of enterprise technology maturity that many organisations simply do not yet possess.


#microservices #monolith #architecture

  • Twitter
  • LinkedIn

©2018 Elegant Development - An AWS Consultancy