DevOps and Microservice Architecture are BFF’s

So, you want to get to shorter release cycles and you know you need some “DevOps”, but what are microservices and why are they important to a successful DevOps initiative? This article will attempt to demystify the concept of microservice architecture and clarify why you should seriously consider moving to containerized microservices as part of your DevOps strategy.

First, let’s define some terminology so we are speaking the same language. A microservice is a single service. It does one thing. For example, a login service. It takes a user name and password, checks it against a database, and then returns either a success or a failure message. This example may be a bit over simplified but it illustrates a classic system design concept. We have an input, we perform some operation on that input, and we produce an output. A service is a microservice when it is decomposed down to this form of simple, singular function. The login microservice doesn’t do new user registrations. It just performs authentication.

A containerized microservice is a service that is completely self-sufficient. This means that it owns the data necessary to perform the function it is intended to perform. Continuing with our example of the login service, this suggests that the login microservice has its own database that contains user names and passwords. To be even more clear, I’m not saying it has its own table in a larger database. I’m saying it has its own database, isolated from all other systems. The login microservice sits within a container that includes the database.

Okay, so what happens when a new user is registered? When a new registration is successful, that microservice will send a message to the login service to add that new user and password to its database. So, microservices exchange messages and keep data synchronized between them. This may be referred to as event driven architecture.

Don’t worry, I’m getting to DevOps, but I have one more concept I want to establish before we go there. Containerized microservices are also designed to scale. Imagine the login service for Netflix, Amazon, or FaceBook. To handle the millions of authentication requests they get, there may be hundreds or thousands of instances of the login microservice. This is done by creating an image of the service and then deploying multiple instances of that service, each in their own container. Each instance is identical, contains an identical copy of the database, and every message sent to the “service” by another service, like a new user registration, is received by every instance. If any instance has a problem, it can be taken down and replaced automatically. We can also scale by adding more instances, on demand, or reducing the number of instances when demand is low.

Okay, so the DevOps connection is this. If we want to be able to safely release new software rapidly, and automatically, (continuous delivery) we need to make sure that the service we are updating is isolated. Conversely, with monolithic applications that share a huge database, this is almost impossible. With a monolithic system, any change to the database schema could affect many services, features, and functions that rely on that database. Hence the need for regression testing, performance testing, and many checks and balances before new software can be released. With microservice architecture, if I want to change something in the new user registration process, I can change it without risking losing login authentication services or any other services, features or functionality. Of course, it is also much easier to test just that new user registration service and be confident that the change is good and react to any issues that appear when the change goes into production. Again, I’m over simplifying, because we do need to test the messages that are exchanged between the new user registration microservice and other services to make sure we didn’t change anything that requires a change in another service. That is still a limited number of test cases, which can be automated.

If you have a monolithic system now, and you want to get to continuous delivery, you need to transition to microservices. How do you do that? As they say, it is like trying to eat an elephant. You do it one bite at a time. You steadily decompose services into microservices and deploy them to the cloud in containers. There is more to DevOps than just getting to microservice architecture, but taking this kind of incremental approach to decomposing your monolithic system puts you on the right track towards achieving DevOps.

A microservices architecture lends itself to smaller, safer releases, that can be tested and deployed quickly. You still need tight collaboration between development and operations, and the tools and processes in place to handle continuous integration, automated testing, configuration management, deployment and monitoring. Don’t be too aggressive. Get some wins and let success build momentum and confidence within the organization. It is also okay to ask for help. There are folks like me around that can coach or consult as needed.