Live data from Hacker News

You Don't Need Microservices

medium.com

111–120 of 169 posts

Re: You Don't Need Microservices

#111
You do need microservices because when when parts of you system are badly written or the requirements change, etc, etc..

You can just shoot a couple of the offending microservices dead and replace them with better implemented versions.

[Assuming there are at least 6 developers]

Re: You Don't Need Microservices

#112

You do need microservices because when when parts of you system are badly written or the requirements change, etc, etc.. You can just shoot a couple of the offending microservices dead and replace them with better implemented versions. [Assuming there are at least 6 developers]

That’s the story for them. I also think it’s possible to do this with code for APIs in different files.

Re: You Don't Need Microservices

#113

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

A friend of mine is working on a 20 years old Microservices application. It is literally the worst piece of garbage system I have ever heard about. I am sure my friend would have loved for it to be a monolith instead of 50+ services with massively complicated distributed dependencies and timing issues.

Re: You Don't Need Microservices

#114

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making du…

If you don’t have the skills to implement a well structured and easy to maintain monolith then you most definitely don’t have the skills to implement a distributed more complex implementation of the same system.

Re: You Don't Need Microservices

#115
I don’t know if you will need microservices or not. I can tell you that many developers and teams will do microservices poorly and will not get an advantage out of it and will have an even more complex ball of mud to maintain.

Re: You Don't Need Microservices

#116

Earlier quoted context omitted.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making du…

If you don’t have the skills to implement a well structured and easy to maintain monolith then you most definitely don’t have the skills to implement a distributed more complex implementation of the same system.

On the contrary. An experienced architect defines the boundaries and then the microservice architecture enforced them in a way that a monolithic architecture cannot.

Re: You Don't Need Microservices

#117

Earlier quoted context omitted.

If you don’t have the skills to implement a well structured and easy to maintain monolith then you most definitely don’t have the skills to implement a distributed more complex implementation of the same system.

On the contrary. An experienced architect defines the boundaries and then the microservice architecture enforced them in a way that a monolithic architecture cannot.

On the contrary. Using libraries with clearly defined interfaces makes it easier to combine those libraries into a single executable, reducing deployment and debugging complexity. It also dramatically improves performance given the lack of intermediate encoding/decoding protocol code and TCP/UDP hops. Experienced seasoned Architects knows this and work hard to remove unnecessary distributed complexity from systems they design. While “beginner experts” always pick the most complex “solution” for the job at hand. The worst spaghetti code I have ever seen in my 30+ year career is a 20+ years old Microservices architecture. So I can’t wait to read the future “We had a problem so we chose micro-services. Now we have N distributed problems + K impossible to debug obscure timing issues” articles.

Re: You Don't Need Microservices

#119

I’ve worked for decades now as both a developer and an SRE and have never once thought either “man I wish these microservices were monolithic” nor “man this monolith is so great I’m glad it’s not a collection of microservices”. These kinds of articles seem to be written for people who work in environments I’ve never even heard of let alone experienced.

Same. I keep hearing that people have had bad experiences with microservices, but I'm not sure what those bad experiences are. I certainly don't relate to them. We had a monolith, and it devolved into a mess--managers would insist on people taking dependencies on stuff they didn't own in the name of expedience ("yeah, we'll totally circle back and do it the right way lol"). Microservices kept things neat by making du…

At a multibillion dollar company, local development is impossible, staging doesn't exist, most stack traces from production are truncated because the log aggregator cannot handle log entries as large as java stack traces, and most of the work involves migrating from talking to the database to talking to a microservice that exposes a single table of the database. What are joins?

At another company that was acquired by Amazon, the "user service" team (so again this is a microservice that exposes a single table of a database, this time with a two-pizza team dedicated entirely to that microservice) told us that we couldn't just query the user service when we wanted to render a page containing a username given a user id, because that was too many queries. Product demands from a VP dictated that we didn't have time to set up our own caching layer for their service (is this the responsibility of every team other than theirs?), so we shipped the feature with the usernames saved in our own DB, and now when users change their usernames the old name will appear in the pages for our feature, depending on when the pages were created.

Post reply on HN