Introduction to Microservices

As a Software Architect I have recently found my new obsession — Microservices. Mindset, so simple yet so elegant, that allows you to create a large scale software while still enjoying perks and benefits of writing a small software.

If you work for a big software company or one of the unicorn startups, you are probably pretty familiar with the whole concept and its pros and cons. As other goodies in life, Microservices are first used by early adopters, who are crazy/rich enough. Well, isn’t that an exact definition of an early adopter? After while, when a product/concept reaches its maturity or mostly when the technology is available to masses, others can start using it and afford it.

When we speak about Microservices, this point of mass production has come alongside with availability and affordability of cloud resources and SaaS & PaaS in general.

First let’s speak about the meaning of microservices.

“Microservices are small, independent processes that communicate with each other to form complex applications which utilize language-agnostic APIs. These services are small building blocks, highly decoupled and focused on doing a small task.”

In other words: you write lots of smaller independent programs to form a big one. Someone could think, it seems to be really infrastructure heavy as it must handle a lot of different applications on different servers and even in different environments. However, this huge barrier tends to disappear with the modern cloud approach and with a little money.

One simple example could be decoupling UI from your backend by creating a simple lightweight single page app in react for handling the UI and which communicates with the API. This is the simple example of microservice architecture and further more behind the API where could be hidden even more services

Advantages

In the other hands there are some treats you can get while using this architecture.

• Since each app is independent (or shares limited) resources, you can have blazingly fast rollout times
• Each part is highly decoupled
• Older parts are easier to replace
• You are not forced to use one programming language or framework just because the rest of the app is written in it. Just use the right tools! :)
• It is much easier for newcomers to start working on a simple service than on a huge monolith.
• It naturally forces you to think modularly
• Smaller boxes are easier to reuse

And I could go on and on. From my point of view I think that Advantages really outweigh the Disadvantages and this architectural concept is worth trying.

Disadvantages

From the definition itself you might think that this approach can bring you a bit of pain, while:

• It adds another level of complexity. (You have to keep in mind which service is responsible for which task)
• You have to manage multiple repositories and deployments
• You deal with latency and fault tolerance
• It`s harder to determine or move responsibility

- You have to balance graining yourself

Should I use it myself?

Well, in some form, you are probably using it right now. Do you use any 3rd party service for mailing or push notifications? That’s right! That is what microservices are about. Small services for each task to form one big ecosystem.

I would only discourage you to use it for really small projects where it could give you too much overhead.

Next time I will focus on examples of microservices and generally used patterns.