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
The End of Microservices
41–50 of 154 posts
Re: The End of Microservices
#42Earlier 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 :)
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
#43Re: The End of Microservices
#44Re: The End of Microservices
#45Earlier 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…
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
#46Equating "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…
Re: The End of Microservices
#47re 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
#48Most 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
#49I 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…
Re: The End of Microservices
#50Distributed 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.