Microservices vs. Monolithic Architecture

By: Asaf Yigal

Every developer instinctually knows — or is soon painfully made aware — that one tiny change can change everything. Just as in rock climbing, each move limits all future options, so an ill-considered starting position can end up suddenly becoming fatal. With the increasing demand for shorter and shorter development cycles and a shorter time-to-market, decisions made during the initial architectural phase are now more important than ever before.

A properly defined software architecture should do more than just outline the high-level structures. It should unite all of the stakeholders, from coders to management to marketing, under a vision of what success will look like.

The New Client-Side vs. Server-Side Debate

Among the primary decisions, an architect has to make is to decide where the heavy lifting will occur. Among the various different patterns and styles of software architecture, a debate continues to rage over this very question.

Adrian Cockcroft of Battery Ventures sparked off one famously public debate on the subject with his tweet:

Etsy at #qconlondon make it clear to me why monolithic apps are a dead end. Use microservices for continuous scalable deployments

— adrian cockcroft (@adrianco) March 5, 2014

John Allspaw, Etsy’s CTO, responded:

@adrianco your critical thinking is lacking on this one, because you’re unable to imagine all benefits. — John Allspaw (@allspaw) March 6, 2014

Allspaw went on to explain in a later tweet: “Less options can open opportunities. A few numbers of well-understood tools and patterns brings advantages.”

Here’s a bit more background on their positions. Monolithic architecture refers to the traditional method of software development going all the way back to mainframes. All the processes and subroutines are part of one massive code base that can be run on various servers as needed for minimal latency and maximum uptime.

The newer architecture is microservices, where a hive of independent processes coordinates their functions in real time. Initially, this may sound like a rerun of the ancient client vs. server-side debate. Basically, that’s a fair comparison, but there are three notable differences that arise from the constraints of the new mobile-oriented market.

The three differences have to do with an update to service-oriented architecture (SOA), an enterprise service bus (ESB) to invoke those services, and some degree of centralized governance (CG) to prevent it all from becoming unmanageably complex.

SOA, ESB, and CG

SOA has been around since the turn of the millennium as a way of handling web services more efficiently. Over the years, SOA has been used in many different ways. This means that the method by which it relates to microservices depends on which definition is being used any given moment.

Oracle’s Tech Network Manager Bob Rhubart summed up the SOA relation in this way: “The picture that emerges is not of microservices as an alternative to SOA, but rather as a way to restore flexibility that may have been lost in SOAs that became too rigid and monolithic.” As the number of services starts to scale upwards, it becomes apparent that direct communication rapidly becomes a nightmare. The ESB normally defines one access method or interface for each service. When it’s time to upgrade the system, when the company is bought out, or when vendor assignments are renegotiated, all the developers have to do is update the ESB.

The value of centralized vs. decentralized governance is also controversial. Senior Engineers Martin Fowler and James Lewis reviewed the state of the development community and concluded this: “One of the consequences of centralized governance is the tendency to standardize on single technology platforms. Experience shows that this approach is constricting — not every problem is a nail and not every solution a hammer.” However, there are still times when monolithic architecture with centralized governance just makes more sense.

Projects that Benefit from a Monolithic Architecture

Though there is clearly plenty of room for opinion, specialization, and nuance, there are certain indicators that can suggest which architecture is better suited for specific goals. For example, David Fullerton, Stack Exchange’s VP of Engineering, defended monolithic as a boring architecture that produces exciting results. During his presentation at QCon New York, he said that his monolithic architecture “scales pretty well for us. We handle 4 billion requests per month, 3000 req/s peak, and 800M SQL queries per day, 8500/s peak.”

Monolithic architecture offers a clear path when the time is short, and it’s critical to get up and running as quickly as possible. If the team is already together and in sync, they can cooperate more productively and stay on task. Deployment is straightforward, and scaling is relatively easy. The team just needs to run multiple copies on a number of virtual or dedicated servers using a load balancer. Often, teams end up building the core on a monolithic structure and then building out component add-ons using a microservices approach.

Projects that Benefit from a Microservices Approach

There are plenty of good arguments for microservices out there, but industry analysts point out that it can be the root of serious communication problems both for the app itself and for the team building it. Microservices definitely come with a much higher bar for documentation, testing, and time for resolving incompatibilities.

PayPal CTO James Barrese said they switched from monolithic to microservices to make more updates in a shorter cycle: “The pace of innovation wasn’t where we wanted it to be, as a company.”

The Final Word

Does microservices software architecture represent the future of software development architecture? PwC certainly thinks so. They pointed out that:

Companies such as Netflix, Gilt, PayPal and Condé Nast are known for their ability to scale high-volume websites. Yet even they have recently performed major surgery on their systems. Their older, more monolithic architectures would not allow them to add new or change old functionality rapidly enough. So they’re now adopting a more modular and loosely coupled approach based on microservices architecture.

The fact is that monolithic is not dead, though, and still serves as the most effective route for rapid prototyping, even if teams that move to microservices later on in the cycle. Until a working AI comes online, a combination of the two approaches must be the best way forward.