Live data from Hacker News

The End of Microservices

lightstep.com

41–50 of 154 posts

Re: The End of Microservices

#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 subtracted to at will depending on the prevailing need. It's silly to declare any of these fads dead or alive, they're just simply techniques that ...people... have bundled together under a common label

Re: The End of Microservices

#42
post #38

Earlier quoted context omitted.

Oh yeah, I don't think it's bad research going into this. I mean I've been writing software professionally for almost 20 years now and I am super excited about (for example) containerization and other trendy areas. I think it's great that people are pushing the boundaries of SOAs, and I think microservice is a good term describing how the boundaries are being pushed. We will all benefit from the improved tooling and…

I agree completely. I may simply have had the luxury of so far working in environments wherein software fads aren't hailed as Swiss-Army panaceas. Here's to hoping my track record doesn't ever trend Dilbertesque :)

Me too. At this point in my career I've worked very closely with more than 100 programmers for long periods of time, and only one of them would I classify as being overly interested in fads. To the contrary, I give a ton of credit to the vast majority of programmers as always being pragmatic about the problem at hand.

I think the problem lies more in the PR, advocacy and conference circuits where there's an incentive and agenda to present things as silver bullets. It mirrors a greater problem in public discourse that everything has become so polarized that nuanced debate is drowned out by noisy, confident blowhards.

Re: The End of Microservices

#43
Ok. I'll be the guy to bring up the Elixir/Erlang ideology that has gained such popularity here. Although I don't have a ton of experience with it yet it seems like the possibility of having the idea of "services" built into the language/framework design is very realistic. That's exciting for me. Although true SOA can be a mix of many technologies I personally find that scary. What happens when your whole platform ends up as a web of services on different technologies and you lose various talent? Now you have to recruit all kinds of different expertise or hope that certain services keep ticking without that knowledge in house.

Re: The End of Microservices

#44
Ok. I'll be the guy to bring up the Elixir/Erlang ideology that has gained such popularity here. Although I don't have a ton of experience with it yet it seems like the possibility of having the idea of "services" built into the language/framework design is very realistic. That's exciting for me. Although true SOA can be a mix of many technologies I personally find that scary. What happens when your whole platform ends up as a web of services on different technologies and you lose various talent? Now you have to recruit all kinds of different expertise or hope that certain services keep ticking without that knowledge in house.

Re: The End of Microservices

#45
post #38

Earlier quoted context omitted.

I agree completely. I may simply have had the luxury of so far working in environments wherein software fads aren't hailed as Swiss-Army panaceas. Here's to hoping my track record doesn't ever trend Dilbertesque :)

Me too. At this point in my career I've worked very closely with more than 100 programmers for long periods of time, and only one of them would I classify as being overly interested in fads. To the contrary, I give a ton of credit to the vast majority of programmers as always being pragmatic about the problem at hand. I think the problem lies more in the PR, advocacy and conference circuits where there's an incentive…

"The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt." (Bertrand Russell)

Back when I was still an employee, I strove to take a more intermediate tact that let me be more vocal about technical direction. What's surprising is how willingly people with authority will listen to what you have to say, once they realize you know what you're doing. I've also been fortunate to have had roles that enabled that in the first place. And now I'm trying my hand at entrepreneurship, which feels practically utopian :)

Re: The End of Microservices

#46
post #15

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…

It's all a balancing act. The two main contenders are developers and scalability. It makes no sense for a single team to run 2000 microservices that come together into a single app. The amount of overhead for managing so many interfaces is insane. At the same time, it's hard to justify 2000 developers working on a single binary. You end up with entire teams dedicated to managing and deploying. Companies do it (Google…

You got the Google part wrong. Google is all in on microservice architecture and has over a decade of experience doing it. There is not some gigantic google.exe program. Perhaps you have heard that Google uses a single source code repo and drew an incorrect conclusion.

Re: The End of Microservices

#47
re: "it was never the size of the services that mattered: it was the connections and the relationships between them"

re relationships I would say these are better thought of through the lens of separation of concerns.

imo, connections, a la protocols like http will fade into the background and be a focus of ops. A piece of code knows to write/read data to/from _________, for which it has been authorized access by address/hashname/entity.

Re: The End of Microservices

#48
I'm not totally convinced that allowing developers to build faster is really all that great of an idea. At least not the sacred ideal that seems to be accepted without any question.

Most of what I see when people are moving fast is building things as fast as they can think of them based on the first idea that comes to mind that sounds like it might get things done.

But the reality is that the first way that you think of implementing something isn't always the best. It's often just about the worst. Giving people the ability to take any whim of a design and run with it all the way to production isn't the best thing overall for software quality.

Perhaps I'm alone here, but I'd like for developers to slow down and put some thought into what they are building, and how it's supposed to work, and if it's going to be able to do what it needs to do. I see a lot of "close enough" in my line of work.

I know it's different in a startup, where testing the idea now is important, and I'm not slamming that. But the vast majority of developers don't work in startups where getting a product to market before a competitor is the difference between making billions and going home broke.

We temper our desire for perfection by reminding ourselves that good enough is okay for now. I'd like us to temper our desire for speed by remembering that there is such a thing as soon enough.

Re: The End of Microservices

#49

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…

[deleted]

Re: The End of Microservices

#50
I'm sorry -- I think the author completely misses the point about why microservices were controversial at all?

Distributed systems are not the same as centralized ones, and you cannot paper over the differences between the two. It is wrong to think that distributed microservices will completely replace centralized services in some future paradise. The difference is not a tech fad; it's more like a law of nature. Distributed systems should plan for network failures, yet nobody wants to get a "503" from their CPU.

Post reply on HN