Your application is great. It has many clients and they make good use of its many functions and capabilities. They have a large product catalog and their store is large and feature rich. You’re doing it right.
Except you’re having trouble.
Your app crashes too often. Your developers are always aware when it fails, and they are very quick to fix your site, but it takes time and energy. You are depressed at least once a month, and you can be depressed for hours. Imagine the lost business.
Your developers would like to fix the problem, they would like to do a lot of things. They keep talking about these great new features that they would like to implement, but just can’t. They are too focused on bug fixing and fire fighting.
You’ve talked about hiring more people, but your budget doesn’t support it. Also, you are constantly hiring to replace people who are leaving. Judy went to a bigger tech company. Joe left because he was exhausted from handling too many late-night emergencies.
Technological problems weigh you down and weigh on your team. You don’t see any way out. You and your company are trapped.
You have fallen into the trap that many software companies and many non-software IT departments have fallen into. They have created large, monolithic applications that seem to handle everything. But these applications have become so large and complicated that they are difficult to handle. Nobody can understand everything that happens in the application.
Things break down and take forever to fix. You try to add new or improved capabilities, but the changes are so intertwined that you can’t make them quickly, and when they are complete, they are full of bugs. Its rate of development is slow and increasingly slow. You try to add more developers, and they don’t seem to make things go any faster. And the learning curve for new developers is incredibly steep.
You are trapped in the mud.
Mud is not inevitable. You can redesign your application to scale with your company, not against it.
The growing application
It got off to a good start with a simple app, written and managed by a single person or a small development team or two. Its application looks like Figure 1, nice and simple.
But time passes, the application grows. Your application is a success and your traffic increases dramatically. Add new features and capabilities and hire more developers to work on the app. Soon, it will look like Figure 2.
Now you have problems. Nobody knows what parts of the application they own. Team 1 makes a change and impacts team 3. Tensions are high, productivity is low. Bugs creep into the app and your site starts crashing, seemingly at random. And when there’s a glitch, your teams struggle to figure out what’s wrong, because no one person can understand everything that goes on in the app. This is an excellent example of dirt.
Your independent development teams are not really independent, because the changes that one team makes has a huge impact on what the other teams are working on. You cannot work on separate projects, because all projects are intertwined. Innovation is stifled and so is your business.
The value of microservices
Now take a look at Figure 3.
Here, each service is independent and isolated from all other services. Each service is smaller, but there is more. Each has a well-defined interface between them and each represents a well-defined piece of business logic.
More importantly, each service has a single owner. A development team is responsible for all aspects of each individual service.
The app is cleaner, making ownership and responsibilities clearer.
In short, your application has been scaled up. Not scaled in the sense of the number of clients you can support, but scaled in the sense of the number of independent developers, projects and initiatives you maintain to support your growing business.
Your development teams are not trampling each other, and they are more productive because there is less dirt involved. They are happier and more likely to stay with the company longer.
Additionally, you can increase the number of development teams, and therefore the number of developers, simply by rebalancing ownership responsibilities. More developers become more productive, and you can progress better on those critical business projects that are critical to your growing business.
And if a problem occurs, by analyzing the interaction between services, you can much more easily determine where the problem originates and which team to fix it. In addition, each team has a much smaller set of responsibilities, therefore a greater understanding of how the services they are responsible for work, so that they can solve problems much faster and much more effectively. And because they better understand the areas for which they are responsible, they are less likely to introduce bugs into the system.
Microservices help you scale
Microservices architectures help you scale in many dimensions:
- Traffic and customers. Microservices allow you to support more customers with more traffic and more data.
- Number of developers and development teams. Microservices allow you to add more development teams, and therefore more developers, to your application. Developers are more productive, because they don’t step on each other’s feet as much as in a monolithic development process.
- Complexity and capabilities. Teams have less application “surface area” to think about, allowing them to work on more complex problems within their domain. With more teams working on more problem domains, more complex projects are possible.
Single Computer Oriented Service Architecture (STOSA)
It is not enough to move your application to a microservices-based architecture. It’s still possible to have a microservices-based architecture, but have your development teams work on projects that span services and create complex interactions between your teams. Bottom line: you can still be in the trouble of development, even if you switch to a microservices-based architecture.
To avoid these problems, you must have a clean service ownership and responsibility model. Each and every service needs a single, clear, and well-defined owner who is fully responsible for the service, and the work must be managed and delegated at the service level. I suggest a model like the Single Team Oriented Service Architecture (STOSA). This model, which I talk about in my book Architecture for scale, provides the clarity that allows your application, and your development teams, to scale to fit your business needs.
The cost of microservices
Microservices architectures come at a cost. While individual services are easier to understand and manage, a microservices application as a whole has many more moving parts and becomes a more complex beast on its own. This can lead to application complexity and the problems that complexity brings to other aspects of your application, and these problems should not be ignored.
Also, many stagnant companies (as shown in Figure 2) will start a project to migrate to a microservice architecture (as shown in Figure 3). However, they will often find the transition more difficult and more expensive than they expected or anticipated. And so, in the middle of the migration, they abandon the effort. They have partially migrated and are often in worse shape than when they started.
Before embarking on a migration to a microservice architecture, make sure you understand the costs, benefits, and future challenges. You must have the proper expectations in place for the transition, and your future status request, to be a success.
Copyright © 2021 IDG Communications, Inc.