With the rise of new virtualization technologies using containers, people are starting to think more and more about using microservices in their organizations. It’s a topic that has been getting a lot of attention. Many top technology companies have attributed some of their recent success to microservices. Some of these companies include Netflix, Amazon, Uber, and Spotify. Every day these companies use hundreds of microservices to power their products and stay nimble.
Microservices
What’s a microservice architecture? It is the practice of building an extensive application using multiple services working together. A business capability is developed end-to-end and encapsulated in a small service, i.e., a microservice. Each service also runs on its process and communicates with other services using RESTful or queue-based protocols. All the database access, business logic, and any other infrastructure code are encapsulated in one service to fulfill a business need.
But why?
We have gotten better at providing meaningful experiences for our users as an industry. Users see the value and request more features. However, our applications reach a point of diminishing returns. The Law of diminishing returns teaches us that we will see diminishing returns for the amount of effort placed on development at some point in time.
So how does a company continue to innovate and stay agile as products get larger? One solution is microservices. With this approach, you focus on developing business capabilities autonomously. Instead of orchestrating a significant release to offer new features, a new business capability can be added by simply adding a new service. Eventually, you create microservices that can be developed, tested, deployed, and managed independently of other parts of the application.
You need DevOps first.
The world of microservices is so rich already that it’s easy to get enamored with its tools and technologies. We may try to shortcut success by purchasing platforms and tooling centered around building microservices. One of the best ways to reduce the risk is to educate ourselves on the principles of microservice and the role of DevOps within it. So here are three reasons why you should start with DevOps.
Reason #1: Conway’s Law
Conway’s Law states that a company will design systems that reflect how the organization communicates. For instance, if your system is split into a front-end tier, a back-end tier, and a database tier, there’s likely a front-end, a back-end, and a database team. So if your organization is structured in a way that does not mirror a set of independent and autonomous services, then it probably won’t be capable of building microservices. Could you develop small services with large horizontal teams? Sure. But The additional complexity could quickly swarm units with micro-tasks to support a microservice architecture.
Reason #2: Without DevOps, you might be worse off than before
If you don’t start with DevOps, teams can become less independent than before. Productivity can grind to a halt because development teams can’t deploy their code. Quality Assurance teams could become bottlenecks because all the untested code hits their backlogs at once.
Defect count would soar because issues are not “reproducible.” Developers would have to develop with many services running at once because of the lack of automated testing. Developing in this environment would be highly cumbersome, especially with new services and more team members. Developers would have to interrupt each other constantly to help others troubleshoot and run their services.
Reason #3: Microservices is just DevOps in practice
Microservices architecture is a natural progression of embracing DevOps. A successful DevOps practice results in continuous integration & delivery, automated testing, and applying monitoring and telemetry. There are many more benefits of DevOps, but to touch on a few:
Continuous Integration & Delivery
Teams build and package their services without relying on other teams/departments in the company. Teams release often and frequently without impacting other groups.
Automated Testing
Teams find out quickly when there’s a regression in their service. Teams are encouraged to write unit tests because that’s the quickest way to get feedback.
Advanced Monitoring and Telemetry
Issues are quickly narrowed down to a microservice, reducing the constant need for escalations to get problems resolved. Teams become responsible for supporting their service. Teams get encouraged to experiment and improve their services while measuring their performance.