Nebbia Technology

12 March 2018

Thinking about microservices? You need DevOps first

With the rise of new virtualization technologies using containers, people are starting to think more and more about using microservices in their organizations. They’ve been getting a lot of attention and companies like Netflix, Amazon, Uber, and Spotify have attributed some of their recent success to using them. Every day, these companies use hundreds of microservices to power their products and stay nimble.

What is a microservice architecture?

In short, it’s the practice of building a large application with the use of multiple services working together. An additional business capability, for example, is developed end-to-end and encapsulated in a small service which runs its own processes and communicates with other services using RESTful or queue-based protocols. All of the database access, business logic, and any other infrastructure code is encapsulated with the purpose of fulfilling a single business need.

But why?

As an industry, we’re getting better at providing meaningful experiences for our users, who see the value and request more features. However, our applications reach a point of diminishing returns, where we see a lower return for the amount of effort placed on development.

Microservices, on the other hand, allow a company continue to innovate and stay agile as products get larger. Here, you focus on developing business capabilities autonomously. Instead of having to orchestrate a large release to offer new features, a new business capability can be added by simply adding a new service.

Eventually, you end up creating 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 even try to shortcut our way to success by purchasing platforms and tooling centered around building microservices.

One of the best ways to reduce the risk is to educate ourselves behind the principles of microservice and the role of DevOps within it. So here are three reasons why you should start with DevOps.

#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, then it’s likely that there are front-end, a back-end, and a database teams. If your organization is structured in a way that doesn’t mirror a set of independent and autonomous services, then it probably won’t be capable of building microservices.

Could you build small services with large horizontal teams? Sure, but the teams could very quickly be swarmed with micro-tasks in order to support a microservice architecture.

#2: Without DevOps, you might be worse off than before

If you don’t start with DevOps, teams can become less independent than they were before. Productivity can grind to a halt because development teams can’t deploy their code. Quality Assurance teams could become bottlenecks because of all the untested code hitting their backlogs at once.

Defect counts 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. This would be highly cumbersome, especially with the addition of new services and new team members. Developers would have to interrupt each other constantly to help others troubleshoot and run their services.

#3: Microservices is just DevOps in practice

A microservice architecture is a natural progression of embracing DevOps. A successful DevOps practice results in continuous integration and delivery, automated testing, and applying monitoring and telemetry. There are many more benefits of DevOps but to touch on a few:

Continuous integration and delivery

Teams build and package their services without having to rely on other teams/departments in the company, and release often without impacting other teams.

Automated testing

Teams know immediately if there’s a regression in their service, and are encouraged to write unit tests because that’s the quickest way to get feedback.

Advanced monitoring and telemetry

Issues are narrowed down to a microservice quickly, reducing the constant need for escalations to get issues resolved. With teams responsible for supporting their own service, they are encouraged to experiment and improve their services while measuring their performance.

Nebbia, DevOps, and microservices

At Nebbia, we enjoy helping companies implement DevOps practices to help attain business agility and streamline their software development processes. We’ve also started to think about microservices and the role of DevOps within this movement.

We want to help you gain business agility by leveraging a DevOps and microservice practices, so contact us if you need a guide for the journey ahead.

If you need help with DevOps consulting, custom software development, Azure, or training, get in touch

Discover more about applying DevOps processes to the database on the Redgate solutions page