“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.
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.
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.
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.
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.
Do you have a ready-made MVP for your web application and you’re just starting the first promotional steps for your business? Great! Then this entry is dedicated to you. We are happy to present to you our experience in working with large startups and beginning entrepreneurs. We’ve collected 15 tips for you that you can implement without any risk. 1. […]
Many entrepreneurs are afraid that the transfer of a business to the internet involves costly investments in hardware and software for remote work or a technological revolution that they cannot cope with. Fortunately, in the era of web applications, all processes have been optimized and you will be able to easily transfer your business to the internet! Reason 1 – […]
The phrase contained in the title “10x developers” can be taken literally and it can be said that there are actually programs that are able to do the work literally 10 times more effective than the rest. However, as you probably realize, it all depends on many factors, the specifics of the project, customer needs and the developer approach. After […]
When building an app, companies have usually three directions they can go with it. They can decide on native, hybrid, or cross-platform mobile app development. The choice depends on the business objectives and the main purpose of the product. Today we’re going to focus on the fourth option available which is a progressive web app and why you should choose […]