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

Microservices Are Something You Grow Into, Not Begin With

nickjanetakis.com

Post reply on HN
Print view View original

121–130 of 159 posts

Re: Microservices Are Something You Grow Into, Not Begin With

#121

Post by hderms »

badminton1 wrote: post #106
spreiti wrote: post #55

Earlier quoted context omitted.

> But microservices are also about coupling: just have a self-contained service that does one thing. What stops you from creating a module inside a monolith with an interface that provides a self-contained service that does one thing?

You can. But one day, some 10xer will be short on time and will duct tape your module with 10 other modules.

The newish argument for microservices is that they enable compositionality, so wouldn't that same hypothetical apply? I.e. some 10xer is short on time and glues a bunch of microservices together and now you have the same problem but worse because there's no IDE allowing you to trace the code?

Re: Microservices Are Something You Grow Into, Not Begin With

#122

Post by nemothekid »

zzzcpan wrote: post #118
adamdrake wrote: post #21

Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…

> Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) They are not wrong though, monoliths cannot give you fast delivery. Fast delivery implies at least expressive dynamically typed languages with some resilience to bugs, which in turn requires limiting the scope of bugs and therefore decoupling and isolating everything as much as possible. Th…

I disagree. You can have fast delivery with monoliths - IME microservices provide better separation of concerns, which one the benefits could be faster delivery.

However your end user doesn’t interact with microservices, they interact with a product. “microservices” suggested as a delivery silver bullet tend to be ways managers try and mask the fact that they are trying to hire 9 women to make a baby in one month.

Re: Microservices Are Something You Grow Into, Not Begin With

#123

Post by batiste »

js4ever wrote: post #94
collyw wrote: post #35

Earlier quoted context omitted.

Not if you know how to architect one properly. How is a small microservice with one purpose different from a class / module with one purpose?

A simple syntax error in a monolith means the whole monolith is crashed. Bug anywhere in the monolith could mean border effect in the rest of the code anywhere. With microservices you guaranty isolation so a bug in one microservice won't have impact on the rest of the api

A syntax error should never make it production if you have even half decent infrastructure... In a monolith or a micro service.

And if your microservice get to production with a syntax error do you really think the whole ecosystem is somehow more healthy? Not unless you wrote a ton of horrible defensive code with and retries and HTTP error/timeout catching code every time this service is called...

Re: Microservices Are Something You Grow Into, Not Begin With

#124

Post by batiste »

z3t4 wrote: post #17

There's trade-off's. They are using a fairly complex CI while with micro-services you release each service individually. It's hard to turn a monolith architecture into a architecture with micro-services. So it all depends on what works best for you. The idea with micro-services is that with a much smaller service - development is faster and cheaper, you can for example rewrite the entire service, use different softwa…

> It's hard to turn a monolith architecture into a architecture with micro-services

The other way around is 10 times harder... So think twice and make sure you need it before doing it.

Re: Microservices Are Something You Grow Into, Not Begin With

#125

Post by arunmk »

When making generic rules one should provide a lot of context. I have found that a fairly large rearchitecture is needed to move from a monolithic product to something with microservices. It is not something to grow into that way.

And the technical reasons to move will be mostly for fault tolerance and resiliency (you don’t want your whole service to go down because a small widget failed somewhere). Of course this does not come for free.

Basically it’s not that one is better than the other for all cases. This is a case where people should consider many things including non-technical aspects before making sweeping statements or decisions.

Re: Microservices Are Something You Grow Into, Not Begin With

#126

Post by zzzcpan »

batiste wrote: post #123
js4ever wrote: post #94

Earlier quoted context omitted.

A simple syntax error in a monolith means the whole monolith is crashed. Bug anywhere in the monolith could mean border effect in the rest of the code anywhere. With microservices you guaranty isolation so a bug in one microservice won't have impact on the rest of the api

A syntax error should never make it production if you have even half decent infrastructure... In a monolith or a micro service. And if your microservice get to production with a syntax error do you really think the whole ecosystem is somehow more healthy? Not unless you wrote a ton of horrible defensive code with and retries and HTTP error/timeout catching code every time this service is called...

Typically you make an abstraction for all those timeouts, retries and errors. It can look just like a normal function call and have optional arguments for timeouts.

Re: Microservices Are Something You Grow Into, Not Begin With

#127

Post by jdc0589 »

I have a slightly different opinion. Start with a mostly monolith, sure, that makes sense. But also start off with just one separate microservice for something important. It's important that you establish good patterns for integrating services in to your codebase early on. Its really easy to write a monolith without any thought of external service abstraction, which makes it WAY harder to do down the road if you decide you need to.

Re: Microservices Are Something You Grow Into, Not Begin With

#128

Post by [deleted] »

jdc0589 wrote: post #127

I have a slightly different opinion. Start with a mostly monolith, sure, that makes sense. But also start off with just one separate microservice for something important. It's important that you establish good patterns for integrating services in to your codebase early on. Its really easy to write a monolith without any thought of external service abstraction, which makes it WAY harder to do down the road if you deci…

[deleted]

Re: Microservices Are Something You Grow Into, Not Begin With

#129

Post by zmmmmm »

js4ever wrote: post #94
collyw wrote: post #35

Earlier quoted context omitted.

Not if you know how to architect one properly. How is a small microservice with one purpose different from a class / module with one purpose?

A simple syntax error in a monolith means the whole monolith is crashed. Bug anywhere in the monolith could mean border effect in the rest of the code anywhere. With microservices you guaranty isolation so a bug in one microservice won't have impact on the rest of the api

You're blurring the lines a bit between the true definition of microservices (eg: no shared schema, data structures, etc) and just a sensible deployment architecture. If their runtime state is independent then there is nothing stopping you taking your monolithic code base and deploying it N times, for as many independent end points as you want. That way service A crashing is never going to bring down service B, but they can still share code and data structures.

The real question is, do they have shared runtime state? If they don't, you can do the above, but if they do, moving to microservices won't make that go away, it might even make it harder to deal with.

Re: Microservices Are Something You Grow Into, Not Begin With

#130

Post by blablabla123 »

netcan wrote: post #93
adamdrake wrote: post #21

Most of the time, I've found a push to microservices within an organization to be due to some combination of: 1) Business is pressuring tech teams to deliver faster, and they cannot, so they blame current system (derogatory name: monolith) and present microservices as solution. Note, this is the same tired argument from years ago when people would refer to legacy systems/legacy code as the reason for not being able t…

Reality is also confusing. People can see that in a one day hackathon, the same bunch of people can produce more stuff than they do in a year otherwise. Why? Are they lazy? Did they use better tools? My niece Shelly added address book integration to her hobby app in an afternoon, while drunk. WhyTF are we 640 man hours deep into "identity architecture coordination" meetings?!! Just do with Shelly did! Those things do…

I guess that's the difference between proper Engineering and hacking something quickly and under self-inflicted pressure together. Your nieces app might work on her setup but not on others and may need almost a complete rewrite on an OS/API update. The properly engineered solution on the other hand might "just work" for years. I think key is to realise how much engineering is needed on what occasion. I find it disturbing when a simple app has highly sophisticated error handling unit tests as I would find it disturbing to find 30kLOC code bases with no unit tests, completely random spaghetti architecture and no explicit error handling.
Post reply on HN