This is the first part of a multi-part series of blog posts on Micro-services. There seems to be a lot of ambiguity amongst the community around what these things are, when they should be used and how to approach them. This blog series is basically a regurgitation of 5 years of building and learning about micro-services. I imagine that not everybody will agree with everything I say here, but I hope that there is nothing so controversial as to cause serious disagreements.
Part 1: What are micro-services?
Part 2: When should you use micro-services?
Part 3: Why shouldn't you use micro-services?
The most important thing when talking about micro-services is to ensure that when we are talking about them we are starting from a common starting point. I've tried in my career to live with a simple philosophy, 'When two smart people disagree, one of them is missing some context.' I wish I could remember who instilled that thought in my head, but, while it doesn't always hold true, it has certainly been a great boon to my professional relationships.
This post is targeted at making sure that when we have a conversation we are starting with the same context. What we'd (or more explicitly, I'd) like to do in this industry is avoid semantic diffusion. Even amongst my colleagues there seems to be much confusion around how micro micro-services really are. Or how macro? Or how Service? Fundamentally there is no one definition of what a 'Micro-service' really is. But, I believe that providing a single view of what and how they can work is very important and I'm going to use this blog post to do just that.
The first thing to cover is what micro-services are not. Micro-services are not 1 million services that make up a single service. (get it... micro = million... ha ha...?). In seriousness though, while one could write a Micro-service architecture with each REST resource being a single service, this can lead to a very confusing architecture. I'll discuss this more in a following post. Micro-services are also not many large services each covering a bunch of functionality and interacting via databases or an ESB in a large enterprise system. Instead, the truth, I believe, lives somewhere in the middle.
Another thing that is important to recognise is that micro-services are not necessarily independently deployable. Instead of focusing on the services being independently deployable, it is sufficient to choose groups of services that can be deployed independently. James Lewis describes this as a city layout and suggests that services that work together to provide a given piece or set of functionality should be independently deployable from other groups of services that provide a different piece or set of functionality. In his metaphor these groups would be akin to neighbourhoods within a city. The services within a neighbourhood do not necessarily need to be independently deployable. There are costs to deploying services independently and the pragmatic mind avoids independently deployable services unless it provides real value. Again this is something we will explore deeper in a later blog post.
When I chatted with James Lewis and asked him, "What is a definition of Micro-services?" his response was "fine grained SOA architecture done the UNIX way". That seems straightforward enough. Essentially we're talking about well defined piece of functionality that communicates with other well defined pieces of functionality via a well defined interface. The UNIX philosophy is to build things that do one thing, do it well and work together at a distance via pipes and filters. Taking this philosophy and applying it to a SOA architecture would imply building services that focus on a single piece of functionality and communicate with other services to provide business value.
Effectively, this is extending Bob Martin's Single Responsibility Principle to a service level. In practice, this is difficult to achieve, but in an 'ideal' world this means that a service only needs to change (and therefore be deployed) if the functionality it is responsible for changes. Very noble, but also very difficult as breaking a system down to that level of granularity might make it a maintenance nightmare.
The communication between these services should be over a well defined interface such as that provided by HTTP. Fortunately there is a compelling SOA architecture that provides us with the ability to provide a well defined interface over HTTP. REST has been floating around for a while and fits the purpose well. While it's not possible to achieve quite the level of decoupling that the UNIX philosophy achieves, proper REST with hypermedia goes a long way to providing this decoupling.
There are other protocols that could function in this space, and I do not want to claim that REST is the only one that fits the pattern. In many cases, other transfer protocols make more sense than HTTP. For the purposes of this series, and in general, I believe that REST is a very compelling integration technique that, done right, provides loads of value and takes micro-services from a challenging dream to a much more achievable reality.
So, with that context, let's try to define micro-services, or a micro-service architecture:
A system built using micro-services is a system that is built up of small, lightweight services, where each performs a single function. The services are arranged in independently deployable groups and communicate with each other via a well defined interface and work together to provide business value.
Copying of this content is allowed only with reference to the source and indication of the author of TQM systems' material.
Written by David
- Контент-маркетолог TQM systems Nataliya Raevskaya
- 6/4/2020 11:29:43 PM
-
enarticles, enblog
