Lately, most of the companies I’ve been talking to recently have at least been thinking about microservices. Unfortunately, it’s very easy for this topic to lead into a tools and frameworks discussion. To avoid jumping into this trap, I made a point in a previous post that if you’re thinking about microservices, you need DevOps first.
There’s 3 important things that don’t usually come up when we think about DevOps.
Change your Mindset
We have deadlines, we have external pressures, so sometimes we want to save time. When we start using a new technology, this could mean that we just treat it as something familiar to us. It happens all the time, approaching document NoSQL databases as just another SQL database. The same is true for microservices; we apply the familiar N-tier architecture.
N-tier architectures put emphasis on creating horizontal tiers. When building microservices, it’s recommended to think about “vertical slices.” Combine the two? You get nanoservices – a microservice anti-pattern.
Also, what to share code as much as possible? It’s a very useful technique in traditional development. The problem with reusing code packages among multiple services is when that packages changes often. A change in a shared dependency means that multiple services have to be redeployed. Do this enough and you’re back to monolithic releases – nullifying one of the greatest benefits of microservices.
So become very familiar with the principles and characteristics of microservices, they will save you time and frustration. They will a Litmus test when a new service is to be created, a new technology to be adopted, or a new dependency is to be added.
At Nebbia, we’re huge believers in automated testing. In addition to unit and integration testing, load testing is a great way to test the architecture and its assumptions. In some ways, load testing is more important for microservices than it was for monolithic applications. Why? Companies are choosing to create microservices so that systems are more scalable. If this is one of the main drivers for this type of architecture, why not put it to the test?
In addition to verifying architectural assumptions, load tests can also:
- Entice dev and ops to produce meaningful logs and metrics
- Shine a light on bottlenecks or potential deadlocks between services
- Bring cloud bills down – developers can optimize the areas that use the most compute
- Establish a baseline for smaller acceptance tests focused on performance
- Help dev and ops practice finding the root cause of issues with production
- Understand the risks – if the team understand what the bottlenecks, then risk mitigation can be prioritized with the backlog
Release Early and Often
Microservices and DevOps call for cultural changes, specifically around silos. So many more components in an architecture means that it’s a lot more for ops to maintain. If dev and ops don’t talk, there is simply too much risk of things not going according to plan. Releasing an app is a great way to practice collaboration between these groups. Striving to making releases boring will lead you down more automation, more telemetry, and more cohesive services.
Releasing early and often also keeps us honest. It’s very easy to become excited at all the new possibilities and all the new tech that microservices introduce. How do we ensure that we don’t bit more than we can chew? Releasing working software early and often – and I don’t just mean just having Sprint Demos. I mean releasing early to start getting feedback from users.
How Can We Help?
As consultants, we see the many hurdles that companies face in creating software. As Azure and Devops consultants, we see the many problems in delivering the software and adopting a cloud-first approach with Azure. How do you monitor services in Azure? Which Azure service to pick? To containerize or not?
Whatever your pain points are, we can help create a customized roadmap for your DevOps and Azure journey.