During the first two quarters of 2020, Netflix added nearly 26 million new subscribers and was ready to stream more content than ever (thanks to furloughs and lockdowns). So much so that the European Commission asked Netflix CEO Reed Hasting to switch EU subscribers to standard definition (SD) streaming (instead of HD) to prevent European internet infrastructure from going down due to the increased load.
How could Netflix accommodate such immense growth without flinching? Hint: thanks to a cloud-based microservices architecture.
Between 2010 and 2016, the streaming platform took a strategic step to fully migrate its operations to the cloud and speed up microservices development. Today, Netflix relies on over 700 microservices to power different aspects of its binge-watching service, from saving watched shows to billing your card. Each service is independently deployable and upgradable, meaning if Netflix wants to make a quick change or two, the entire platform and viewing experience won’t be affected.
While Netflix was one of the earliest proponents of microservices architecture advantages, it’s no longer the exclusive connoisseur of this approach to modern software development. From Apple to Zoom, businesses across all verticals are retiring their legacy architectures in favor of microservices.
A 2020 O’Reilly article titled “Microservices Adoption in 2020” shares that almost one-third (29%) of tech leaders have either migrated their systems to or implemented most of their systems using a microservices software architecture.
That leaves us wondering: Why are over two-thirds of business leaders not yet sold on the advantages of microservices?
Given that most industries have vaulted years ahead in terms of consumer and business digital penetration courtesy of the pandemic, issues of application performance and scalability have become even more pressing.
So the question is this: Will your business be like the European Commission, asking users to please slow down as we can’t keep up? Or would you rather take the Netflix approach and confidently work towards delivering unbeatable service to your customers?
The answer is obvious, isn’t it? Before we get into the details. let’s start with a quick refresher of the key terms.
Quick FAQs: What is a microservice?
A microservice is a bundle featuring a certain set of processes that run independently and can communicate with other services via lightweight protocols known as RESTful APIs.
You can think of a microservice as a LEGO brick — it might be either independent or connected with other bricks to make a more complex structure.
How do microservices communicate with each other?
Depending on the purpose, microservices use either:
- The HTTP/HTTPS protocol to invoke a regular Web API HTTP service
- Message-based communication (e.g. Simple Notification Service (SNS)) or event-driven communication
Here’s a simple example of how microservices communicate:
Source: Microsoft
A less technical explanation? In a microservice-based architecture, different services communicate via application programming interfaces, or APIs — code-level interfaces for connecting applications. Microservice APIs act like glue, holding together all elements of a platform.
Microservice vs API: What’s the difference?
An API is a special set of rules and routines for exchanging data and actions between different microservices. An API gateway serves as an intermediary between the UI (clients) and microservices, forwarding user requests to specific services and returning responses from them.
What are the advantages of microservices?
The benefits of microservices include higher resilience due to isolation, faster deployments, and technological diversity.
Higher resilience due to isolation. Microservices are designed as products that can run independently of one another. So if one microservice fails, requests to it can be rerouted to a failover microservices. Additionally, the scoped nature of microservices lets you deploy updates, changes, or patches to one service rather than the entire app, effectively reducing the risks of downtime.
Finally, using microservices you can work on new features in a sandbox environment — and build a separate microservices platform to power new product features, test it for efficiency, and connect it to the main service. Each microservices codebase can be developed and managed autonomously without any exposure to other internal system components.
Faster deployments. Containers and containerized deployments are some of the core principles of a microservices architecture. In essence, containers are ready-to-deploy software packages that can be launched automatically whenever the need arises, such as to replace a failed container or to release a new product feature. Containers dramatically reduce redundancy and speed up the frequency of new releases.
Primary reasons why organizations run container technologies
Source: Portworx — Container Adoption Survey
Technological diversity. Each microservice can be programmed in a different language, meaning you can diversify your tech stack and cherry-pick the best technology for the purpose. This makes microservices a great tool for modernizing your codebase in installments and migrating to newer tech without operational disruptions.
For example, core banking software written in COBOL can be sustainably decoupled and modernized in increments.
Are there any disadvantages to microservices?
There can’t only be benefits of microservices, right? If there weren’t disadvantages, the adoption rate would be much higher. According to Martin Fowler, the advantages of a microservices architecture go hand in hand with the following disadvantages:
- Increased distribution. Systems with many moving parts are hard to manage and orchestrate.
- Lack of consistency. Despite using different tech stacks, microservices need to effectively interact with one another.
- Operational complexity. Microservices require a mature approach to microservice governance and microservices configuration management.
- Performance limitations. Since microservices work in tandem and send remote calls to other services, lack of performance orchestration can lead to significant latency.
Microservices vs monolithic architecture: Why microservices wins
A monolithic architecture leads to an application in which all components are closely interconnected. This means the entire system will fail if a single small part fails. But if an application consists of several autonomous parts, it’s more reliable. Since small services are isolated from each other within a microservices architecture, faults in one service don’t affect the rest of the system. In other words, issues can be fixed without damaging the application’s deployment.
Just imagine how devastating it is to rewrite an entire application when only one section of code needs to be changed. Sadly, that’s what you’ll have to do if your application is monolithic. Adding new features, customizing, fixing bugs — any updates are painful with a monolithic architecture.
By contrast, microservices software systems make programs agile and scalable.
What is a microservices architecture?
A microservices architectural style structures an application as a collection of small independent services. In other words, it allows you to build an application not as a single unit but as a system of loosely coupled scalable applications.
In a wider sense, microservices is the go-to modern software architecture for industry frontrunners and a stepping stone on the way to becoming a platform business.
Core elements of a microservices architecture
Source: IBM
Microservices
We’ve talked at length about the concept of a microservice application as an independent operational unit. But how do you build microservices from a structural perspective? Especially if you’re starting with a monolithic app. Here are several key principles:
- Organize around business capabilities. When comparing a microservice vs monolithic element, one of the core differences is that a microservice has a separate database, set of processes, user interface, and external collaborators. Thus, the team responsible for a microservice (or a group of microservices) usually includes multiple roles — UX design, project management, development.
- Products, not projects. Amazon popularized the you build it, you run it paradigm, meaning developers should take full responsibility for managing a microservice as a product. This includes responding to customer feedback, providing support, and doing ongoing maintenance.
- Design for failure. This principle was largely popularized by Netflix. The key idea here is that microservices should have high failure tolerance both individually and in combination so that the failure of a single service doesn’t create a domino effect throughout the entire app.
Service mesh
Microservices perform both synchronous and asynchronous communications. Within complex products, communication between services can be challenging to manage due to its scale.
A service mesh is an infrastructure layer facilitating microservice orchestration and communication management by documenting how different services interact. It’s a visible infrastructure layer built right into the application that provides you with a neat set of tools for:
- Load balancing and traffic management
- Service health checks
- App authentication
- Security
- Failover policy management
Container platform
Containers package microservices and their dependencies into a standardized package that can be effectively pushed through development and testing and into production. The purpose of containers is that they can share operating system and middleware components to avoid duplicating the operating system across machine images. This makes them a good alternative to virtual machines (VMs), which require an operating system.
When it comes to microservices in software development, containers can help companies:
- Fit a larger collection of microservices on a single server
- Improve deployment times and frequency
- Deploy on-demand without affecting app performance
The above factors multiply the other benefits of a microservices architecture, such as the ability to effectively replace, replicate, or retire microservices with little effort.
By 2022, more than 75% of global organizations will be running containerized applications in production, up from less than 30% in 2020.
Apart from that, container services such as Docker and Kubernetes also facilitate the management of dependencies between containers so you can rapidly scale only certain parts of your microservices architecture based on workloads rather than the entire app. Lastly, a container platform is integral for microservice orchestration, as it provides a centralized view into all your services and enables you to arrange all those services in the right sequence.
Decentralized data management
Another staunch advantage of microservices over monolithic applications is decentralized data storage and management.
A microservice can be designed with a separate or shared database, depending on your needs.
Source: Martin Fowler
Using a database per microservice provide several advantages for high-load applications:
- Relevant business domain data is encapsulated within the service
- The data schema can be changed without affecting other services
- Each database can be scaled independently
- The failure of one database won’t affect other services
Additionally, each database can be optimized for different workloads and storage needs so you’re always using the best-suited tech stack.
Infrastructure automation and DevOps
DevOps practices such as CI/CD and testing automation are the cornerstone to effective microservices deployments.
One of the key principles of the microservices architecture is that no one has to wait for anyone. If your team wants to push an update to service A, they don’t need to wait for service B to get tested or deployed.
Source: Microsoft
But to make that happen, you need properly automated release pipelines plus an effective way for rolling back to a previous service version if things go awry after the release.
A staunch CI/CD process is integral for that. In particular, you should focus on:
- Creating independent deployment pipelines for different services so your team can make changes to one service without disrupting others
- Maintaining a strong versioning policy that allows for deploying new versions side by side with earlier ones (especially for breaking API changes)
- Ensuring you always have production-ready code in the main branch by automating the build and test processes
- Adding flexibility to the build process so every team can adapt it to their tech stack
Continuously seek out ways to automate your CI/CD pipelines to add more predictability to all deployments performed within your distributed systems.
API management
Microservices communicate via internal REST APIs, and these communications can be effectively governed by a service mesh. But what if you want to go a step further and join the burgeoning API economy? That is, what if you want to provide access to third parties via a microservice API gateway?
In that case, you should think in terms of an API management strategy — a governance model covering authentication, security, and product and portfolio governance.
To conclude
We’ve discussed microservices advantages, key principles of microservices, and architectural components. But at the end of the day, for most businesses, migrating to microservices is more a question of expertise. How can we make sure that intervening in our monolithic service won’t disrupt our operations?
The key to successfully adopting microservices is careful planning. Amazon, Netflix, Airbnb, and GE didn’t upgrade their architectures in one fell swoop. They pursued paced, structural changes to their technology stacks and modernized their core one LEGO brick at a time.
Intellias provides discovery sessions where our specialists assess your current system architecture and help you create a sustainable roadmap for transformations. Contact us to learn more!
