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.
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.
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|
This is a guest post from Nebbia Technology. Nebbia Technology is a software company based in Orlando, Florida, that specializes in Azure-based solutions and DevOps best practices. We bring together top professionals and provide them with the right environment and tools to produce amazing products and solutions.
Our team is well known in the industry as some of the best Microsoft-focused professionals. We have a cloud-first focus and we partner with our clients to help them get the most out of their Azure investment.
Also in DevOps
CALMS is the acronym for a framework which allows businesses to assess how prepared they are on their journey to DevOps, and where they can improve. CAMS (without the L) was first introduced by Damon ...
Also in Blog
Back in 2017 Redgate acquired Net2000, a leading provider of data masking solutions for SQL Server databases. Since then, we’ve invested heavily in the data masking tools to ensure our customers can...
Also about Nebbia Technology
Release Day used to mean weekends spent deploying the latest code, database changes, and website content. Release teams would huddle together in war rooms troubleshooting issues, deploying hotfixes, c...