Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

Post reply on HN
Print view View original

291–300 of 469 posts

Re: The Death of Microservice Madness in 2018

#291

Post by dancek »

simias wrote: post #268
shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

The #1 thing they should teach in any engineering school (or maybe any school period ) is "you shouldn't remove/replace/change something until you've understood why it was done that way in the first place". Or maybe a somewhat equivalent version: "you're not as clever as you think you are and the people who came before you were not as dumb as you think they were".

This principle is commonly known as Chesterton's fence. https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Re: The Death of Microservice Madness in 2018

#292

Post by madshiva »

dreamcompiler wrote: post #175
shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.

A real hacker can fix is car, paint that wall, and can code too.

There is no problem painting for me and many others who know how to use their hand.

Is amazing when you talk to people and they are like: Did you do that? How do you know how to do that?

Learn, try and you can do anything. As people did at every step.

Re: The Death of Microservice Madness in 2018

#293

Post by deepGem »

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

I wonder why. Isn't it so unproductive to keep tearing down stuff and rebuilding them with the next shiniest tool ? I mean, you are making very little progress on product features.

Re: The Death of Microservice Madness in 2018

#294

Post by McP »

ivan_gammel wrote: post #290
pjmlp wrote: post #229

Earlier quoted context omitted.

They can manage those teams by writing libraries, no need for microservices.

It's much harder to deploy a library fix to production (producing a new build of integrated app in large team is a big deal), than a microservice.

It shouldn't be a big deal. https://en.wikipedia.org/wiki/Continuous_delivery

Re: The Death of Microservice Madness in 2018

#295

Post by chillidoor »

shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

While I'm not arguing with you, I have had a different experience working with developers and microservices, perhaps because the teams have been more seasoned/experienced and there is more of a collaborative environment.

I found that a lot of the time developers start moving towards microservices when they find that a monolithic app becomes too difficult to work on. For example, multiple teams working on the same codebase will often have accidental code conflicts. Plus, scaling a monolithic app because one part of it is under load isn't always cost effective or logical. So, teams will start to break off components into microservices to make development easier and less painful. Naturally this has to be weighed up as microservices bring a different set of challenges, 'gotchas', etc, etc but in my experience the teams have done a proper job discussing the pros and cons.

Re: The Death of Microservice Madness in 2018

#296

Post by cocktailpeanuts »

Here's my experience. Some features are extremely good as Microservices. And I wanted to use it. But I don't. Why?

1. Setting up a "Microservices" architecture itself is a convoluted process. If you're not a Netflix or Amazon that will run hundreds of microservices, the up-front cost and time is NOT at all worth it. I would rather just run an app on Digitalocean.

2. IF I decided to bypass step 1 and just use existing vendors like AWS, Google, Microsoft, etc., first I don't feel good about it because I know it's in each vendor's best interest to implement lockin, which conflicts with my own interest.

3. Lastly, none of the existing cloud function vendors have good user experience. AWS Lambda, Google cloud functions, etc. all require you to go through all the authentication related stuff before running a simple function, not to mention all the constraints that come with "function based paradigm". Again, definitely not worth it unless you're trying to run hundreds of these functions.

I think part 3 is critical, because I was willing to ignore part 1 and 2, as long as I could get my function up and running really easily. But none of the vendors make it easy. Sure, there are frameworks that let you do that like Apex and Serverless, but those also require setup. I would rather just run a DigitalOcean server for $5 which by the way can run multiple of those services as a regular server, without me having to spend time dealing with the complexities of function servers.

I thought about how this could be improved. Sure there can be some "Heroku for functions" SaaS, but nobody is excited about building SaaS startups nowadays because they know they can't compete with large vendors in the very long run. (Unless you're comfortable with just building a lifestyle business, which is totally fine, but I personally won't rely on a lifestyle business SaaS)

The only way this can be improved is if each root vendors like Amazon, MS, and Google actually implemented better UI, but none of them are really focused on this since the reason they're doing this business in the first place is not for consumers but to make sure they have leverage in this space. (If AWS dominated 90%+ of this market, the rest of the companies will be in a great risk in the long run)

Re: The Death of Microservice Madness in 2018

#297

Post by lmm »

rtpg wrote: post #146
shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

Do you legit think that people are all just doing this as a fad? There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course. The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And it…

> Do you legit think that people are all just doing this as a fad?

Yes. That's been my experience.

> The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too.

Most organisations aren't Amazon. Most organisations aren't Twitter. And even these web-scale organisations aren't as all-in as the microservice advocates. (I worked at last.fm for a time and while we did many things that could be classed as "microservices" from a certain perspective, we didn't blindly "microservice all the things")

> "Microservices as mass delusion" discounts a lot of people who are really thinking hard about how to handle the pros and the cons of things.

Most fads start from a core of sensible design. The web really did revolutionise commerce, but many "x, but on the web" companies of the late '90s really were dumb.

Re: The Death of Microservice Madness in 2018

#298

Post by styfle »

> If your boundaries are actually not well defined, then what happens is that even though theoretically services can be deployed in isolation, you find that due to the inter-dependencies between services, you have to deploy sets of services as a group.

This is the part I keep getting hung up on. Even with perfect boundaries, there always seems to be a cross-cutting feature that would require touching all of the services.

Re: The Death of Microservice Madness in 2018

#299

Post by danieltillett »

dreamcompiler wrote: post #175
shitloadofbooks wrote: post #54

I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…

I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.

My experience is a careful amateur painter is 1000% better than an average professional. Professionals are certainly a lot faster, but if you look carefully at their work it is in the main very shoddy.

If you want a good result don’t skimp on the tools. Buy good quality brushes, rollers, filler, throws and paint. Also buy an edger to cut in the walls and ceilings. One final tip buy some of the disposable plastic liners for the roller tray so you don’t have to spend time washing out the tray at the end of the day.

Re: The Death of Microservice Madness in 2018

#300

Post by lmm »

philwelch wrote: post #209
rtpg wrote: post #146

Earlier quoted context omitted.

Do you legit think that people are all just doing this as a fad? There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course. The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And it…

The ops cost of not using microservices is a lot higher than you'd think, too. At some point, when you have hundreds of engineers and your monolith is compiled together from libraries written by a dozen different teams and you have to try and make one heroic release per week, except half the time it fails and you have to go back and fix it, and absolutely no one in the company can ship a new feature because you're bl…

You don't need microservices to fix that, you need CI and maybe some release processes for your libraries.

There will come a point where you can't scale a monolith, sure, but that point is thousands rather than hundreds of engineers.

Post reply on HN