Microservices from Systems Thinking Point of View
What is the difference between Service-Oriented Architectures and Microservice Architectures? — that seems to be one of the most popular questions in the software engineering circles lately. Why are we doing it? Is it just a marketing term?
There’s a lot of confusion around the term and everyone has their own definition of the latest trend in IT.
To make things even more confusing, I thought I’d dump my point of view on the Internet. There are probably some bits missing below and I still have a lot to learn about systems thinking, but I hope the post makes sense in general.
Systems Thinking and Emergent Properties
I’ve been reading about systems thinking for a while and found it a very interesting perspective on many aspects of life, software engineering being one of them.
In a gist, systems thinking focuses on relationships between components of complex systems. On a certain level of complexity, interactions between parts of a system cause new properties to emerge. Those properties are called emergent, as they are not exhibited by the components themselves.
Take smell as an example of an emergent property. There’s plenty of carbon, oxygen and hydrogen around us all the time, yet we can still figure out when someone’s having a bad hangover, because of the properties of C2H5OH exhaled by that person.
Because of the nature of the universe, systems thinking is more complex than that, but for now it’s enough to make the point about Microservices.
Why Microservices?
If we look at the circumstances when the Microservice Architectures emerged, we will find out why we needed a new (unfortunately misleading) term. I found Martin Fowler’s article a good place to start the exploration.
Here are a few things we didn’t have when Service-Oriented Architectures started appearing:
- good infrastructure automation tools
- disposable virtual machines
- rich selection of database management systems
…and a few others which I probably missed. Of course, there were exceptions, but it was not enough to trigger the evolution of a new pattern.
There are also components which we had for a while:
- distributed, fault-tolerant systems
- independent services as components
- product-focused teams
- protocols (HTTP was created in the 90’s) and proxies
Arrival and combination of the technologies from the first list with our knowledge from Service-Oriented Architectures caused a new category of software systems to appear: Microservice Architectures.
Microservices and Emerged Properties
Microservice Architectures exhibit some properties, which Service-Oriented Architectures don’t. Most important properties emerging from adding new parts to the system are:
- decentralized governance of services
- decentralized data management and polyglot persistence
- evolutionary design of services
In my opinion, systems that don’t have those properties don’t belong to the category of systems which people call Microservice Architectures.
Those are pretty powerful properties, if you think about it, although mostly organizational, not technical. However, they would not emerge without the newly added components, such as infrastructure automation and cloud computing.
Increasing Complexity
The question is — why do we need those new properties? Adding complexity for its own sake is not a very good idea.
The answer is —there are forces pushing the system to grow. They usually come from the business side of the system.
In the current economic system the goal of most businesses is to grow, especially when we’re talking about the IT sector. In order to grow, companies need to find more users, evolve the existing products and find new ones to expand even further.
At a certain level of complexity, the system finds it hard to grow and cracks start to appear. Sometimes the communication costs start being unbearable — it’s hard to make changes to existing components and experiment with new ideas. Sometimes the system just starts being unreliable.
Microservice Architectures provide new properties which companies can use to grow even further than before. Those properties help solve organizational problems by increasing the internal complexity of the system.
So what is this fuss all about?
For me Microservice Architectures are an approach for taking systems into the next level of growth. They solve a certain set of problems with tools we didn’t have when people discovered Service-Oriented Architectures.
Whether you have any of those problems is another thing. If your system is small and there’s no need to grow it rapidly, it is probably better to stay at lower levels of complexity than Microservices require.
As a last note, if you’re confused about Microservices having no relation to the emergent properties described above — you’re not the only one. I find the term unfortunate and easy to misunderstand, but here we are and it doesn’t seem we can’t do much about it anymore.
