Microservices: Breaking it Down

It has been a longstanding goal of software companies to get features out to customers faster. As we see the rise in popularity of DevOps in software development, a new form of architecture has tagged along with it to the top: microservices. So what are microservices, and why are they such a big deal?

During my internship this summer, I researched DevOps methodology and the popular tools used to implement it. DevOps is all about continuous integration and deployment, improved team communication, and automated processes. In other words, DevOps helps you put out new features more quickly. If you want to take advantage of DevOps, you need a type of architecture that lends itself to quick development and automated deployment. Microservice architecture allows you to work with small, isolated services that make implementing DevOps a breeze.

Trouble with Monolithic Architecture

No architecture is as well-known as the tried and true monolithic application. Client side, server side, and database are all wrapped up into one jar file and shipped off to the server for deployment. It’s easy to develop, test, and deploy. However, when you’re trying to be quick and efficient, a monolithic architecture has many drawbacks.

• It’s difficult to understand and update. The dependencies between layers make it hard to quickly change the code without breaking something else. But, that’s only if you can find where you need to make the change in the first place.
• It’s a one package deal. If something happens to one part of the application, it happens to every part of the application. Redeploying or scaling up? The entire application is in for the ride. One part goes down? The rest goes down with it.  
• It’s not efficient. The bigger your application gets, the more it will impact performance and available resources. A monolithic application can become so large that it impacts start-up time. And, if you are scaling up your entire application because you can’t scale up individual parts of it, you’re wasting a lot of resources.

The Solution

Enter microservices: the younger, cooler cousin of SOA. Microservice architecture is an alternative to the classic monolith, and it solves many of the problems associated with the latter. The main idea of microservices is to break down your business logic and data access layers into independent services. Each service has its own database and is focused on a specific business capability. It is able to communicate with both the client side and other services through a well-defined API.  

Advantages

• Continuous Delivery & Deployment. With your application being made up of microservices, it makes it faster and easier to deploy updates. Unlike monolithic applications, all you need to do is take down and redeploy the specific service that needs a change – no need to get the rest of the application involved.
• Small Development Teams. Because your application is broken up into neat little services, distributing work to small teams is a quick task. The teams don’t have to wait for someone else’s code to start on their own. Each service should work independently (for the most part) from the other services, so development can happen more quickly.
• Isolation. Microservices are meant to be isolated. This means that it’s not the end of your application when one service happens to fail. While you might have a few broken functions that call the service that is down, the rest of your application is still functional while you work on getting it back up.
• Scalability. Remember all of those wasted resources that come with scaling up an entire monolithic application? With microservices, you can decide what to scale up at the lowest possible level. Scale up just one web server, or just one database. If you want to scale up both, you can do that, too. It’s entirely up to you, which means that you can save resources and ultimately, save money.

Disadvantages

• Complexity. The main issue with microservices is that the way services use other services can become incredibly complex. Testing, configuration, and deployment often require automation due to the sheer number of services that are affected by a change to just one. On top of that, you have to manage each individual service and scale it as needed. Automation tools are almost always a necessity.
• Partitioned Databases. With an architecture that gives services their own database, entering data isn’t as straightforward as it is with a monolithic architecture. The entry data must be split up and sent to the correct service. When you have a large number of services, this kind of data handling can be challenging.
• Sometimes It’s Not Needed. Just because you can implement microservices doesn’t mean you should. You need to take your application and its users into consideration. If your application is small, has low complexity, doesn’t need pinpoint scalability, or is rarely updated, microservices are not ideal. It may be more trouble than it is worth to re-design the architecture.

Looking Forward

As more companies begin to adopt the DevOps methodology, they are also adopting microservices. Among them are Amazon, Netflix, Spotify, Uber, and Walmart – just to name a few. The transition of architecture from monolithic to microservice introduces complexity, but it also paves the way for automated processes. In the end, if you are adopting DevOps, using microservices is a faster, more efficient way to provide your clients with what they need.

Sources:
https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
https://opensource.com/resources/what-are-microservices
https://en.wikipedia.org/wiki/Microservices