Microservices

Microservices are in many ways a best-practice approach for realizing service-oriented architecture.

A microservice in my mind is a small application that can be deployed independently, scaled independently that can be tested independently and which has a single responsibility.

Microservices is the coming together of a bunch of better practices from a number of different communities.

It is a combination of great stuff from the domain-driven-design community around strategic design, bounded context, subdomains, how to separate out your domains, and how to partition a very big problem domain into smaller domains so that you can manage them.

It's also taking a bunch of the better practices from operational automation and programmable infrastructure, development operations communities, cloud communities, and the integration communities.

There are certain things you need to get sorted out before you can put your first microservices system into production: monitoring, provisioning, and a devops culture.

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

Microservices are commonly known as an architecture for building scalable applications running in the cloud.

However, they also promise high maintainability due to smaller code bases and strong component separation, making them an interesting option for software modernization.

Microservices address the problem of efficiently building and managing complex software systems.

For medium-sized systems, they can deliver cost reduction, quality improvement, agility, and decreased time to market. For large cloud systems, they fundamentally change the rules of the game.

However, although microservices approaches offer substantial benefits, a microservices architecture requires extra machinery, which can impose substantial costs.

By breaking a system up into small well defined services, additional boundaries are exposed that were previously hidden.

These boundaries provide opportunities and flexibility in terms of the type and level of testing that can be employed.

Microservices aren't for every company, and the journey isn't easy. At times the discussion about their adoption has been effusive, focusing on autonomy, agility, resilience, and developer productivity.

The benefits don't end there, however, and to make the journey worthwhile, it's important to reap the additional dividends.

People often mistake the flexibility microservices provide with a requirement to use different technologies for each service.

Like all development teams, we still need to keep the number of technologies we use to a minimum so we can easily train new people, maintain our code, support moves between teams, and the like.

Microservices aren't defined by lines of code so much as by the scope and breadth an individual service covers.

And, no, microservices won't prevent your two-pizza teams from needing to have conversations with one another over that pizza.