Around the time Docker started becoming popular, software architecture was also evolving. The Service-Orientated Architecture (SOA) pattern was a common way of layering applications into services separated by a bus or other messaging system to allow each service to communicate with each other. The microservices approach follows the same principle of a loosely-coupled application and takes it a step further in terms of granularity.

Microservices focus more on decoupling an application, and the communication mechanism is lightweight and typically HTTP. The mantra of a microservice is that it should do one thing and do it well. Large complex applications can be broken down into components with a bounded context, meaning that developers think about building within a domain instead of a generic service. Think about the example of a new customer signup service using REST rather than an abstract data service:

Deploying independently means that development teams have the freedom to choose the runtime, define their own software life cycles, and choose which platform to run on. Naturally, containerization matches up on a lot of parallels. Containers make it easier to break the monolith into smaller applications that can be modular. Since we're now scaling at the microservice level, we can add more compute capacity by starting up more containers.

The DevOps revolution helped with the adoption of microservice application architectures as well. The benefits behind both industry trends included agility, deployability, scalability, and availability among others. Microservices allowed us to truly own what we built because we were already responsible for configuring and deploying all the tiers. When we apply microservices principles to the function level, we get nanoservices. Let's explore these.