This is the first part of a two part series on microservice architectures, how they are used in application development and the role that APIs play within them. The second part looks at what distinguishes a typical Web API that you might add to your enterprise from a microservice (with an API) and when the two approaches make sense.
Traditionally, software developers created large, monolithic applications. The single monolith would encompass all the business activities for a single application. As the requirements of the application grew, so did the monolith.
In this model, implementing an improved piece of business functionality required developers to make changes within the single application, often with many other developers attempting to make changes to the same single application at the same time. In that environment, developers could easily step on each other’s toes and make conflicting changes that resulted in problems and outages.
Dealing with monolithic applications often caused development organizations to get stuck in the muck, resulting in slower, less-reliable applications and longer and longer development schedules. The companies who create those applications, as a result, end up losing customers and money.
The muck is not inevitable. You can rebuild and rearchitect your applications to scale with your company’s needs, not against it. Using a microservice-based application architecture is an increasingly popular technique for building applications that can scale without miring your organization in the monolithic muck.
From Muck to Microservices
This is how many applications start out. A simple application is written and managed by a single development team. Nice and simple. This may very well be how your application looked like at one point:
The Growing Application
But then your application grows…and grows…and grows. Your application becomes a success; traffic and usage increase dramatically. You add features, and more and more developers are brought in to work on it. Before too long, your application looks more like this:
Your once-simple application has become large, complex, and intertwined. You now have multiple independent development teams working on it simultaneously. These presumably independent development teams are actually not independent at all, since they are working on the same code base and changing the same sections of code.
The example above shows five independent development teams, working on overlapping areas of the application. It is impossible to know who is working on what piece of the application at any point in time, and code-change collisions and problems are easy to imagine. Code quality—and hence application quality and availability—are likely to suffer. Additionally, it becomes harder and harder for individual development teams to make changes without having to deal with the impact of other teams, conflicts with incompatible changes, and an overall molasses effect to the organization as a whole.
But what happens if you construct your application using techniques more like those shown below:
This diagram shows the same application constructed as a series of microservices. Each microservice has a clear team owner, and each team has a clear, non-overlapping set of responsibilities.
What are Microservices?
Microservices are a software architecting pattern that allows software to be developed into relatively small, distinct components. Each of the components is abstracted by an API(s) and provides a distinct subset of the functionality of the entire application. Each individual distinct component, or microservice, can then be designed, developed, and managed independently. This allows for distributed ownership of a large application across a large organization, with each microservice owned by a specific team.
Microservices for Scaling
Microservice architectures let you split applications into distinct domains, each managed by individual groups within your organization. By using well-defined, managed and documented APIs between them, they support the separation of responsibilities critical for building highly scaled applications, allowing work to be done independently on individual services without impacting the work of other developers in other groups working on the same overall application.
This article is continued on page 2.