Introduction to Microservice Architectures

Microservices are the new hotness when it comes to software architectures. Although the term is already around for a few years, there’s still no standard definition or consensus on what it really means. However, lately it has gained far more attention being used as the architecture pattern of choice at companies like Google, Facebook, Twitter, Netflix and many more prominent technology companies and startups.

And all this attention is not unfounded, microservices are the perfect fit for the nowadays common agile software development process to enable faster, better delivery of value. Combined with agile the microservice pattern enables not only continuous delivery in engineering, but with that continuous innovation on the product, while being more efficient in terms of engineering as well as server resources.

The Basics: What are Microservices?

Its "enemy" is the architectural monolith, the big software application, that has grown over time and that is hard to maintain and evolve. As mentioned above we are still in the early stages of defining microservices. There’s is many discussions as to how “micro” a service should be, if data should be part of each service, and if “micro” is actually a good word, as with decoupled services there’s a natural limit to the lower barrier of a service in terms of size.

As a working definition we use:

In microservice architectures, applications are built and deployed as simple, highly decoupled, focussed services. They connect to each other over lightweight language agnostic communication mechanisms, which often times means simple HTTP APIs and message queues. Services are built around business capabilities and independently changeable and deployable with only a bare minimum of centralized management. They are polyglot in terms of programming languages, frameworks, and data stores used. Lastly, microservices are resilient, which means they are immutable artifacts that are designed to fail and elastic in scale.

This definition helps us get a better feeling of the charecteristics that we want to achieve with microservices, but is not too dogmatic about specifics, so that there's some freedom of choice left for each use case.

The Benefits: Why Microservices give you super powers?

So why are microservices such a hot topic these days? Basically, there’s four benefits that come with this new architecture pattern - mostly stemming from the higher rate of decoupling between services:

  1. Decoupled services give development teams the freedom to use any language and framework as well as data storage technologies they deem best for the problem at hand. They might choose Golang for a massively parallelized backend service, but ClojureScript for a dynamic user-facing front end.
  2. With this decoupling come also small, independent teams (e.g. Amazon’s “two pizza teams”), which need only little coordination between them and thus can move independently.
  3. As microservices can be built and deployed independently, they enable faster, more agile development cycles and fully automated deployment processes.
  4. Independent deployment also means that microservices help companies deploy different services on different infrastructures (e.g. private vs. public cloud) as well as deployment on clusterized infrastructures that enable high scalability and resilience.

All of this boils down into microservice architectures that enable companies to scale their products and add or adapt services easily. Companies can deliver software faster and more efficiently in order to compete on the dynamic markets of today and tomorrow, while at the same time keeping their products fast, secure, and stable.

The Challenges: Why are Microservices not a free lunch?

However, microservices are not a free lunch and there are many challenges when moving to this new pattern. The complexity of microservices in the real world and the many hurdles we have to take to make microservice architectures a reality are not trivial. Especially, the significant operations overhead and the substantial DevOps skills required to get microservices running, but also the implicated problems that arise when trying to split up a monolith or even new app into many (small) microservices, e.g. implicit interfaces, increase in complexity, testing issues, and asynchronicity, are just the beginning.

Basically there are two categories of problems arising with moving to microservice patterns. One is software architecture mindset/pattern related problems, e.g. how do we define a microservice, how big or thin should it be, how is communication handled, etc. The other is deployment and operations production related problems, e.g. increased complexity, DevOps skills, etc.

The first category are common problems with moving to new patterns, same as moving from procedural to object-oriented programming before. However, these problems are slowly but surely getting smaller with defining articles and books as well as more and more microservices meetups around the globe.

The second category is one that is not that easy to solve and it only gets worse when deploying to clusters instead of single servers. Suddenly you need orchestration, service discovery, load balancers, circuit breakers, etc. that handle running and connecting your neatly packaged microservices.

The Solution: Containers and Microservices

This is where container technologies like Docker come into the game. Docker and similar (or future) container technologies can help with at least some of the problems (especially when it comes to making boundaries between Dev and Ops more explicit and offering a means of communication for both groups). However, many of the problems still remain, especially when it comes to production and deployment. Handling your operations yourself is already quite some work without microservices, but with them the work increases manyfold.

Like many things on the business side it comes down to a make or buy decision. Big technology companies like Google, Facebook, and Netflix decided to build it themselves and they run very successful businesses on their infrastructure. However for companies with less than 100 developers the decision for a do-it-yourself microservice infrastructure implies a significant investment into infrastructure and operations knowhow and staff, which usually does not result in any added value on the product side.

About Giant Swarm: Your Production Microservice Infrastructure

Thus, we at Giant Swarm thought we should build something for the rest of us, who are not working at these big tech companies. We work with you to build and run a powerful microservice infrastructure that lets you deploy, run, and scale your containerized apps resiliently - integrating and automating proven open source software with our own custom tooling to let you focus on building microservices without having to take care of the glue in between them. Learn more about our services and products or contact us directly.

More about Microservice Architectures in our blog