What I Think About When I Think About Microservices

Over the past few months I've been learning a lot about microservices. The idea behind what microservices are and what they accomplish is defined in detail in this 2014 article by Martin Fowler and James Lewis. If you want to know more, there are some fantastic talks on the subject available on the world wide web. Go have a listen.

Simply put, microservices is an architectural style that structures an application as a collection of loosely coupled services, which implement independent functions (each having a single responsibility). The reasons are to allow easy independent horizontal scaling of applications, smaller development teams and adoption of a diverse technology stack. And a whole lot more.

The theoretical ideas coupled with the vast tooling available today can quickly make it overwhelming for those (like myself) looking to begin. This tooling also revolves around a lot of ancillary technologies and techniques that lend themselves well to this architecture.

To Container Or Not To Container

A lot of the information around microservices will have mention of Docker.

If you don't know what Docker is, stop reading and go watch this "Lightning Talk" by Solomon Hykes at PyCon 2013. Five minutes that basically marked the beginning of a revolution in how applications are packaged and deployed today. I'm sure you'll be further confused (unless you know Linux Containers) and curious once you watch this video.

Now, a very important thing to keep in mind is that the microservices architecture can be realized in two ways:

Using application frameworks with built in patterns (e.g. centralized configuration management, service discovery, circuit breakers, etc.) available with frameworks such as Azure Service Fabric and Spring Cloud. Azure Service Fabric provides the deployment model along with the programming constructs. Spring Cloud constructs need to be coupled with any PaaS Provider such as Cloud Foundry.
Using containerization technology, i.e., packaging applications in containers (Docker) and then deploying and maintaining them using orchestration / choreography tools (Kubernetes).

One is an Application PaaS while the other is a Container PaaS.

The distinction between the two is that an Application PaaS like Cloud Foundry has a staging layer that takes a (12-factor) user application (e.g. jar or gem) and a Heroku-style buildpack (e.g. Java+Tomcat or Ruby) and produces a droplet (analogous to a Docker image). Cloud Foundry doesn't expose the containerization interface to the user, but Kubernetes does.

While, using a Container PaaS can remove the limitation of following a prescriptive framework with an Application PaaS, it also means that many of the additional microservice capabilities such as API Gateways, Configuration and Discovery need to be done using separate tools and wired together.

Examples:
API Gateway - Kong, Tyk
Service Discovery & Key Value Stores (Configuration) - Consul, etcd, Zookeeper, Eureka (Eureka is not a KV Store)

(I also see that it's possible to have a Container PaaS over an Application PaaS without using the programming models available. There must be reasons for doing so, but I haven't come that far.)

Programming Models

There is also a lot of information regarding using opinionated application programming models to write individual microservices and handle communication between them.

You will encounter terms such as Reactive Programming, Event Sourcing, Actor Model, CQRS, etc. For example Akka and Azure Service Fabric provide such constructs to develop concurrent and distributed applications.

Their usage is independent of the above strategies discussed in microservice implementation.

These are just a few observations I've made during this time. Microservices is a vast topic once you get started and one that demands a lot of learning. I hope this article helps to clarify where some of the tooling around microservices today fits.