1. Microservices

Software is consuming the world and becoming a core competency of nearly all businesses today, including traditional businesses whose focus is not specifically technical. A growing number of industries need software to remain relevant, and that software must be able to evolve at a rapid rate to meet the demanding needs of today’s fast-changing and competitive markets. The way we build and manage software continues to evolve as new technologies enter the market and we learn of new ways to build better systems. Many early concepts still hold true although others have simply evolved, or have been adapted to new technologies. New applications are showing up every day to meet the growing needs of consumers and businesses alike.

As we begin building a new application, the team and codebase are generally small and agile when compared to a more mature application. As new features are added to the application, the team and codebase continue to grow. The increased size of the team and codebase brings some new challenges and overhead that can begin to slow progress. The code becomes increasingly difficult to understand and reason about, leading to longer development ramp-up times. Enforcement of modularity becomes challenging, the encapsulation easily breaks down, and the application grows increasingly more complex and brittle, requiring additional coordination across the teams when changing features. Builds and testing begin to take longer and releases become more fragile, including a larger set of changes with each deployment. The smallest change to a component can require the redeployment of the application, which can take a long time to build, test, and deploy. If one component of the application needs to be scaled, the entire application needs to be scaled. Everything about the application is tightly coupled: teams, builds, deployments. This might not be a problem for some applications, but for large-scale applications that must evolve at a rapid rate, this can be a big problem.

For a long time now we have understood the benefits of componentization and encapsulation in software, but enforcement can be challenging. Through the recent DevOps shift we now understand the benefits of smaller incremental releases, and making the entire team accountable for the complete lifecycle of the application. When building large-scale applications, we understand the benefits of partitioning, and the cost of coordination on scale. As with applications, some organizations can also benefit from breaking down into smaller teams, helping to reduce coordination overhead.

Over recent years many organizations have begun to realize the benefits of decomposing applications into smaller isolated units that are easier to deploy, and structuring teams around those units. This decomposition of applications into smaller autonomous units is part of what is called a microservice architecture.