5 ms·

I don't understand these impulsive "don't do it" reactions. Why can't folks just assess their own situations, review/learn about possible solutions, try stuff

I don't understand these impulsive "don't do it" reactions. Why can't folks just assess their own situations, review/learn about possible solutions, try stuff out and then eventually go with something? There's going to be unpleasant problems no matter what you choose. There's no silver bullet. Projects fail for many different reasons, only one of them is because of wrong "technology platform choice."

foobiekr 6y ago
At least my personal feeling from having watched multiple projects arrive at hundreds of microservices, some of which end up amplifying inbound requests into a nearly exponential number of internal requests, the problem is that most teams have no thesis at all for when it makes sense to separate two functions, when you should make a function a service, etc. this means you get a massive amplification of cost and complexity and, honestly, not a lot of gain most of the time.
fendy3002 6y ago
I can sympathize with them. I did one project using microservice and tdd with a team of 4 devs. It wasn't my architecture. It takes 6 months to deploy a minimum functionality apps, that I'm confident that with monolith, it'll take 1-2 months to get the same level of functionality. Microservices are very complex, especially if you don't know the domain beforehand. Most of the time, the additional complexity brings more harm than the benefit.
gregmac 6y ago
It's exactly because of articles written like this! > Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software architecture. More and more developers are adopting it. > Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications. Companies all over the world have recognized the advantages they get with microservices. Amazon, Netflix, eBay, Spotify, Uber, Groupon, and SoundCloud, are only some of them. At the bottom of the challenges section, it mentions: > Aside from all these disadvantages, it’s very important to state that the right kind of automation, tools, and developers who are rockstars in their areas every challenge can be solved. It also does briefly mention why you'd want a monolith, but doesn't really give it much weight: > Monolithic architecture is better when: > * the application you’re developing is simple, and everything is in the same language and framework, > * you want to test quickly and easily by simply launching the application, and > * you don’t have too many new features that will trigger the release of the entire application. So basically the way this comes off: * Everyone is using microservices, and if you aren't, you should be. * Only "simple" apps that aren't getting new features use monoliths (and who describes the app they are spending a significant effort on as "simple"?) * If you find them too hard, you're not a "rockstar" and/or you don't have good tools. It may not be the intent of the article to have this tone, but that's the way it comes across (and so many articles advocating for the trendy technology-of-the-day are written in this style). This causes people to react strongly the opposite way to balance it out, and that knee-jerk reaction is naturally "don't!". I bet many of those reacting this way are people that have negative experience and know the downsides better than described here. Of course every team should evaluate technology decisions on their merits, but cargo-cult programming, resume-driven development, and clueless managers that want to show they're working on the "new hotness" are all things that drive these decisions, and articles written like this strongly influence all those categories.
johnbrodie 6y ago
Some of the people with a reflexive "probably don't do it" response _have_ done what you are saying. They've assessed and learned. They've gone with microservices, and they've watched it go poorly. In short, people are giving a reflexive "don't do it" because they are sharing their experience (which is one of the points of comments in general, right?). If you're anywhere near the point of "needing" microservices (if there is such a thing), there is no simple "try stuff out", fwiw. You're talking about potentially 10s of different teams needing to be involved even for some small effort.
dec0dedab0de 6y ago
The problem is when a manager that "used to code" reads an article and decides that micro services are the answer to everything. Then it spreads around the company like a disease, until you find yourself repeatedly having to explain that "micro services can be useful in some scenarios, and we should keep an open mind, but for our particular use case it would just make things more difficult without adding any benefit."

foobiekr 6y ago

At least my personal feeling from having watched multiple projects arrive at hundreds of microservices, some of which end up amplifying inbound requests into a nearly exponential number of internal requests, the problem is that most teams have no thesis at all for when it makes sense to separate two functions, when you should make a function a service, etc. this means you get a massive amplification of cost and complexity and, honestly, not a lot of gain most of the time.

fendy3002 6y ago

I can sympathize with them. I did one project using microservice and tdd with a team of 4 devs. It wasn't my architecture. It takes 6 months to deploy a minimum functionality apps, that I'm confident that with monolith, it'll take 1-2 months to get the same level of functionality. Microservices are very complex, especially if you don't know the domain beforehand. Most of the time, the additional complexity brings more harm than the benefit.

gregmac 6y ago

It's exactly because of articles written like this! > Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software architecture. More and more developers are adopting it. > Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications. Companies all over the world have recognized the advantages they get with microservices. Amazon, Netflix, eBay, Spotify, Uber, Groupon, and SoundCloud, are only some of them. At the bottom of the challenges section, it mentions: > Aside from all these disadvantages, it’s very important to state that the right kind of automation, tools, and developers who are rockstars in their areas every challenge can be solved. It also does briefly mention why you'd want a monolith, but doesn't really give it much weight: > Monolithic architecture is better when: > * the application you’re developing is simple, and everything is in the same language and framework, > * you want to test quickly and easily by simply launching the application, and > * you don’t have too many new features that will trigger the release of the entire application. So basically the way this comes off: * Everyone is using microservices, and if you aren't, you should be. * Only "simple" apps that aren't getting new features use monoliths (and who describes the app they are spending a significant effort on as "simple"?) * If you find them too hard, you're not a "rockstar" and/or you don't have good tools. It may not be the intent of the article to have this tone, but that's the way it comes across (and so many articles advocating for the trendy technology-of-the-day are written in this style). This causes people to react strongly the opposite way to balance it out, and that knee-jerk reaction is naturally "don't!". I bet many of those reacting this way are people that have negative experience and know the downsides better than described here. Of course every team should evaluate technology decisions on their merits, but cargo-cult programming, resume-driven development, and clueless managers that want to show they're working on the "new hotness" are all things that drive these decisions, and articles written like this strongly influence all those categories.

johnbrodie 6y ago

Some of the people with a reflexive "probably don't do it" response _have_ done what you are saying. They've assessed and learned. They've gone with microservices, and they've watched it go poorly. In short, people are giving a reflexive "don't do it" because they are sharing their experience (which is one of the points of comments in general, right?). If you're anywhere near the point of "needing" microservices (if there is such a thing), there is no simple "try stuff out", fwiw. You're talking about potentially 10s of different teams needing to be involved even for some small effort.

dec0dedab0de 6y ago

The problem is when a manager that "used to code" reads an article and decides that micro services are the answer to everything. Then it spreads around the company like a disease, until you find yourself repeatedly having to explain that "micro services can be useful in some scenarios, and we should keep an open mind, but for our particular use case it would just make things more difficult without adding any benefit."