Microservices is not a new architecture style. Back in 2014, Martin Fowler and James Lewis published a post defining microservices. One year later, Kubernetes (the most popular container orchestration at the moment) was open-sourced by Google. In this Refcard, you will find an introduction to these technologies, as well as the essential characteristics and design principles of microservices in an orchestration world. This Refcard will also dive into monitoring and logging, which are essential tools in distributed systems like microservice architectures.

Microservices is an architectural style where every piece of a system lives separately, as an individual service — rather than condensing all the different parts of a system into a single, larger service, as happens with traditional monolithic architectures. It is useful to keep in mind that microservices should not mean as small as possible, but rather should be taken to mean as small as necessary.

Having multiple services instead of just one brings increased levels of complexity. It adds such questions as: Which service should we update first when it's time to update, especially when there are several services to update simultaneously? There are so many pieces now that automating the deployment of each service becomes a requirement. If there are issues in production, which service is a problem or is causing a problem? Good observability is needed to spot the issue is an imminent need when working with microservices. It seems that with monolith systems, things were simpler. So, is it worth having the additional complexity of decoupling a monolith into several microservices? Sometimes it is, especially when working with systems utilizing Kubernetes in the containers world.

This is page 1 of the Microservices on Kubernetes Refcard. To read the full Refcard, you can download the full PDF above.