Implementing a scalable, microservices architecture without all the hype

One of the most illuminating takeaways from the talk for those who are new to microservices was the compare and contrast section about different types of architecture. Heckler covered these in detail so that listeners could easily grasp the pros and cons.

First on the chopping block was the cumbersome monolith. Its key features include having a single, logical executable with shared data across functionality and a non-granular structure. The drawbacks are many. This type of system is difficult to scale, any failure means complete failure, control flow change is not possible, it is attached to a specific language and platform, and has high coupling with low cohesion.

The days of the monolith are necessarily numbered. A system that may have worked fine internally for a few hundred users simply isn’t designed to work well for hundreds of thousands of geographically dispersed users. In short, what might appear simple is never really easy to deal with. “The idea of a small, self-contained monolith is a romantic concept. It doesn’t stay that way even if it starts that way.”

According to Mark, the microservices model has a lot more to it than meets the eye. Words like flexible, scalable, and speedy are often used to describe this architecture. But the features that make these benefits possible are more specific. Microservices can be independently deployed and executed. They support non-disruptive change, are polyglot-friendly, serve to isolate failures, make control flow changes easier, have high-cohesion and low coupling, and are known for being easy to scale. In addition, they have a manageable mental model that is, or should be, simpler for programmers to grasp. Quite simply, they allow organizations to be more Agile.

Microservices are not SOA

In contrast to microservices, SOA is neither agile nor speedy, as was proven during the enterprise service bus heyday. This architecture features macroservices, SOAP + XML, dumb endpoints with smart pipes, and is highly coupled. “In a way, it’s more complex than microservices, and even less nimble.” Also, “An ESB externalizes domain knowledge and incorporates process knowledge.”

Microservices have more moving parts, but they are more focused. This approach uses lightweight REST, XML, and JSON and features smart endpoints with dumb pipes. Its benefits compared to SOA are, again, flexibility, scalability, availability, independent operability, and efficiency. Microservices provide finely tuned control in a way that SOA cannot.

What needs to change to make microservices work?

Heckler’s comparison so far painted a rosy picture of microservices compared to the alternatives. But he made it clear that there are obstacles to overcome. “There is more complextity at the macro level. This means you need better architects.” Of course, this was not an invitation to fire everyone and start building a new team. Mark explained that these next-generation microservices architects may already be within an organization, but they need to be identified and cultivated.

Enterprises must also give up the idea of having a single data repository. That has to change. However, it will be worth it in the long run. “It’s always easier to combine small, self-contained code or data than to decouple code or parse data.” Heckler rounded out his talk with a more detailed look at microservice enablers like load balancers, intelligent routers, and circuit breaker dashboards that can help manage and make the most of the much-hyped benefits of microservice while avoiding potential pitfalls.