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

101–110 of 243 posts

Re: Why our team cancelled our move to microservices

#101

Post by staticassertion »

duxup wrote: post #80
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…

I don’t even know what anyone means by monolith or micro services. I’m somewhat sure everyone is somewhere in between depending on who you ask.

ISBN-13: 978-1491950357 ISBN-10: 1491950358

Here you go, you can read this book and it explains.

Re: Why our team cancelled our move to microservices

#102

Post by serial_dev »

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 microservices kool-aid", and came up with (in theory) super scalable solutions and like a dozen of microservices. It was difficult to keep things in mind, the tech stack was way too complicated for two developers. It was also less performant and more costly. The added complexity was totally unnecessary, especially because we never got neither tons of users, nor more developers. The business guy trusted the developer, so the company never worked enough on their product and USP. I guess the developer just didn't want to accept that the fancy tech solutions won't bring success.

Yet another time, we were a small team (5-ish devs, product owner, and a designer). We started with a monolith and we paid attention to software design and moved quickly.

Also, for some reason it's often overlooked, that you can make your monolith modular and design it so that when the day comes, you can split it up into smaller services. You don't need to start with microservices, you can start with a monolith and figure out later how to split it up (if necessary).

Microservices and "monoliths" have their place, you just need to know when to use which.

Re: Why our team cancelled our move to microservices

#103

Post by whimsicalism »

ironmagma wrote: post #81
whimsicalism wrote: post #62

Earlier quoted context omitted.

> What have you gained? Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system? Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.

> you only have so many inputs and outputs to a simpler system? Doesn't a function only have so many inputs and outputs too? Scope capturing/global variables aside.

> Doesn't a function only have so many inputs and outputs too? Scope capturing/global variables aside.

Sure, and a microservices architecture to me implies a larger movement towards function-esque, idemopotency, analyzability and away from global state.

To me, monolithic architecture implies global shared state that is difficult to reason about.

Re: Why our team cancelled our move to microservices

#104

Post by wpietri »

jedberg wrote: post #61

> We have approximately 12 developers spread across 2 feature teams and a support team. If I were consulting for this company, I would have told them to stop right there, microservices are probably not for them. Unless you build from the start for microservices on something like AWS lambda, doing with such a small team would be really hard. And as they eventually discovered, a lot of unnecessary overhead for such a s…

One of the questions I like asking developer pals is what ratio their company has between engineers and services/deployable units. Anybody reading this care to share?

For me, that number says a lot more about the day-to-day life of devs than the microservices vs monolith label does.

Re: Why our team cancelled our move to microservices

#105

Post by winternett »

glintik wrote: post #20
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 are relatively new and unproven. They are so old, buddy, actually. Splitting monolith into services(not always been micro) is a natural evolution for any software.

Agreed in essence... The ideology is indeed old, but the practice of putting flashy wrappers and catchy names around the services are new.. Like "Dynamo DB" and "Route 53". Those names appeal to non technical product owners that then force adoption onto development teams... Pure fluff at it's best.

That's the think about the marketing first model we're dealing with now... No real innovation, just branding/name changes and highly tailored customization to lock a customer into a specific platform.

Re: Why our team cancelled our move to microservices

#106

Post by whimsicalism »

bcrosby95 wrote: post #79
whimsicalism wrote: post #62

Earlier quoted context omitted.

> What have you gained? Separation of responsibilities? Easier to analyze because you only have so many inputs and outputs to a simpler system? Debugging something that touches a lot of paths in a monolith can be quite nightmarish as well.

Most comments about this assumes a poorly designed monolith and a well designed set of microservices. A microservices architecture can be a rats nest too. I guess what it means is that even if you can build a well modularized system, it will only stay well modularized if you use a network call to enforce it. Well, at least for most companies. Conceptually, there's nothing keeping you from designing your codebase to w…

Or something that can be spun up as a service or imported as a library

Re: Why our team cancelled our move to microservices

#107

Post by trinovantes »

noogle wrote: post #58
kgeist wrote: post #46

Earlier quoted context omitted.

>The golden rule is to never break API backwards compatibility. If you must, create a new version of the API and leave the old version functional It also helps with zero-downtime deployments: 1) spawn a new instance of the service with the new API, side by side with the old one 2) now incoming traffic (which still expects the old API) is routed to the new instance with the new API, and it's OK, because it's backward-…

How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version. Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).

One way is to rewrite version N endpoints to use version N+1 endpoints. You just need to ensure clients can handle null/empty data so that when some requested data is depreciated, you don't break old apps. The increased latency from N conversion calls also encourage the oldest clients to migrate without breaking backwards comparability.

Re: Why our team cancelled our move to microservices

#108

Post by duxup »

staticassertion wrote: post #101
duxup wrote: post #80

Earlier quoted context omitted.

I don’t even know what anyone means by monolith or micro services. I’m somewhat sure everyone is somewhere in between depending on who you ask.

ISBN-13: 978-1491950357 ISBN-10: 1491950358 Here you go, you can read this book and it explains.

I know what the terms means, but I think in common language people mean different things when you find out what they are doing.

Re: Why our team cancelled our move to microservices

#109

Post by edude03 »

ironmagma wrote: post #59
andrewstuart wrote: post #38

Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.

Examining behavior in the limit (a la physics) is interesting. Imagine a system where every function call goes out to a separate process. Suddenly you have a lot of processes waiting around to be called. Debugging requires special tools. Profiling becomes a nightmare. Even determining if the system is fully running becomes difficult. What have you gained?

Minor nit: functions as a service are almost exactly this - and they (from a technical perspective) don’t wait to be called, they pop into existence just in time.

Arguably though it’s not special tools is just different tools. You usually can’t run a debugger live in production but with tools like distributed tracing and service meshes you get really close

Re: Why our team cancelled our move to microservices

#110

Post by jpalomaki »

Some perspective from Netflix. Around 10k employees [1] (could not find how many are working with software), more that 1000 microservices [2].

The second article also provides some insight to the services. Those make sense for me - they truly sound like independent, relatively large pieces of software. Not like “LoginService” type of things you sometimes see.

Few examples: 1)Create a main menu list of movies 2)Determine your subscription status to provide content relevant to that subscription tier 3)Use your watch history to recommend videos you may like

[1] https://www.macrotrends.net/stocks/charts/NFLX/netflix/numbe... [2] https://www.cloudzero.com/blog/netflix-aws?hs_amp=true

Post reply on HN