Microservice architecture offers organizations a way to manage huge volumes of traffic while reducing costs and development time, and making it easier to grow and scale. That definitely sounds like it’s worth a closer look.
In this post, we’ll look at how microservices are structured, what their advantages are when compared to traditional application architecture, and how businesses use them.
Let’s start by defining microservice architecture.
Microservice architecture is a way of structuring applications in which each application function is written and deployed as a separate tool, handling its own data. There’s nothing inherently ‘micro’ about these services — individual services can be very large, very small, or somewhere in between. What makes them microservices is that they structure a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms such as resource APIs. Each service is built around a business capability or ‘job to be done’ for the user, and there’s a minimum of centralized oversight.
Microservices architecture is sometimes referred to as composable, modular, or best-of-breed architecture; probably the most illuminating alternate term is also the least-used: MACH, for Microservices-based, API-first, Cloud-native, and Headless.
Traditional application architecture is monolithic (literally, ‘one stone’). It’s a single application that can do everything that everyone requires of it. It typically includes three parts: A database, a server-side application that handles information in the database, and a client-side user interface running HTML and/or JavaScript in a browser. When anyone wants anything from the user interface, it will send requests to the server-side application which will query the database, put together a response and send it to the UI for display.
In other words, this is a conventional web application. There are times when using a conventional web application is ideal, for instance when building a small service rapidly.
Microservices have some important advantages over more traditional application architecture, and we’ll get into those further down this post. First, though, here are some examples of microservices architecture.
Here are three real-world microservices you’re probably already familiar with as a user:
Amazon started life as a standard web application. Faced with the prospect of reconciling in-process changes to the code from hundreds of developers into a single master version to be deployed to production, Amazon’s engineering department found they needed to come up with something else. Clearly, there was a structural problem with the whole process. The solution, explained Amazon AWS senior manager for product management Rob Brigham in 2015, was to pivot to microservices, taking ‘Amazon’ apart and restructuring it behind the scenes as individual tools.
“We went through the code, and pulled out functional units that served a single purpose, and we wrapped those with a web service interface,” he said. Some of these tools seem very small and focused — there’s a single service that renders the ‘buy’ button on product pages, another that calculates taxes during checkout.
But then, there always was; the difference is that they were yoked to each other so that changing one meant changing them all. Now, when taxes change in one of the 58 countries Amazon serves, only one relatively small application element must be altered.
Here’s a real-time graph of Amazon’s microservices dependencies in 2008:
… colloquially referred to at the company as the ‘Death Star.’
Another ecommerce giant, eBay found itself hosting over 2 billion pictures, handling 250 billion search queries, and selling a pair of shoes in the USA every 9 seconds — and that was in 2011. Keeping up with the volume of database queries alone was becoming impossible for traditional architecture, even after significant overhauls in 1999 and 2005 that moved the company’s IT ever further from a conventional web application.
But these changes weren’t enough: a fundamental alteration in the company’s internal structure was required.
In response eBay moved to a microservices approach, initially homebrewing with code they made open source in 2011 before replatforming to Kubernetes, Kafka and Envoy in 2018-19. It’s a good thing they did: in 2011, eBay had 97 million active users; in 2020 that number was 159 million.
Netflix began its pivot to microservices before a lot of us had heard of it. In 2009, microservices weren’t exactly common knowledge either, but Netflix found itself in a bind; its extant IT infrastructure froze up, leaving the company unable to fulfill either its nascent streaming customers or its much better-established DVDs-by-email business. Its website may have looked almost perfectly 2009:
…but behind the scenes, Netflix was moving away from a relatively frail traditional architecture and towards a more secure and reliable microservices-based approach. It involved building a huge array of interrelated services, which when visualized looks something like this:
Netflix now faces the prospect of competing with other providers of a service it invented; at least it doesn’t have to maintain a cumbersome and fault-prone legacy codebase at the same time. Instead, after homebrewing its own in-house platforms, it began replatforming to SpringBase in 2018.
Here, we can see that the main examples of large-scale microservices users share some characteristics — being retailers, selling online, and so on — all of which can be summed as: they’re big companies that handle a large number of small, real-time transactions and requests.
If you substitute ‘customer searches’ or ‘database queries’ for ‘sensor inputs’ or ‘instruction requests from shop-floor robots’ you’ve got a pretty accurate description of the state of play in industrial IoT.
Monolithic architecture isn’t a stage on the route to the development of microservices. It’s a choice, and for some organizations it’s the right one. Here are the advantages and disadvantages of monolithic application architecture.
What about the disadvantages?
Microservices are not the answer to every problem. Here’s where they shine — and where they don’t.
This depends on where you are in your growth journey, your technical situation, and the services you offer your users. In general, we can say that the more you cater to large numbers of small queries or transactions, the earlier you’ll benefit from transitioning to microservices. If you offer a wide range of services, microservices can allow you to scale the different parts of your business separately.
However, if you’re very early in your growth journey or your offering is narrowly defined and coherent, you may find monolithic architecture solves more of your problems.
An example of how this plays out in real life is the log management platform Scalyr, created by ex-Googlers Steven Czerwinski and Steve Newman. After leading development of Google Docs, they set out to build Scalyr — and ‘even though we had had these positive experiences of using microservices at Google,’ Czerwinski told buttercms.com’s Jake Lumetta, ‘when it was just Steve and I the first versions of the service were just a monolithic server…because it was less work for us as two engineers to maintain and deploy.’ As the company grew, Czerwinski continues, ‘we started pulling off some of those pieces from the mount of the Linux server for particular reasons.’
AndPlus has worked with hundreds of businesses to build applications that fit their business needs. We’ve built monolithic applications for large and small businesses; we’ve created microservices-based applications, and helped companies transition over from one to the other. Most importantly and impactfully, we’ve worked with businesses to identify the tools and systems required to match their technical setup to their business needs.