DEV Community

Discussion on: what are microservices and why should we use them?

Collapse
 
leightondarkins profile image
Leighton Darkins • Edited

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.

Collapse
 
mraza007 profile image
Muhammad

Wow a very well thought answer
I think that answers my question