Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why our team cancelled our move to microservices

steven-lemon182.medium.com

Post reply on HN
Print view View original

171–180 of 243 posts

Re: Why our team cancelled our move to microservices

#171

Post by withinboredom »

serial_dev wrote: post #102
winternett wrote: post #7

The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…

Microservices make sense in some scenarios. I work at a large retail company with who knows how many developers. We have different teams for payment, promotions, product search, account, shipping and more. All of them working on a single codebase with coordinated deployments would be a nightmare. Previously, I joined a startup (previous coworkers of mine), a developer and a business guy. The developer "drank the micr…

There’s really not much coordination with a monolithic deployment. Merge your commit and get in line. Monitoring tools will ping you on slack if there’s any issues. It’s probably easier than micro services because all tooling and builds are centralized.

Re: Why our team cancelled our move to microservices

#172

Post by mdavis6890 »

"What were we trying to achieve again?"

This is the main takeaway here. If you have a problem and think microservices might be a good way to solve it and possibly worth the effort, then go ahead and investigate. But without a clear problem and plausible solution involving MS, it's going to be a big waste of time.

Re: Why our team cancelled our move to microservices

#173

Post by QuercusMax »

candiddevmike wrote: post #122
Kalium wrote: post #72

Earlier quoted context omitted.

I agree that microservices shift complexity, but I'm not sure that this inherently results in an overall increase in complexity. For example, using highly automated ops tools like autoscaling and load balancing can enable smooth handling of problems that can be challenging to handle in code.

Instead of shuffling data between things via shared memory/function args, you're doing it over the network. This will always be more complicated.

Here at Google, one of our most popular microservices frameworks enables microservices to be assembled into servers. If one microservice calls another one in the same assembly, it won't touch the network, and is quite optimized. There's no reason that microservices have to all run in separate binaries, but when it's useful it can be done easily enough without having to change your code.

Re: Why our team cancelled our move to microservices

#174

Post by TheOtherHobbes »

throwaway894345 wrote: post #127
winternett wrote: post #7

The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It's almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that's why I don't buy into buzz words at all. If it's not broken, don't fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into…

Monoliths are pretty great, and there are tons of valid criticisms of microservices; however, this comment managed to steer clear of all of them. :) > The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. Not everything is a conspiracy. Sometimes it’s just useful to have a word to describe a particular architecture. In this particular case, “monolith” isn’t even disparagin…

>individual teams can’t deploy their code without coordinating with every other team, which yields long user feedback loops and a bunch of other knock-on effects

Fine until one of the microservices needs an update with new features -> new API because Something Has Changed, and suddenly...

>the whole purpose of containers is to decouple the application from the platform.

Are containers not a de facto platform?

>Literally laughing out loud at the idea that marketing people are behind microservices.

Here's a moderately complete list of products. How many are pay-to-play?

https://www.aquasec.com/cloud-native-academy/container-platf...

All you're really doing with containers is creating a meta-monolith running on external hardware with custom automation - managed by an ever so handy third party software product. Also running on external hardware. All of which you're paying for.

You can also DIY and not pay. In theory. But really...?

This makes sense at global scale where you're drowning in income and need to handle all kinds of everything for $very_large_number customers.

It's complete madness for a small startup that doesn't even have a proven market yet.

Re: Why our team cancelled our move to microservices

#176

Post by candiddevmike »

Kalium wrote: post #142
candiddevmike wrote: post #122

Earlier quoted context omitted.

Instead of shuffling data between things via shared memory/function args, you're doing it over the network. This will always be more complicated.

Yes, it shifts communication to over the network, but this comes with the benefit of making system boundaries much clearer. It's been my experience that this can allow different parts to evolve separately and make the choices best for their own needs, which can sometimes result in a paradoxical reduction of complexity as one all-in-one system turns into a series of simpler tools. Suddenly the part of the system that…

Given the trade off of synchronous vs asynchronous, I hope most folks try their damnedest to use the former before having to use the latter.

Re: Why our team cancelled our move to microservices

#177

Post by indymike »

The debate about microservices and monoliths are really about valuing consistency of tooling over best tool for the job. Microservices tend to emphasize allowing a developer to use whatever tools services and languages they want to implement a service. We define the input to the service and the output from the service, but little in between. The consistency is in the interfaces between the services - how each service is built can be totally different. Monoliths emphasize consistency of tooling and language across services, so there are fewer tools, fewer things to know to operate and develop the application.

You know what? You can totally screw up both architectures, you can have cost overruns, and you can fail to scale. Neither microservices or monoliths are going to make you succeed of fail.

The real question is, where do you want to put the consistency? Is that the right way to do it for your app? Can your team maintain and keep building, or is maintenance going to blow you up?

Re: Why our team cancelled our move to microservices

#178

Post by edgyquant »

throwaway894345 wrote: post #159
winternett wrote: post #150

Earlier quoted context omitted.

This is agreeably congruent with my original statement, The main problem I have with microservice marketing: It is often promoted to clients that do not have applications that are large or critical enough to warrant leveraging them. That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily. And clients are often not aware of the operati…

You’re confusing “microservices” with dependencies on a particular platform (presumably cloud providers). Microservices aren’t more likely to have these dependencies, as monoliths are often also deployed on cloud providers and assume a particular database, etc. Anyway, if you’re dealing with microservices “lock-in” isn’t a real problem—you just move one service over to your new platform at a time. Good luck doing tha…

It really doesn’t seem like they are confusing microservices, I’m not sure what makes you think that.

Re: Why our team cancelled our move to microservices

#179

Post by throwaway894345 »

edgyquant wrote: post #178
throwaway894345 wrote: post #159

Earlier quoted context omitted.

You’re confusing “microservices” with dependencies on a particular platform (presumably cloud providers). Microservices aren’t more likely to have these dependencies, as monoliths are often also deployed on cloud providers and assume a particular database, etc. Anyway, if you’re dealing with microservices “lock-in” isn’t a real problem—you just move one service over to your new platform at a time. Good luck doing tha…

It really doesn’t seem like they are confusing microservices, I’m not sure what makes you think that.

> That buyers often are properly warned about their inability to easily migrate if they invest in platform-specific microservices too heavily.

Re: Why our team cancelled our move to microservices

#180

Post by winternett »

throwaway894345 wrote: post #138
winternett wrote: post #131

Earlier quoted context omitted.

I'd need days to detail it all specifically enough, but I'll give you a simple example... A "monolithic" solution usually relies on a basic (e.g. LAMP) stack that can all be run on one server if the need arises... Your web and database server can be migrated from AWS to Azure much easier if pretty much all of the functionality relies on a close-knit local server architecture that can have a less complicated security,…

You’re confusing “microservices” and “distributed architecture” with “depending on specific cloud provider services”. Microservices don’t have to depend on any cloud services at all and monoliths can (and often do!) use cloud services.

Many "Monoliths" can be run on something as simple as a desktop emulator. They don't generally rely on cloud either.

Microservices are "distributed" across a cloud host platform because they are each updated and maintained by different teams. My use of the term "distributed means that if AWS East has your DB instance and your web server is stored in an entirely different region, you app goes down anyway, but your front-end team can maybe still deploy updates... Which is not really a dramatically productive gain for a customer running a restaurant web site.... On the other hand, if you're running a massive video streaming site, it might be a good thing to base it on micro service architecture. Each use case is different.

I'm resisting the pressure to be drawn into a debate about which one is better, that's not what I'm out to do... What determines which solution is better is the business case it seeks to resolve. Neither is inferior or more obsolete, the two ideals both can and often do run on identical/similar code bases... It's the configuration and potential uses/application/benefits that differ.

Post reply on HN