In the movie Despicable Me (amazing movie – if you haven’t watched it yet, watch it now!) the supervillain Gru employs hundreds of Minions to build a rocket to reach the moon. Minions are small cute yellow creatures and they don’t do much – but when they are organised to do work together, they could even build a rocket.
Microservices are like Minions working together: small services when organised to do work together can result in large applications that are scalable, understandable, and maintainable.
What are microservices? It is
1. an architectural style in which
2. complex applications are composed of small, independent processes
3. that typically communicate over REST (Representational State Transfer) API
Remember movies such as “Endhiran” and “Big Hero 6”? In these movies, a larger robot is organised out of smaller robots. These robots have a way to communicate with each other. In case of micro services, communication is typically done using REST (REpresentational State Transfer) API, i.e., those GETs, PUTs, DELETEs, and POSTs over HTTP.
The underlying philosophy behind micro services is Single Responsibility Principle (SRP): “do one thing and do it well” (read it in Yoda’s voice).
If you are familiar with Unix pipelines, you already know how simple commands like “ls”, “head”, etc. can be combined together to create a “tiny application-like” functionality. Here is an example:
cat file.txt | tr -s ‘ \t\n\r\f’ \\n | sort | uniq -c
It counts the number of times words occur in the given text file. Cat displays the file, tr translates, sort does sorting, and uniq removes duplicates (and -c option displays the number of times that word occurs). What is important to observe here is the commands like cat, tr, sort, uniq “do one thing and do it well”. But not just, they have an uniform communication mechanism – as text input and output – and they can be “strung together” through “dumb” pipes.
Microservices are analogous to that in many ways. Just like Unix commands, microservices are “stateless”, i.e., services does not “remember” anything from earlier calls. Each service does one thing and does it well; instead of text, they communicate over REST.
The concept of microservices emerged from SOA (i.e., SOA: The Good Parts), and hence one way to think of micro services is “fine-grained SOA” or “SOA 2.0”. In other words, SOA without its complexities like ESB (Enterprise Service Bus), WS* protocols, large services, etc.
So, how big (or small) is a service in “microservice”? A popular answer: Each service should be manageable by a team that can be served by a pizza or two (“two-pizza” rule).
Microservices are organised around business capabilities that are addressed by teams. This idea is reflected in Conway’s law: “Any organization that designs a system… will inevitably produce a design whose structure is a copy of the organization’s communication structure”. In a large monolithic system, it is harder for teams to coordinate and implement features, test them and maintain the software. However, micro services are organised around business capabilities. A cross-functional team should be able to manage each service independent of others.
An acronym you can use for how teams can independently manage microservices is DURS “Deploy, Update, Replace, Scale”; you can remember it with “Microservices = Damn U R Sexy”!
Services in this architectural style can be implemented in any programming language, including C, Go, and Java. This is possible because services communicate over REST API and the underlying technology is implementation detail that gets hidden.
Many large companies (mostly web-related ones) such as Google and Ebay use microservices. But it was mainly popularised by Amazon and Netflix.
There are many things one should be careful about when using microservices. For example, unlike monolithic structures, microservices expose a lot more functionality over the network and hence security is a key concern. In Claude Shannon’s words, “the enemy knows the system”, and with micro services it may be easier to exploit the system.
Hope this article provided you a simple overview of microservices. Here is a list of resources for you to get started:
1. Wikipedia entry for microservices
2. Martin Fowler’s article that provides an overview of microservices
3. Sam Newman’s book “Building Microservices”
4. Description of microservices architecture pattern
5. James Lewis on microservices in SE-Radio
6. Migration to microservices by Adrian Cockcroft (Netflix)
7. From monolith to microservices by Randy Shoup
(I am new to microservices. Following the idea “Try at least one uncomfortable thing every day”, I have written this article. So, thanks in advance for being kind with your comments!)
The presentation version of this article is available here.