“What? You never heard about microservices?
Over the years, this subject had his time to cool down a little bit.
But for many, it’s still considered as the highest achievement in IT project architecture styles. We decided to put our hands on it, and give you a glimpse of our approach, its appliance in the web app and our thoughts about this subject.
“Where has it been all my life?”
Before we start to judge over microservices we’ll give you a small background to them. Microservices architecture idea was introduced to the world at the beginning of this decade.
Basically is an approach of developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. We like to look at microservices as an organism. Each organ has its own purpose and function. All of them together forms organism.
To visualize it better we will compare it with opposite implementation of tactics which is monolith (single large unit). We use hypothetical video streaming platform as an example.
The first system represents a single large unit with all functionalities in it. The second is a set of small, specific services, with specific roles. Although this diagram is the simplest, highest level of detail possible, you can clearly see a difference between them.
You can also imagine a whole list of benefits in using the microservices approach.
First of them could be a possibility for small development teams, working on independent components. Without taking care, or even know about other components. And because it’s much easier to learn the code for only a small part of the system, the amount of time for onboard new developers is greatly reduced.
Each individual component can also be developed in different programming languages. You can choose the most suitable technology for wanted functionality and deploy them independently. This allows new features to be released in a faster, safer and most relevant way.
And because each small component fulfills a small, specific function, they can easily be reused in other systems, services or products. They can also be scaled independently, which make this process more efficient and less expensive.
And now imagine hearing it all for the first time. The fancy conference with some Netlflix or Amazon DevOps guru, praising over it. It was just impossible to not just fall in love with it.
When the emotion subsided…
If microservices are so great, what’s the big deal, right? Why anyone would even consider not using them in their systems? Well over the last few years multiple “microservices systems” were developed, with multiple “development hell” stories at the same time. As it turns out it isn’t as painless easy and cheap solution as it was promised.
The Microservices structure caused a huge explosion in complexity. For the teams that were responsible for developing and maintaining that kind of a system. Very often when developers were trying to create or test a new feature, that span many services. It was necessary to run them all on a local machine or connect to them. It’s turned to be way more time consuming than simply run a single program.
Having many small teams working on separate systems, made versioning of them, a hard to coordinate issue. Very often updates on one service required synchronized updates on a couple of different ones. In some cases you could even see 2 running versions of one microservice, just to keep the system alive.
Unfortunately, scaling didn’t get in microservices any easier either. Microservices aren’t scaling by themselves and this task is still challenging, and hard. It’s safe to say that if someone can do it properly on microservices, he would be able to do the same on the monolith. It was pretty fast to realize that those systems will work only when done by experts.
More services mean more communication paths, a much more complicated networking arrangement, and more areas of potential failure. Don’t get us wrong. Microservices are great, but to structurize and maintain them, in a safe and satisfying way, serious expertise is strongly required.
Context is the key – the microservices golden mean
Most of the time, when people discussing microservices subject, you can see a tendency to focus only on two ends of that spectrum.
Many tiny applications, passing many messages to each other, at one hand and a giant monolith doing many things, on the other. And this is good only for discussion. For any real system, there are many possible service-oriented architectures between those two extremes. It’s important to choose architecture that the best fits for the project and the one that developers are comfortable with.
So if you building a new product, that it’s likely going to change and evolve over time. Or your team is at the founding stage and have no microservices experience a monolith will be ideal to way to start the project. Over time you can separate some parts of it into smaller services, and there is nothing wrong with that. Believe us, many big systems still working like this, and they’re doing fine. Microservices architecture is a great technology, there are no doubts about that.
But just like many other “new revolutionary technology”, there is a price for their greatness. We don’t like to look at them as an answer, but just another great option.
If you feel like talking to us about this topic a bit wider, we will gladly do it! Don’t hesitate and write to us!
Andrzej Kopera • Sep 05
