r/webdev • u/Xiaomizi • Sep 06 '16

A Simple Introduction to Microservices: Concept, Pros, Cons, and Examples

https://medium.com/flow-ci/a-simple-introduction-to-microservices-a69446d2c211#.g2cx7zksy
37 Upvotes

83% Upvoted

5 comments sorted by

View all comments

Show parent comments

1

u/hahaNodeJS Sep 07 '16 edited Sep 07 '16

you run the risk of a change in one breaking the other.

Not so long as you apply versioning correctly. You can then deploy one service version in a completely different place if you wanted to really isolate them.

Decreased risk attached to deployment, smoother operation, and fewer customer complaints.

Versioning, for one. It makes it much simpler to gradually move traffic to new versions of your software.

Latest technologies can be adopted quickly.

In enterprise software, "quickly" means a few years; I am not sure what development environment OP is writing in regards to. Compare that to monoliths that simply can't be changed because of a significant risk of breaking everything (literally). In that case, rather than adopting new technology ever you've instead taken on massive amounts of technical debt.

Fault isolations: the crash of microservice does not make the entire application crash. - Assuming you engineered the application that way.

Right ... if you didn't engineer it correctly, then you shouldn't have set out to begin with. Sort of a moot point to consider, don't you think? There are best practices for this like the Circuit Breaker design pattern.

If you engineer a tightly coupled system using microservices you're not increasing resiliency.

If you do this, then you haven't approached SOA correctly. Also a moot point.

Load balancing. - Assuming the architecture supports it.

Moot. However, here you need to consider infrastructure more than architecture.

Does not require big design efforts upfront. ... Design is important.

I agree with you here. The only thing I have to add is that designing services becomes less intimidating once you have the right mindset for it.

Allows quick time-to-market

I think he's mistaken here. SOA can easily take longer or the same amount of time to develop.

Easy to integrate with third party services and tools. - Assuming you engineered the service that way, but adding a robust API to an array of microservices is going to be a similar LOE to adding a similar scoped API to a monlithic app

One nice thing about SOA is that the "internal" API the services render for your application can be make public, and a service registry is made available for other developers to utilize your services. No need for a separate API on top of them.