Microservice architecture is on the rise and has the potential to become a mainstream application design pattern.

I will introduce you to how the architecture compares and differentiates itself from the common monolithic architecture, its benefits, drawbacks, its implications to DevOps and its potential impact to the digital business.

We’ll start with a definition of microservice architecture from James Lewis & Martin Fowler:

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. This is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

In essence, microservice architecture is an application comprised of many light weight (self-contained) web services, each providing a distinct business component or function (boundary) with service communication provided via HTTP/REST. The sum total (or subset) of these services provide the fundamentals of the application.

The diagram above depicts a general microservice architecture. Each business capability or function is defined by a microservice with a clear and distinct domain boundary (Product, Cart and Order service) developed by independent teams.

Comparison of microservice architecture versus monolithic architecture

Microservice architecture

Monolithic architecture

Code, development and ownership with clear and distinct domain (business) boundary

Prone to blurring of code and domain boundary ownership unless adhering to well-defined governance

Allows rapid and frequent deployment of small business functionality with minimal impact to overall application architecture

Continuous deployment is more of a challenge—typically, a larger code base and dependencies have to be deployed and tested

Developers have the ability to choose their preferred or latest technology

The technology is predetermined upfront after which developers have limited or no freedom to change technology (for example, a Java application may have to be standardized on Java7)

Improved fault tolerance and isolation; if a microservice fails, then in general it does not impact the overall application or architecture

When a fault occurs then it can impact the entire application (for example, JVM out of memory)

Inherently small services can be scaled easily and independently

Can be scaled, but more of a challenge as typically the entire application has to be deployed and replicated

Why businesses need microservices

Microservice architectures have been predominately developed and used by webscale companies, to name a few, Netflix, Amazon, Uber and ebay. All of these companies business models are born on the web, i.e., their business models are inherently digital business models and their technology (operating model) and business is indistinguishable. Each and every successful digital business uses data to their advantage and data is vast at unprecedented levels, driving growth in business intelligence and analytics. Data provides customer insight, behaviors, preferences, consumption and so forth. However, all of this data and insight is useless if (digital) business models cannot be adapted or change very quickly to exploit and commercialize these changes in consumer preferences. And, this is why a microservice is the preferred architecture of successful webscale businesses.

We only have to look at Amazon’s business model to see why this works. Amazon is predominately the largest and arguable the most successful e-commerce platform in the world. Their success is attributed to innovative development of technology, but that was not always the case. Initially their platform was designed as a monolith, and as it grew, so did the drawbacks, which impacted the ability to release at the rate of business. These drawbacks were attributed to maintaining a monolithic codebase, inefficiencies in the software development lifecycle with waste and manual handoffs.

That all changed in 2002 when Jeff Bezos mandated the following:

  • All teams will henceforth expose their data and functionality through service interfaces.
  • Teams must communicate with each other through these interfaces.
  • There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  • It doesn’t matter what technology they use.
  • All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.

And hence their microservices journey started and the rest is history.

Competitive advantage
The beauty of having a platform devised around small discrete microservices, each providing a business capability, is that (a) it can be used to support many types of user experiences, web or mobile while efficiently using the core platform; and (b) the most powerful business advantage is that digital business models can be changed at will, able to rapidly and frequently change by the deployment of a microservice, (i.e., business logic can be adapted to marketing changes at the rate of business in a riskless manner). Having such a platform is a perfect example of sustainable competitive business advantage.

DevOps 2.0: The evolution of DevOps
The general essence of DevOps will always remain the same, improving the efficiencies of product development and alignment with the goals and objectives of the business. But with the adoption of microservices, we are witnessing changes to how the building blocks of DevOps are being implemented. When I started DevOps several years ago, I implemented continuous integration with Java, Junit, Maven, Ant and automated deployments with Tomcat, Weblogic, Websphere and relational databases—all supporting monolithic architectures.

In the very close future (some would say now), with the advent of microservices architecture, those very same principles will be applied with different technologies (the details of which shall be topics of other blogs). To name a few, all of which support the end-to-end lifecycle of a microservice platform:

  • Development: Container, Docker, Lambda, Node.js, Go & Rust
  • Operational: Meso, Kubernetes, Swarm & Amazon ECS
  • Datastores: Orchestrated, Distributed Ephemeral, Cassandra & DynamoDB
  • Policy: Security compliance, Vault, Docker Content Trust

What I find insightful with these new generation tools is that they continue to blur the lines between Development and Operations, until a point where there is simply one, “DevOps.” Eventually the term will disappear (and also the distinction of Development and Operations) and simply become the way of building software.

Additional reading
Companies using Microservice architectures
What is Microservice architecture
What led Amazon to its own Microservice Architecture

Darryl Bowler

DevOps Senior Manager & Architect

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog