Table of Contents
As you have noticed this quarter we are talking about trends and buzzwords so that you know what to focus on this year. Today we will discuss microservices architecture; it’s essence, benefits and successful case studies.
What is so good about microservices architecture ?
When we talk about microservices architecture, we talk about an architectural style, an approach to software development in which a large application is built as a suite of modular services; small, independently versioned, and scalable customer-focused services with specific business goals, which communicate with each other over standard protocols with well-defined interfaces. As they are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages and can also be managed by different teams.
Microservices architecture is a way of breaking large software projects into smaller, independent, and loosely coupled modules. Individual modules are responsible for highly defined and discrete tasks and communicate with other modules through simple, universally accessible APIs. It is a distinctive method of developing software systems that has grown in popularity in recent years. Thanks to its scalability, this architectural method is considered particularly ideal when you have to enable support for a range of platforms and devices, for example web, mobile, Internet of Things, wearables, etc. or simply when you’re not sure what kind of devices you’ll need to support in a cloudy future.
The main idea behind microservices architecture is that some types of applications become easier to build and maintain when they are broken down into smaller, composable pieces which work together. In other words, each component is developed separately, and the application is then simply the sum of its constituent components. In a microservices architecture, each service runs a unique process and usually manages its own database. This not only provides development teams with a more decentralized approach to building software, it also allows each service to be deployed, rebuilt, redeployed and managed independently.
The philosophy of the microservices architecture : “Do one thing and do it well”. Services might run within the same process, but they should be independently deployable and easy to replace. They can be implemented using different programming languages, databases, and software environment. The services are small, fine-grained to perform a single function. They embrace automation of testing and deployment, continuous delivery software development process, failure and faults, similar to anti-fragile systems. Each service is elastic, resilient, composable, minimal, and complete.
Also, probably you have heart about Docker if you are interested in microservices architecture. And you have heart that Docker or other container technologies is kind of enabler of a microservice architecture. Containers are designed to be pared down to the minimal viable pieces needed to run whatever the one thing the container is designed to do, rather than packing multiple functions into the same machine. The ease of development that Docker provides help make possible rapid development and testing.
Using containers and microservices together enhances cloud capabilities. Microservices is scalable and reusable, while containers supply efficient resources. Both microservices and containers can work independently, but it has become clear that merging them has improved runtime frequency, cloud-hosting policies and cloud tools.
Microservices architecture benefits
- Software built as microservices can be broken down into multiple component services. So that each of these services can be deployed and then redeployed independently without compromising the integrity of an application. That means that microservice architecture gives developers the freedom to independently develop and deploy services.
- Better fault isolation. If one microservice fails, the other will continue to work
- Code for different services can be written in different languages
- Easy integration and automatic deployment; using open-source continuous integration tools such as Jenkins, etc.
- The microservice architecture enables continuous delivery
- Easy to understand since they represent the small piece of functionality and easy to modify for developers, thus can help a new team member become productive quickly
- The code is organized around business capabilities
- Scalability and reusability, as well as efficiency. Easy to scale and integrate with third-party services
- Components can be spread around multiple servers or even multiple data centers
- Work very well with containers, such as Docker
- Complement cloud activities
- Microservices simplifies security monitoring because the various parts of an app are isolated. A security problem could happen in one section without affecting other areas of the project
- Increase the autonomy of individual development teams within an organization, as ideas can be implemented and deployed without having to coordinate with a wider IT delivery function
Successful case studies & examples of microservices architecture implementation
Netflix, eBay, Amazon, the UK Government Digital Service, Twitter, PayPal, The Guardian, and many other large-scale websites and applications have all evolved from monolithic to microservices architecture. Let’s look at some of the success stories to see the result.
Walmart successfully revitalized its failing architecture with microservices
This is a good example of what should be done when aging architecture begins to negatively affect business. This is the multi-million dollar question which the IT Department of Walmart Canada had to address after they were failing on Black Fridays for two years in a row.
Migrating to microservices actually brought notable results:
- Conversions were up by 20% literally overnight
- Mobile orders were up by 98% instantly
- No downtime on Black Friday or Boxing Day
- The operational savings were significant as well since the company moved off of its expensive hardware onto commodity hardware
- They saved 40% of the computing power and experienced 20-50% cost savings overall
Spotify builds outstanding user experience with microservices
Kevin Goldsmith, VP of Engineering at Spotify knows from his experience that an enterprise which intends to move fast and stay innovative in a highly competitive market requires an architecture that can scale.
Spotify serves more than 75 million active users per month, with an average session length of 23 minutes, while running incredibly complex business roles behind the scenes.
So, Spotify came to the conclusion that if you’re worried about scaling to hundreds of millions of users, you build your system in a way that you scale components independently. And Spotify built a microservice architecture with autonomous full-stack teams in charge in order to avoid synchronization hell within the organization. These teams are autonomous, and their mission does not overlap with other teams mission.
Now, Spotify has around 90 teams, 600 developers, and 5 development offices on 2 continents building the same product, so they needed to minimize these dependencies as much as possible.
What Spotify really likes about microservices is that they don’t have large failures; big services fail big, small services fail small. Building a microservices architecture allows Spotify to have a large number of services down at the same time without the users even noticing it. They’ve built their system assuming that services can fail all the time, so individual services that could be failing are not doing too much, so they can’t ruin the experience of using Spotify.
Amazon embraced the DevOps philosophy with microservices
Amazon has also migrated to microservices.They get countless calls from a variety of applications, including applications that manage the web service API as well as the website itself, which would have been simply impossible for their old, two-tiered architecture to handle.
In 2001, the Amazon.com retail website was a large architectural monolith. It was architected in multiple tiers, and those tiers had many components in them, but they were coupled together very tightly, and behaved like one big monolith. They had a large number of developers working on one big monolithic website, and even though each one of these developers only worked on a very small piece of that application, they still needed to deal with the overhead of coordinating their changes with everyone else who was also working on the same project. When they were adding a new feature or making a bugfix, they needed to make sure that the change is not going to break something else on that project. If they wanted to update a shared library to take advantage of a new feature, they needed to convince everyone else on that project to upgrade to the new shared library at the same time. If they wanted to make a quick fix – to push out to their customers quickly – they couldn’t just do it on their own schedule, they had to coordinate that with all the other developers who have been processed changes at the same time. In the early 2000’s Amazon even had an engineering group whose sole job was to take new versions of the application and manually push it across Amazon’s production environment.
It was literally a very long and complex process, it was hell. It was frustrating for the software engineers, and most importantly, it was slowing down the software development lifecycle, the ability to innovate, so they made architectural and organizational changes.
These big changes began on an architectural level: Amazon went through its monolithic application into a Service Oriented Architecture. Amazon also implemented changes in how their organization operated. They broke down their one, central, hierarchical product development team into small, “two-pizza teams”. They wanted teams so small that they could feed them with just two pizzas. In reality, it’s 6-8 developers per team right now.”
Each of these teams were given full ownership of one or a few microservices. So they were defining their own feature roadmap, designing their features, implementing their features, then test them, deploy them and operate them.
After all these changes were made, Amazon dramatically improved its front-end development lifecycle. Now the product teams can quickly make decisions and crank out new features for their microservices. Now the company makes 50 million deployments a year, thanks to the microservice architecture and their continuous delivery processes.
Do you want to discuss the possibilities for your company ? Please contact us, we will be happy to discuss your project!
If you enjoyed this article, you might like…
- “Almost-Infinite” scalability systems
- 10 benefits you get by using Docker
- How important is a good software architecture?
- Why are Microservices a good idea?
- More about microservices architecture
If you liked this article and if you are interested in software development trends, I recommend you to subscribe to our monthly newsletter to receive latest tips, trends and examples.
