Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

341–350 of 469 posts

Re: The Death of Microservice Madness in 2018

#341

Earlier quoted context omitted.

This is Parkinson's Law of Triviality. https://en.wikipedia.org/wiki/Law_of_triviality

It is frightening to see bikeshedding in practice. I used to work for a regional transportation authority that would administer hundreds of millions of dollars in federal/state/local road projects. Local leaders would monthly come in and sit at a huge round table (40-50 cities/counties/regional leaders) and vote on projects. 800 million dollar projects would sail through with almost no questions in the first five min…

Why? Do some of them have something against helping the homeless on principle?

Re: The Death of Microservice Madness in 2018

#342

Earlier quoted context omitted.

This is Parkinson's Law of Triviality. https://en.wikipedia.org/wiki/Law_of_triviality

It is frightening to see bikeshedding in practice. I used to work for a regional transportation authority that would administer hundreds of millions of dollars in federal/state/local road projects. Local leaders would monthly come in and sit at a huge round table (40-50 cities/counties/regional leaders) and vote on projects. 800 million dollar projects would sail through with almost no questions in the first five min…

I once sat in the board of a student organisation management a $3mil investment fund. Which was rapidly declining as funds where being withdrawn to cover budget deficits. At the same meeting where no-one could explain, and no-one seemed to care about a 100,000$ transaction listed as “assorted expenses”, people spend 1,5 hours debating whether the coffee-shop should keep buying newspapers for 200$ a year...

Re: The Death of Microservice Madness in 2018

#343

Earlier quoted context omitted.

> When I see a team of 7 deciding to go with microservices for a new project I know they're gonna be in for a world of unnecessary pain. Faced this a couple of years ago, and I was the lone dissenting voice suggesting this was not going to go well. Then I learned that "microservice" in reality just meant everything was going to be one nodejs process running endpoints, with ios and android clients hitting it, which...…

If you are slightly careful and put this service behind a load-balancer/reverse-proxy you can take any given set of end points and turn them into a micro-service when you need to. Sounds perfect for a small team.

you could. in this particular case, if memory serves, we had an existing set of endpoints functioning, but people deemed it in need of rewrite to node, because 'microservice'. Instead of putting the code we had behind proxy then migrating, we had to start over. because 'scale' and 'microservice'. and 'lambda'.

Also, the same team spent several hours in meetings deciding whether or not to allow email signup, or facebook signup, or both, or neither, in the mobile app. Then had the same discussions/arguments a few weeks later when a couple new people joined the team.

I realize I sound a bit bitter. I got pushback because I'd used the 'microservice api' in a "we don't like that" language. consuming the api (which I'd understood to be part of the reason of having a central API vs just hitting db tables directly) by anything that wasn't also node was outside the groupthink, and caused problems.

I left the project.

They've got their microservice architecture, but no userbase (yet?) to be concerned about scaling issues.

I understand it's reasonable to be concerned about potential scaling problems, the team/project spent far too much time chasing architectural perfection (and really... 'shiny new stuff') vs executing a marketing plan. It's easier for a group that is tech-folk-heavy to focus on that; I get it. But it didn't solve any problems at hand. But when the mythical "2 million users in an hour" problem happens, it'll probably hold up, unless it doesn't.

Re: The Death of Microservice Madness in 2018

#344

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…

But in fact, K8s provides more robustness than old good kinda monolith Pacemaker

Re: The Death of Microservice Madness in 2018

#345

Earlier quoted context omitted.

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

Not sure where you're from but in Germany there are industry standards professionals have to adhere to. Sure, there are sloppy professionals like in any other job too but if they adhere to the industry standards, the result will be pretty much what you expect and they're not allowed to take shortcuts that result in lower quality work.

On the other hand, coming from a country that takes its trades extremely serious, I was shocked about what I observed every time I visited the UK. It seems the expectations vary drastically between different countries (though I'm sure there are quality professionals in the UK too).

Re: The Death of Microservice Madness in 2018

#347
post #319

Earlier quoted context omitted.

And how is that not also service oriented architecture? That's also supposed to be modular and one of the reasons for splitting out service is to scale. You can then place those services in a cloud...

Microservice architectures are a sub-category of SOA. Many of the same reasons to use them apply to both, but with a finer granularity on what is being hosted where and how it is scaling with microservices. Scaling a service with multiple facets going through it gets tricky, hence a desire for a more appropriate modularity. "Placing services in the cloud" kinda papers over why microservices and cloud-native apps hang…

Yes, I agree. My concern is more that microservices (as a sub-category of SOA) are a fad that few people will care about or use 10-20 years from now. Most services probably don't ever go beyond monolith, the rest move to SOA and probably a minuscule minority actually needs microservices.

Re: The Death of Microservice Madness in 2018

#348

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…

This is usually true but I’ve recently been introduced to a legacy codebase which is so bad it can hardly be modified.

Mixed tabs and spaces, sometimes one space indentation or no indentation at all, 1000+ line Java methods, meaningless variable names, no comments or documentation. SQL transactions aren’t used, the database is just put into a bad state and hopefully the user finishes what they’re doing so it doesn’t stay that way. That’s just the server. The UI is just as bad and based on Flash (but compiled to HTML5 now)

Re: The Death of Microservice Madness in 2018

#349

Earlier quoted context omitted.

Great analogy. I tried to paint my own flat. Was a disaster.

I've tried to hang sheet rock. How hard could it be? It certainly looks easy. A disaster for me, too.

I'm a die-hard DIYer. I hire out drywall and blueboard/skimcoat work. Two guys who do that work everyday can do in a 6-hour day and ~$800 what it would take me two weeks and $300 in materials and their job looks 4x better than mine.

Re: The Death of Microservice Madness in 2018

#350

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.

Actually, there's nothing that difficult about painting after the first one or two jobs anyone with half a brain can figure it out. "Painter" is the #1 job role for alcoholics. Every paint can opener is also a bottle opener.
Post reply on HN