Every major cloud technology conference these days has multiple presentations about moving to a microservices architecture, so I did some research and tried to answer basic questions like what microservices are, what benefits and costs they provide to businesses, and when it might make sense to think about using them. My findings are summarized below; I think others may find it useful.
1. What Are Microservices?
The Netflix story is a great one for getting a basic understanding of microservices. Back in 2008, the Netflix website was one giant application, also referred to as a monolith in microservices lingo. The Netflix monolith had a lot of problems. For example, a simple error such as a missing semi-colon in the code base could bring down the entire Netflix website for several days. Also, developing new features was pretty slow as code changes (such as adding a new column to a database table) needed cross-functional teams to review and approve. Finally, and maybe most importantly, Netflix needed to move to the cloud so they could scale quickly enough to meet rising customer demand. Forklifting their monolith to the cloud wasn’t really an option, so they spent seven years adopting a Microservice architecture. This meant that they broke down their monolith into smaller, more manageable, and fully decoupled components, exposed through lightweight APIs.
The benefits of adopting a microservice architecture include:
a. Scaling Efficiently: Teams can easily scale out the application components that need more resources (such as authentication & payments), without having to scale out the entire application.
b. Raising Availability & Fault Tolerance: The decentralized nature of a microservice architecture eliminates single points of failure and delivers resilient, highly available applications that experience very little outage.
d. Getting Rid of Big Bang Deployments: Application deployment becomes a non-event as teams can deploy their services independently multiple times a day, without having to put the entire application in maintenance mode, or co-ordinate with other teams.
e. Giving Teams Technical Autonomy: Teams can implement their service using whatever technologies they prefer, as long as these services are exposed through standard APIs.
Despite their numerous benefits, microservices come with the following costs:
a. Microservices Imply an Org. Change: At its heart, microservice architectures are about creating the autonomous teams that can build, run and manage independent and loosely coupled services. This usually means a change from the current org. structure, and we all know how painful and emotional org. changes can be.
b. Application Architectures are More Complex: Every microservice architecture is essentially a distributed system, which means that things like monitoring, testing, and end-to-end visibility of the system become really really hard. Also, moving developers between teams becomes more difficult as their new team may work on a completely different stack from their current team.
3. When To Think About Adopting Microservices
According to Martin Fowler, a microservices thought leader, there are a few housekeeping items you need to address before moving your critical applications to a microservice architecture. They include:
a. Rapid Provisioning: You should be able to provision new servers in minutes and not days.
b. Monitoring: You need to know what’s going on within your application; where things are failing and why.
c. Rapid Deployment: Your deployment processes should be automated, and should take minutes and not days.
If you are interested in diving a little deeper into microservices, here are a few resources I found to be super helpful:
a. Blog Post on Why You Can’t Talk About Microservices Without Mentioning Netflix.
b. Video of Microservices Overview by Martin Fowler – Very good overview.
c. Video of Microservices at Netflix Scale: Principles, Tradeoffs, and Lessons Learned by Ruslan Meshenberg (Director of Platform Engineering @ Netflix) – A little more technical depth, but nothing overwhelming. Good presenter.
d. Video of What I Wish I Had Known Before Scaling Uber to 1000 Services by Matt Ranney (Chief Systems Architect @ Uber) – A lot of focus on the people side of microservices.