3 ms·

I think the other listed advantages of microservices also aren't entirely serious. "Easier deployment than monoliths" are you sure? "Polyglot persistence" why i

I think the other listed advantages of microservices also aren't entirely serious. "Easier deployment than monoliths" are you sure? "Polyglot persistence" why is that a good thing? "Scalable" no idea what it means. "High performance" now you're just messing with me. In my experience, you can have a huge binary doing tons of things that's nevertheless quick to build and run. And it will be easier to step through, which is super important.

lost_name 7y ago
> "Scalable" no idea what it means. Generally refers to the idea that a microservice should be designed to scale horizontally (with more instances) vs. vertically (more compute power). If you can scale horizontally you're more likely to be able to meet changes demand at a lower price.
jayd16 7y ago
You should actually try microservices in a larger team before dismissing all these. Having large feature sets behind a load balancer and having the rest of the app fail gracefully when a feature goes down, means you can have worry free deployments. You can deploy a single feature, you can do a tiered role out on a feature, without impacting any other service. You can also easily deploy more instances of a service. As long as you've done the work to make your internal requests stateless then you should be able to maintain high perf by scaling instances. Beyond Polygot, I would instead phrase it as new features can roll out without dealing a large legacy tier of code. Most of your code can be Java with a single high performance service written in C++, lets say. If you're compressing video in an async manner, do you really want to throw that in your RESTful Spring service?
kgoralski 7y ago
you can check that one for more context :) https://www.slideshare.net/aahoogendoorn/designing-and-building-a-microservices-architecture-stairway-to-heaven-or-a-highway-to-hell https://www.slideshare.net/aahoogendoorn/designing-and-build... , slide 26 ;)

lost_name 7y ago

> "Scalable" no idea what it means. Generally refers to the idea that a microservice should be designed to scale horizontally (with more instances) vs. vertically (more compute power). If you can scale horizontally you're more likely to be able to meet changes demand at a lower price.

jayd16 7y ago

You should actually try microservices in a larger team before dismissing all these. Having large feature sets behind a load balancer and having the rest of the app fail gracefully when a feature goes down, means you can have worry free deployments. You can deploy a single feature, you can do a tiered role out on a feature, without impacting any other service. You can also easily deploy more instances of a service. As long as you've done the work to make your internal requests stateless then you should be able to maintain high perf by scaling instances. Beyond Polygot, I would instead phrase it as new features can roll out without dealing a large legacy tier of code. Most of your code can be Java with a single high performance service written in C++, lets say. If you're compressing video in an async manner, do you really want to throw that in your RESTful Spring service?

kgoralski 7y ago

you can check that one for more context :) https://www.slideshare.net/aahoogendoorn/designing-and-building-a-microservices-architecture-stairway-to-heaven-or-a-highway-to-hell https://www.slideshare.net/aahoogendoorn/designing-and-build... , slide 26 ;)