One trend of the last few years is microservices architecture. In this post we’re looking at what that is, and what some of the benefits and drawbacks are.
Note: This is the third post of our four-post series on Trends on Version Control Land. Take a look at the first post on Innersourcing to learn more about common challenges large organizations face and how Innersourcing can solve them. Also check out our second post, Release Early, Release Often, to read about how and why GitLab releases monthly.
What are microservices?
Microservices architecture is a way of designing software applications as smaller, independent, cloud-based services rather than one monolithic data center. Netflix is a good example: their users application, movies application and ratings application are deployed independently. Netflix has made a lot of the code behind their microservice architecture open source. Uber, Soundcloud, Hailo, Amazon, and Ebay are a few other companies that are using microservices to deliver their applications. Uber shared a really nice narrative of their move from monolith to microservices on their blog.
Benefits of microservices
System-wide stability: Using Nextflix as an example again, since moving to a microservices architecture, they have achieved much greater system-wide stability, because API service interruptions are restricted to one service.
Scale teams: With microservices you can move more quickly because each app can deploy independently of the others. Teams can operate independently. Since larger teams have more overhead (decisions, training, etc.), being able to split them up per service increases efficiency.
Diverse technology: Since each service is independent, you can use the best programming language and database for each respective job.
Improved architecture: Splitting up the application in multiple services enforces module boundaries; each application has its own responsibilities. Please note that it only helps with enforcement, in a monolitic application you can also have great module boundaries.
Drawbacks
Latency: Making function calls between different services instead of in an application slows everything down.
Distributed system: The first rule of distributed object design is don't distribute your objects. Distributed systems are harder to debug, reason about, and do transactions in.
Three-step rollouts: If you have a change that affects other services you first have to push a new version of your application, then ensure all other services start using that, and finally deprecate the old version. If it was a single application that process could be done in one step.
The need to accommodate failure modes: You can only increase system-wide stability if services can deal with other services being down. You will have to program this into your application. For example, if Netflix's recommendations service goes down, they can't just remove recommendations from the console. Instead they'll need to build their application to display generic recommendations instead of personalized ones.
Infrastructure complexity: Microservices increase the number of applications you have to deploy, monitor, and throttle. You will need to automate everything to make this work.
Multiple projects: Each service will need to be its own project to achieve the necessary independence. Each service will need multiple repositories, CI, CD, and issue trackers.
GitLab and microservices
A major goal for us at GitLab is to make sure you can do everything you need to do within GitLab, with as few external integrations to deal with as possible. This way, you don’t have to set up CI/CD, and an issue tracker for each project and spend the time integrating them, they're all already pre-configured to use from one single UI. You can move issues between the projects of the different services and aggregate them with group level milestones. To ensure the right people have access to each project you can use LDAP group sync and the ability to invite teams from other projects.
When are microservices right for your team?
We think that microservices are great when your team is spending too much time coordinating. There is no set number but when you have more than 25 backend developers, coordination becomes more challenging. For another take on the benefits and drawbacks see Martin Fowler's take on the trade-offs.
Watch out for our last post of this series, we'll share our thoughts on what industries are likely to embrace Open Source!
