Stop Turning Success Into Failure With Microservices
Your application is a large application. You have lots of customers, and they make good use of your system. Your application has lots of capabilities and features. All seems well. Except it’s not.
You have a major problem.
Your application crashes a lot. This results in downtime and outages. You have dissatisfied customers who are unable to use your system. You lose money, and you lose customers.
And you are losing employees. Your developers work hard to keep the application going. They respond to pages at all hours of the day and night and fix problems regularly. They spend so much time working to put out fires that they don’t have any time to find the root cause of the problems. All they can do is rapidly put out the fires as quickly as they pop up.
And forget about working on new features. That just isn’t going to happen anytime soon. You are in trouble, and there is no easy solution to this problem.
How Success Can Cause Failure
You have fallen into the trap that many software companies—and the IT departments of non-software companies—have fallen into. Business success has driven you to create larger and more complex applications. But they’ve become so large and so complicated that they are unwieldy. No single person can understand everything that’s going on in the application. Things break, and they take forever to fix. You try to add new or improved capabilities, and the changes are so intertwined that you can’t get them done quickly. When you make changes, the changes are buggy. Your development pace is slow and getting slower.
This state of affairs is not inevitable. You can build and rearchitect your application to scale with your company, not against it.
The problem is that your independent development teams aren’t truly independent because the changes one team makes greatly impact what the other teams are working on. You can’t work on independent projects because all projects are intertwined. Innovation is stifled, and so is your business.
Your business success has come at the cost of an application that is large, unwieldy, buggy and hard to support. Your success becomes your failure.
Leveraging Microservice Architectures
The problem is the huge, monolithic application architecture. Instead, using service-based architectures, you create an application where each service is independent and isolated from every other service. Each service is smaller, but there are more of them. Each service has a well-defined interface between them, and each represents a piece of well-defined business logic.
More importantly, each service has a single assigned owner. One development team is responsible for all aspects of each individual service.
The application is cleaner, and the ownership and responsibilities are clearer. In short, your application has scaled. Not scaled in the sense of the number of customers it can support but scaled in the sense of the number of independent developers, projects, and initiatives it maintains to support your growing business. Your dev teams aren’t stepping on each other’s toes, and hence, they are more productive overall. Morale is higher, and you end up with lower attrition because your developers aren’t stuck working in a spaghetti-like monolith. They are working in a smaller and more nimble code base that allows them to be more creative and productive.
Also, if a problem occurs, it’s much easier to see which service is causing the problem. Rather than pulling everyone in to try and find a problem, you know which service is having problems, and only the service owner needs to be involved in the solution.
Teams are more focused, and hence, they can be greater experts in the areas of concern they are responsible for.
Microservices Help you Scale
Microservices architectures help you scale in many different dimensions. In particular:
- Traffic and customers. Microservices enable you to support more customers with more traffic and more data by distributing increased load across services that can be scaled more quickly and independently from the rest of the application.
- Number of developers and development teams. Microservices enable you to add more development teams and, hence, more developers to your application. Ownership assignments make it clear what you need to work on. APIs mean clearer boundaries of responsibility. Each developer is more productive because they aren’t stepping on the toes of the other developers as much as with a monolithic development process.
- Complexity and capabilities. Teams have less of an application to consider, allowing them to work on more complex problems within their domain. With more teams working on more problem domains, more complex projects are possible.
The cost of microservices
Microservice architectures do come at a cost. While individual services are easier to understand and manage, the application has significantly more moving parts and becomes a more complex beast. This can lead to application complexity and the problems it brings in other aspects of your application, and these issues should not be ignored.
Make sure before you undertake a migration to a microservices architecture that you understand the costs and benefits and that you have proper expectations set in order to make the transition—and your future state application—a success.
