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.
What is 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.
- API-first means all functionality is exposed through an API, meaning application elements can constantly share information by asking each other for it while still managing their own data.
- Cloud-native means being built in accordance with the structures and functions of the cloud, including containerization and elastic resource scaling.
- Headless means the front-end user experience is decoupled from the back end, working as a separate application whose role is to permit the user to interact with the rest of the tools available.
Microservices vs monolithic architecture: an introduction
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.
Examples of microservice architecture
Here are three real-world microservices you’re probably already familiar with as a user:
Amazon
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.’
eBay
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
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.
What are the pros and cons of monolithic architecture?
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.
Advantages:
- Easy deployment with one master executable file or directory.
- Easier development with a single codebase.
- Simplified improved performance, with fewer APIs. Additionally, shared-memory access is faster than Inter-Process Communication (IPC).
- Simplified testing, because a single centralized unit is easier to comprehensively test.
- Easier debugging, because with all code located in one place it’s easier to follow a request end-to-end and identify an issue.
- Fewer cross-cutting concerns such as logging, rate limiting, and audit trails. It’s easier to hook up components to these cross-cutting concerns in monolithic applications.
What about the disadvantages?
Disadvantages:
- Slower development speed, because in a monolithic application changing one element means redeveloping the whole application.
- Reduced scalability because individual components can’t be separately scaled.
- Reduced reliability, since an error in any module can affect the entire application’s availability or functionality.
- Slower adoption of new technologies since changes in the framework or language affect the entire application.
- Reduced flexibility, since there’s a larger degree of sunk cost and often more technical debt.
- Slower deployment since the whole application has to be redeployed after any change.
- Tight service coupling and entanglement mean it can be difficult to isolate services for visibility, or to transition to microservices.
- Reduced visibility and comprehensibility since there will likely be unknown or undocumented dependencies and side effects built into monolithic applications.
What are the pros and cons of microservices?
Microservices are not the answer to every problem. Here’s where they shine — and where they don’t.
Advantages:
- Better organization, with each microservice assigned a specific job and zero overlap with other microservices.
- Decoupling, meaning microservices are easier to repurpose, reconfigure, recompose, redevelop, and replace. They can be made to serve different apps or user groups via web clients or public APIs, and allow for faster delivery and integration of parts into the whole application.
- Performance improvements, depending on how they’re organized. Microservice architecture doesn’t inherently deliver better performance. Because it’s possible to isolate high-use or rapidly-growing services and scale them independently, it can be structured to deliver continuously improved performance.
- Reduced error rate, with parallel development combined with boundaries between different application elements. This makes it easier to isolate errors within services, and more difficult to accidentally create connections and dependencies that should not exist.
Disadvantages:
- Cross-cutting concerns across each service, often unanticipated at design. These concerns are often concealed within the dependencies of extant monolithic architecture and must be ‘teased out,’ to use Rob Brigham’s term, during the process of transition to microservice architecture. This can involve incurring the overhead of building separate modules to provide cross-cutting concerns, or providing them as a service through which all relevant traffic is routed. This issue must eventually be faced even in monolithic application structures, but there it can be delayed much longer.
- Higher operational overhead, since microservices are often deployed on their own virtual machines or containers, meaning skilled hours must be spent managing the VMs or containers. These tasks can be automated with container fleet management tools, but this only becomes efficient at scale.
Should your organization use microservices?
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.’
Building microservices with AndPlus
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.
Takeaways
- Microservice architecture means building applications as a suite of interrelated but separate tools, each of which is responsible for a specific service, runs its own processes, lives on its own VM or container, and handles its own data, communicating with the rest of the application through lightweight APIs.
- Microservices are used by companies that need to handle large numbers of queries, searches or transactions in real time. That includes ecommerce giants, and streaming companies like Spotify and Netflix, but also covers many SaaS companies and IoT installations.
- Building microservices is a specialized software development task, best undertaken by those with an understanding of the virtualization and containerization techniques required — especially if the project is a transition from monolithic architecture.
