Microservices: what are pros and cons?

Question

What are pros and cons of using microservices in comparison with alternative architectures? Is there a rule of thumb when microservices should be used?

Answer 1

Pros

---

Sam Newman in Building Microservices, enumerates the key benefits of Microservices as following:

Technology Heterogeneity

With a system composed of multiple, collaborating services, we can decide to use different technologies inside each one. This allows us to pick the right tool for each job, rather than having to select a more standardized, one-size-fits-all approach that often ends up being the lowest common denominator.

Resilience

A key concept in resilience engineering is the bulkhead. If one component of a system fails, but that failure doesn’t cascade, you can isolate the problem and the rest of the system can carry on working. Service boundaries become your obvious bulkheads. In a monolithic service, if the service fails, everything stops working. With a monolithic system, we can run on multiple machines to reduce our chance of failure, but with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.

Scaling

With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle scaling everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.

Ease of Deployment

A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large-impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening infrequently due to understandable fear.

With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service, making fast rollback easy to achieve.

Organizational Alignment

Microservices allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity. We can also shift ownership of services between teams to try to keep people working on one service colocated.

Composability

One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes. This can be especially important when we think about how our consumers use our software.

Optimizing for Replaceability

If you work at a medium-size or bigger organization, chances are you are aware of some big, nasty legacy system sitting in the corner. The one no one wants to touch. The one that is vital to how your company runs, but that happens to be written in some odd Fortran variant and runs only on hardware that reached end of life 25 years ago. Why hasn’t it been replaced? You know why: it’s too big and risky a job.

With our individual services being small in size, the cost to replace them with a better implementation, or even delete them altogether, is much easier to manage.

Cons

---

The most important disadvantage of Microservices is that they have all the associated complexities of distributed systems, and while we have learned a lot about how to manage distributed systems well it is still hard. If you’re coming from a monolithic system point of view, you’ll have to get much better at handling deployment, testing, and monitoring to unlock the benefits. You’ll also need to think differently about how you scale your systems and ensure that they are resilient. Don’t also be surprised if things like distributed transactions or CAP theorem start giving you headaches, either!

Closing Remarks

---

Just quoting from Martin Fowler:

One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.

Answer 2

The pro's of micro-services are that your applications scale very well. You divide your application in tiny services. It's a hard thing to decide which bounded services you will need. But once you have done this, you can easy scale specific services up to multiple times (the services that actually get the most load) rather than needing to scale your whole application up.

Another advantage is that it is easier for new developers to start creating new features for your application, since everything is divided into these separated service --> Each service has its own (small) codebase.

The biggest disadvantage of using microservices are of course that there is a higher chance of failure during the communication between the different services.

The usage of microservices usually only starts paying off when your application is getting too big to maintain as a monolithic application. Try starting as a monolithic but keep your bounded contexts in mind while developing (try to keep it as separated as possible) to you can migrate to microservices if needed later on.

Answer 3

Advantages

1.Decentralized and Decoupled Architecture, using choreography rather than orchestration makes services publish-subscribe based and as a result fully decentralized

2.Do one thing and do it well (Unix philosophy), more focused and singular with very narrow functionality

3.Easy to have parallelism and load balancing, because of being more fine-grained from the business process point of view

4.Statelessness, however, having a stateful Microservice is valid but it is not the ideal

5.Individual data storage makes services relaxed to keep tracing the data-flow

6.Easy and automated deployment and discovery due to use of container engine-based technologies such as docker

7.More interoperability, which makes services able to have more flexibility in accepting/dropping a new/current service or protocol

8.Fully compatible with Representational state transfer (REST) which allows creating stateless services

9.Suitable for discrete systems, for example for batch automation process

Disadvantages 1.Service synchronization, keeping services synchronized in a cooperative way

2.Difficult to find systematic problems, for example, finding a problem in a chain of business activities when there is a logical error in the process is more difficult and it requires to combine several log files into one piece

3.Automated deployment and discovery is a must when the number of microservices is more than a few

4.Difficult to find the right service granularity, which can lead the entire system into instability due to overwhelmed network communication and error rations

5.Challenging when the business system is not discrete enough, like continues process control

6.Developing an automated test is significant difficult than monolithic systems

Following are a set of articles that published about microservices in code-project, you can read and comment on your questions if you like.

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-II https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III

Answer 4

We can say deployment is easier for micro services but any change has to be additive only. because anybody who depends on it can fail. So the separation of concern is not there as much as like to. Also, tracing failures is no fun. Also during development, requires something available all the time for others to be able to make a call. otherwise development suffers. With monolithic application, we know what is there. But with distributed world no one know what is there or if anything even exists.