what are microservices and why should we use them?

Stealing a quote straight from this article.

In short, the Microservice architectural style is an approach to 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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralised management of these services, which may be written in different programming languages and use different data storage technologies.

I think that covers the "what" quite well.

The "why" is where things get a bit complicated. As with a lot of approaches to software architecture, folks tend to take every idea and think it's a cure all for every issue you have with your current architecture.

I'll save y'all a bunch of time and pain and say it now: Microservices are not a cure all. In fact, there are plenty of instances where defining, building, and maintaining Microservices will hurt you, not help you.

But for every case where they don't makes sense, there's a case where they do.

Do you have a huge monolithic application that takes hours (or days) to deploy? Does it need to frequently change to keep up with new requirements? Do you find that those changes tend to live within one or two small pieces of the monoliths overall functionality?

Well damn! You've got yourself the perfect use case for Microservices. Break out those ever-changing pieces of functionality into their own isolated, independently deployable services and witness the wonder that is not having to redeploy the whole damn application for every little change you make.

Generally the best advice in regards to Microservices is to start with a monolith. As and when you start to face issues like those I described above, it's time to think about splitting your monolith up. In simpler terms, like any optimisation, you shouldn't do it until you've got measurable evidence of a problem.

There are also other factors that affect whether or not Microservices are right for you, like the technical maturity of your organisation, that are better explained here, where the CTO of ThoughtWorks (where I work) explains why we haven't placed Microservices into the "Adopt" ring of our technology radar.

For those not familiar with the radar, "Adopt" means we think this is a technology or approach that you should be using today.

I would be very careful about taking the microservices approach; I had a bad experience with these years ago due to the over-use of them.

A client hired a system architect consultant in addition to our company to develop a new system for them, even though we had delivered some very successful and stable systems to them before with similar requirements which could be classified as monolithic MVC apps.

Rather than take the same approach to the architecture the consultant had his mind fixated on microservices and that they were the solution to everything - that every part of the system had to be a microservice, even though only one thing in this new system needed to be shared with others.

As such this meant that in order to do anything, in order to CRUD on any screen, the app had to talk with multiple web APIs for all these microservices.

Of course the round-trip process of creating, sending a web request, then receiving and decoding a request in the service, doing a DB lookup, creating XML response and then sending it back to the app for it to decode and use meant the whole system was very slow and clunky.

Also reporting became almost impossible because a number of tables which needed to be joined in SQL queries ended up in different microservices and there is no way we were allowed to directly query the DB of another microservice - all were strict silos/self contained things. I left that company and the project years before it was finished so would love to know how they solved that one.

One of the dumbest things was that all these microservices actually ran on the same server so there was no benefit at all over a single MVC web app especially given the number of users was not likely to rise so scaling was not going to become a problem.

Finally the project took years longer than needed - I heard from one of the devs I worked with at that time when exactly it did go live and was quite astounded, I am sure we could have completed it during my time there if it had not been broken in to all these little pieces and completely over engineered.

I would very carefully consider if microservices are needed and if so use them sparingly. Perhaps a monolithic with an API attached to the side is all that is needed instead.

When I hear "Microservices" I can't help but think "Warning warning - Will Robinson"

Sometimes software libraries or resources don't physically fit on the same server. So you put them on different servers. Also forcing people to do this prevents monolithic applications which can also be good.

Structuring applications to use libraries and components that communicate over network by default, rather than linking, is the microservices style.

This is my notes on why you should not use microservices (yet) - github.com/devkini/notes/wiki/Why-....

You should not use microservices when data is highly coupled.