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

121–130 of 154 posts

Re: The End of Microservices

#121

Post by lobster_johnson »

pjmlp wrote: post #84
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…

I have been doing it since the early 90's. It is called unit, module, package, library. No need to put some network layer, with its own set of problems, between method/function calls.

Libraries typically don't have databases or daemons. It's operationally very different.

Can I envision a language-specific framework wherein "microservices" are just plugins that implement interfaces (Java interfaces, for example) for exposing RPC endpoints, which you then "mount" in your framework, allowing developer-enforced separation of concerns, but still allowing a single codebase to share things like config structures, database accessibility, etc.?

Sure. I can't imagine why anyone would want to do it that way, though. For example, you couldn't realistically open-source one of your services, or write it in a different language. Service-specific database stuff would get hairy, quickly. And so on.

Re: The End of Microservices

#122

Post by sp527 »

estefan wrote: post #104
sp527 wrote: post #31

Earlier quoted context omitted.

Speaking as a young engineer, I can tell you many are already looking past microservices towards things like AWS Lambda, AMQs, and BaaS, which make a great deal more sense. Why? Because it helps reduce dev effort down to purely the logic you'd have to write no matter what, with better guarantees about reliability and scalability, and less maintenance. I hesitate to say 'serverless' because that still feels somewhat o…

> AWS Lambda Has local dev/testing been solved for that yet, and different environments, etc?

Getting there. Wrapping Lambda functions for local execution isn't too hard since it's really just JS. e.g. https://www.npmjs.com/package/node-lambda

Re: The End of Microservices

#123

Post by krisdol »

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

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

I can think of a few off the top of my head:

1. Being able to scale individual, smaller components rather than one giant application

2. Being able to build-and-deploy any one module much faster than one monolithic bundle of local dependencies

3. Universal interface with language-agnostic applications. Do you need to expose big data statistical analytics, but can't find data engineers that are comfortable with Java/Node.js/Go? Doesn't matter, hire the best ones and let them use Python/R/Clojure. HTTP doesn't care.

Re: The End of Microservices

#124

Post by sp527 »

xyzzy123 wrote: post #66
sp527 wrote: post #39

Earlier quoted context omitted.

If that's the case, I'd argue we're conflating software development management with software engineering execution. It's illogical to assert that utilizing microservices implies entirely forgoing centralization.

I agree with you. In my defense, people who want microservices are generally asking for developer autonomy, but just using technical language to do it, rather than managerial.

I can believe that. This is why it's so crucial to have good management. I've also realized through my own experience that a good manager has to be in the trenches coding with his/her reports, at least part of the time. It's amazing how fast you can become irrelevant when you're unplugged and stuff like this is exactly why.

Re: The End of Microservices

#125

Post by lmm »

krisdol wrote: post #123
lmm wrote: post #76

Earlier quoted context omitted.

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

>Invoke those services via RPC-over-HTTP? Why??? I can think of a few off the top of my head: 1. Being able to scale individual, smaller components rather than one giant application 2. Being able to build-and-deploy any one module much faster than one monolithic bundle of local dependencies 3. Universal interface with language-agnostic applications. Do you need to expose big data statistical analytics, but can't find…

> 1. Being able to scale individual, smaller components rather than one giant application

Why does the size of the application matter? Sure it'll take up a little more disk space, maybe even some memory, but probably less than the overhead of splitting into components. Two copies of a monolith wastes less RAM etc. than five components of which you deploy two copies of one.

> 2. Being able to build-and-deploy any one module much faster than one monolithic bundle of local dependencies

Maybe, but first see if you can make build-and-deploy of the whole thing fast. Remember that microservices will slow you down a lot in the case where you do need to spin up multiple components (e.g. every time you spin up a dev instance).

> 3. Universal interface with language-agnostic applications. Do you need to expose big data statistical analytics, but can't find data engineers that are comfortable with Java/Node.js/Go? Doesn't matter, hire the best ones and let them use Python/R/Clojure. HTTP doesn't care.

When you have an actual use case for a HTTP interface then of course you should expose one. But most of the time, YAGNI.

Re: The End of Microservices

#126

Post by daxfohl »

Every generation's microlith is the next generation's monolith.

For this generation, the end of microservices will be when we can look at a cluster as one big unit, and deploy a microlithic monolith on it.

For the next generation, who knows how they will slice it up.

Re: The End of Microservices

#127

Post by alayne »

r2dnb wrote: post #86
hibikir wrote: post #33

Earlier quoted context omitted.

You say it as if it's a bad thing... Compared to the alternative, fiefdoms really are a wonderful thing! I once work for a giant fortune 500 corporation. Our department had a good 300 developers, and had been writing code for years. They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, ha…

I really value your contribution, thanks for sharing. I give the proponents/consultants credit for proposing a practical and incremental solution to these people instead of just insulting them or saying "you're doing it wrong". That being said, the issue I have with microservices is the fact that the below is repeatedly used as a core technical argument : > They had built the whose system using the classic, box-box-c…

Microservices aren't distributed objects http://martinfowler.com/articles/distributed-objects-microse...

Re: The End of Microservices

#128

Post by 3minus1 »

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…

> Micrososervices shouldn't have more than 100 lines of code.

I'd really like to see a non-trivial example of this because it's sounds ludicrous on its face

Re: The End of Microservices

#129

Post by alayne »

TickleSteve wrote: post #57

"Microservices" are a new name for a very old concept. This is just low-coupling, high-cohesion by another name. Small, composable, decoupled, highly cohesive components are what "good" software has been about for decades, but it now has a new name in the server s/w world; "Microservices". Only the name is new & hyped. The concepts have been true forever.

There is software and concepts around managing microservices that didn't exist before, and so on. Nothing can be new when you use such a vague way of comparing things. There were electric cars in the 1800s, why talk about Tesla?

Re: The End of Microservices

#130

Post by StavrosK »

vonmoltke wrote: post #119
StavrosK wrote: post #97

Earlier quoted context omitted.

> 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 n…

> 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. If you are writing and deploying standalone applications, I agree. Microservices do have another benefit, though: forcing the application to be modu…

> The microservice (maybe not micro, but definitely service) architecture we are moving to will allow us to compose applications with reusable building blocks more easily than trying to maintain different git branches and library versions.

Can you elaborate why? Presumably, with microservices, you're always running the latest version, whereas you're mentioning a need for "different branches and versions" in your comment.

Microservices don't force you to modularize, you can still make a mess by not cleanly separating things or by cutting across the wrong boundary. You modularized well because you created a clean, separated, thought-out architecture, not because of any intrinsic property of microservices.

Post reply on HN