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

71–80 of 154 posts

Re: The End of Microservices

#71

Post by sbov »

onion2k wrote: post #68
weego wrote: post #61

Earlier quoted context omitted.

I'm not trying to be facetious, but isn't that just called a library?

Not as I understand microservices. A library would be something that's compiled or included in to your application code. A microservice is a separate process that the application communicates with over a protocol (eg http).

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.

Re: The End of Microservices

#72

Post by beagle3 »

spriggan3 wrote: post #21
dasil003 wrote: post #13

Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom. Don't get me wrong, a service-oriented architecture is the only thing that s…

> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then make it scale" ?

> 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. However, if you don't think about the bottlenecks and how to optimize them in advance, you more often than not find later, when profiling, that there are not enough hotspots, and the performance is "lost" all over the place.

Re: The End of Microservices

#73

Post by k__ »

I had the feeling that microservices would add too much of complexity, but with FaaS this is canceled out by the fact that almost all server management complexity is handled by a different company.

Re: The End of Microservices

#74

Post by jbverschoor »

onion2k wrote: post #58
carterehsmith wrote: post #52

Earlier quoted context omitted.

You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?

You are if you care about whether you're deploying things that aren't necessary. With microservices you can take a single specific service that two projects share and reuse it. With a monolith you can't unless you deploy everything else as well. That can easily fail a requirements check (say, hardware requirements are too costly) and force you to redevelop the service for the second project.

So you deploy your easy to manage monolith, and expose your library through an rpc service. rest, thrift or whatever is hip these days.

Re: The End of Microservices

#75

Post by zby »

sbov wrote: post #71
onion2k wrote: post #68

Earlier quoted context omitted.

Not as I understand microservices. A library would be something that's compiled or included in to your application code. A microservice is a separate process that the application communicates with over a protocol (eg http).

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.

With some work you can have the some behaviour - but the microservice is also about the data (like user ids and passwords for a login microservice).

Re: The End of Microservices

#76

Post by lmm »

lobster_johnson wrote: post #40

I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it. A core principle which a lot of people and articles ignore, though, is reusability . I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it. Essentially, you build out the backend to act as a library for your front end. So we have log…

Separate pieces of functionality into small reusable libraries? Great. Enforce separation of each library's internals from each other one? Great. Ensure each database is owned by one and only one service? Great.

Invoke those services via RPC-over-HTTP? Why???

Re: The End of Microservices

#77

Post by r2dnb »

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 warned us a long time ago : "The first rule of distributed objects : don't distribute them".

>There are a few exceptions where its useful to scale out parts of a distributed application

Yes, and very very very few. As I always say : microservices are not an architecture, they are an optimization.

Re: The End of Microservices

#78

Post by lmm »

beagle3 wrote: post #72
spriggan3 wrote: post #21

Earlier quoted context omitted.

> Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now. This. What happened to "make it work then make it scale" ?

> 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.

Re: The End of Microservices

#79

Post by xorcist »

lmm wrote: post #76
lobster_johnson wrote: post #40

I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it. A core principle which a lot of people and articles ignore, though, is reusability . I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it. Essentially, you build out the backend to act as a library for your front end. So we have log…

Separate pieces of functionality into small reusable libraries? Great. Enforce separation of each library's internals from each other one? Great. Ensure each database is owned by one and only one service? Great. Invoke those services via RPC-over-HTTP? Why???

Because we have to reinvent the message bus every fifth year, so we have to de-invent it in between.

Re: The End of Microservices

#80

Post by danmaz74 »

DanielBMarkham wrote: post #69
nostrademons wrote: post #64

Earlier quoted context omitted.

If you're starting "micro", why do you need the "services" part at all? Why not just make it a function call? To use your example, if my task were "make a record of the errors of this process available on the web", my first thought would be to write to stderr, pipe stderr to a file, and then serve that from the webroot of some commodity webserver like Apache, 'python -m SimpleHTTPServer', or even S3. If the format is…

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 pretty difficult to test automatically?

Post reply on HN