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

The End of Microservices

lightstep.com

Post reply on HN
Print view View original

91–100 of 154 posts

Re: The End of Microservices

#91

Post by [deleted] »

onion2k wrote: post #81
sbov wrote: post #71

Earlier quoted context omitted.

I think the point is you can achieve the same result by just using a library. There are potential benefits and downsides to services over libraries of course, but unless there are specific requirements that make a library unsuitable, all else equal I would rather just use a library.

Microservices also enable you to scale individual parts of your application. If you need better performance for, say, image compression then it's much easier to add resources to a service that lives in its own process space (or its own server, or rack of servers, or data centre..) than it is to improve the performance of a specific library in a larger application.

[deleted]

Re: The End of Microservices

#92

Post by badminton1 »

iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

When you have a large service, you can end up with a lot of coupling. Meaning that it is hard to have teams that specialize in specific parts of the application, you need a huge team that knows everything about everything and that doesn't scale as your code and company grows. And you can see the effects of that in reduced productivity and technical debt beyond belief.

Even if you hire high-end talent, they will be forced to worship people that have the knowledge about how all the bloated jenga-tower mess works.

And that's only the people problem, let's not even discuss how you build, deploy, test things in a reliable way without taking days to produce a working build.

That, and the fact that your quality of life will suck, since you won't be in control of such mess.

With microservices you have one service that does a limited set of things, that is easy to monitor, maintain, test, deploy and even entirely replace if necessary.

Re: The End of Microservices

#93

Post by DanielBMarkham »

danmaz74 wrote: post #80
DanielBMarkham wrote: post #69

Earlier quoted context omitted.

It is a pure function call. There are no side effects, just a clear and simple input stream and a clear and simple output stream. I agree with your characterization. All except maybe the "I'd probably write a quick JS viewer that can collapse stack traces" part. Here's the thing: I'm so minimalist that I'm only going to add frameworks and libraries as a last result, if you stuck a gun to my head. I'm going to resist…

> I'm okay with calling that a microservice, since it's infrastructure code that needs to be deployed and maintained as part of the app. But it's really only a line of BASH. I'm under the impression that most people wouldn't call that a microsevice. Moreover, isn't that solution completely dependent on the implementation of the code that is writing those certain files, without making this dependence explicit - and pr…

Actually no. No more than CSV dependency prevents spreadsheets from working with one another.

I think the key thing here is your word "explicit". There are lots of ways to make things explicit. The concerns of coupling and cohesion don't go anywhere. There are other ways to address them.

Testing is actually significantly easier, not more difficult.

Re: The End of Microservices

#94

Post by xxs »

tomc1985 wrote: post #41

It is weird to read people write about microservices (or some other tech fad) as if it is this otherworldly thing that requires instruction and training. So many words dedicated to describing the supposedly bad old days! All this stuff is just another aspect in the life of a practitioner of computing. A proper expert should see these things not as a fad, but as a collection of techniques that can be added or subtract…

...but you can write (and sell) books about, talk at conferences too

Re: The End of Microservices

#95

Post by [deleted] »

iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

[deleted]

Re: The End of Microservices

#97

Post by StavrosK »

r2dnb wrote: post #77
iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

>In fact, that's how most non-web software is still written and done. I can even add that we only do web software, but we do them exactly that way. >If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. I couldn't agree more. Martin Fowler warn…

> I can even add that we only do web software, but we do them exactly that way.

I can even add that not only do we do them exactly that way, but it's many times faster and more reliable than microservices, for reasons I have written about before[1].

The reality is that microservices add a whole host of failure modes, for just one benefit over monoliths: They are easier to scale horizontally. If you don't absolutely need horizontal scalability, and not many companies do, then you'd be foolish to pay the large cost.

[1]: https://www.stavros.io/posts/microservices-cargo-cult/

Re: The End of Microservices

#98

Post by beagle3 »

lmm wrote: post #78
beagle3 wrote: post #72

Earlier quoted context omitted.

> This. What happened to "make it work then make it scale" ? The fact that it is wrong (or rather, incomplete) It should be "make it work with a clear path to scaling, then make it scale" - that's true with respect to both software engineering and business plans. It's the same with "premature optimization is [the|a root of [all]] evil" - Premature optimization is a waste of time and often paints you into a corner. Ho…

Not my experience at all. Systems that were designed as simply as possible can be unpicked and made scalable - it takes time and effort but it's doable. Systems that were designed to be scalable are much worse, because you have to undo all of that work first before you can start actually making them scalable.

Simpler systems are easier to scale than more complicated ones, for sure - but things like making sure that your database is easily shardable are often cheap (even free) before you start, and might be extremely expensive later on -- I'm familiar with a project that eventually spent a few hundred thousand dollars on some high performance database (Oracle RAC or something, don't remember exactly), where -- if the database schema was shardable in advance -- they could have been ok with 10-20 cheap machines running MySQL.

And I remember an earlier project that had to be completely rewritten in the early '90s because at the time, Oracle couldn't yet scale even throwing money at it (and DB2 reportedly could - but the required Mainframe was not an option).

Simple is often best, yes. But not oblivious-to-the-future simple.

Re: The End of Microservices

#99

Post by danmaz74 »

DanielBMarkham wrote: post #93
danmaz74 wrote: post #80

Earlier quoted context omitted.

> I'm okay with calling that a microservice, since it's infrastructure code that needs to be deployed and maintained as part of the app. But it's really only a line of BASH. I'm under the impression that most people wouldn't call that a microsevice. Moreover, isn't that solution completely dependent on the implementation of the code that is writing those certain files, without making this dependence explicit - and pr…

Actually no. No more than CSV dependency prevents spreadsheets from working with one another. I think the key thing here is your word "explicit". There are lots of ways to make things explicit. The concerns of coupling and cohesion don't go anywhere. There are other ways to address them. Testing is actually significantly easier , not more difficult.

I'll take your words about testability and maintainability, but still, I'm not convinced this would be be considered a microservice by most proponents of the term:

> Like in SOA, services in a microservice architecture[1] are processes that communicate with each other over the network in order to fulfill a goal. Also, like in SOA, these services use technology agnostic protocols.[2]

https://en.wikipedia.org/wiki/Microservices

Re: The End of Microservices

#100

Post by mk89 »

r2dnb wrote: post #77
iamleppert wrote: post #28

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…

>In fact, that's how most non-web software is still written and done. I can even add that we only do web software, but we do them exactly that way. >If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. I couldn't agree more. Martin Fowler warn…

> I couldn't agree more. Martin Fowler warned us a long time ago : "The first rule of distributed objects : don't distribute them".

Funny that now the same person carries the flag with the symbol of microservices, which are seen as a way to "get rid of architects". That's exactly what Thoughtworks believes in - and you will understand more if you read the first chapters of the book "Building Microservices", or if you join their recent conferences. Just my 2 cents.

Post reply on HN