Live data from Hacker News

The Death of Microservice Madness in 2018

dwmkerr.com

421–430 of 469 posts

Re: The Death of Microservice Madness in 2018

#421

Earlier quoted context omitted.

I’m confused. If a microservice doesn’t call the api of any other microservices, then when is sending the requests to any of them? A large purpose of service oriented architecture is encapsulation. If no other microservices can make requests to your microservice, then you really haven’t encapsulated much.

I'm thinking this concept improperly conflates synchronous requests with eventually-consistent asynchrony. No, you definitely don't want microservices making synchronous requests to other microservices and depending on them that way. But it still may be necessary for your services to depend on each other, and that's where you can allow that communication through asynchronous eventually consistent communication. Actor…

But a message posted to a queue is a kind of API.

Re: The Death of Microservice Madness in 2018

#422
So it's backlash time already?

A lot of technologies get a lot of hype over the years. But often the backlash is no less ignorant or fashion driven.

Is there a silent majority of us that look at these hype trends, consider them, and make a level-headed decision to see if they fit our problem? I never got into micro-services, because I worked on small teams and it seemed like over-engineering. But it's an idea that I tucked away in the back of my head, that I'd still use if the situation calls for it, HN backlash be damned. The same goes for nosql databases or dynamic scripting languages or anything else that's now irrationally hated.

Re: The Death of Microservice Madness in 2018

#423

Earlier quoted context omitted.

Hi Daniel, It's weird you mention that, I was just chatting to a colleague the other day on this topic, and I rooted out this old article which I loved: www.slideshare.net/ScottWlaschin/ddd-with-fsharptypesystemlondonndc2013 I was lucky enough to work on a big F# project a while ago and really enjoyed the experience, it was the first time I'd done any functional programming in a professional context and I miss it now…

Hey Dave, No problem. There was a ton of good stuff in there! I saved it to refer back to it later. :) As a tech coach, I teach good programming skills, which mostly ends up being TDD and other good coding skills for OOP folks. But I've become a huge pure FP fan over the past decade, learning it all on my own just by struggling through it. So as a coach, I'm seeing more and more of these microservice train wrecks. I'…

Personally I have learned that TDD and unit tests are only useful in OOP settings that have side effects and have mutated state overtime. But with a more FP approach all you need to do is verify the feature works since you know that state can't change the output.

I kind of also feel that TDD has a kind of cult like following, especially with the Rails crowd

Re: The Death of Microservice Madness in 2018

#424

Earlier quoted context omitted.

I recently came across 'sheetrock' as a term and had to google it... For UK natives it's actually three steps: "sheetrock" == drywall == Plasterboard

I have also heard it as "gypsum wallboard", which is certainly most descriptive. I'm not certain whether the water-resistant, mold-resistant variety typically hung behind tiles in bathrooms is ever referred to as "wetwall" or if they still call it "drywall". Nor am I aware of whether anyone calls the foil-backed, glass-reinforced, fire-resistant variety "firewall" instead of "drywall". I wouldn't be surprised if obso…

it is called dry wall because it is installed while already dry. Unlike the old technique of lath and plaster where you build up the wall with multiple layers of wet plaster https://en.wikipedia.org/wiki/Lath_and_plaster

Re: The Death of Microservice Madness in 2018

#425
post #97

Earlier quoted context omitted.

I really think microservices are a process win not a technical win. It's easier and better to have 5 teams of 10 managing 5 services. Then having one team of 50 managing a one super service. 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.

Jesus, 10 people on a team? What are you doing that you need 10 people to work on it? I manage like 8 services by myself.

I get both why people downvoted you and why people defended you.

One developer can certainly be responsible for coding many microservices and even maintaining them depending on the scope, number of users, etc.

Sometimes people might even rotate with a core architect coordinating how they all interact and if they are consistent with each other.

Discussing about microservices can be very confusing if people are thinking about different things and, as always, when there's a good idea implemented in a specific context and people who don't use it get exposed to it as a silver bullet we'll end up with a huge backlash like in this article.

Re: The Death of Microservice Madness in 2018

#426

Earlier quoted context omitted.

You can and should have a cross-functional team (containing both devs and operators) to build and operate your infrastructure automation. But the operation of the individual services still falls on the teams that own them.

Right, but the complexity the author complains about is then not on the individual services’ developer teams.

That's the point, yes?

Re: The Death of Microservice Madness in 2018

#427
post #300

Earlier quoted context omitted.

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.

Also, there is a nice place between microservices and a monolith

I'm gonna just be honest here and say that I don't really know the difference between "microservices" and "service-oriented architecture" except for the notion that "microservices" implies breaking up your services before they get too big and hairy, which kind of seems obvious.

If some companies go completely nuts and deploy 5 microservices per developer, then yes, that is madness. If all of those microservices are REST/JSON microservices, that's madness squared because you're wasting half your time in serialization/deserialization. If you're managing all of this stuff with Kubernetes because it's trendy rather than because it's actually necessary for your use case, then you're probably making a bad call.

But ultimately, services give development teams ownership over features in a complete, end-to-end way that is fundamentally impossible with monoliths once you're past a certain size.

Re: The Death of Microservice Madness in 2018

#428
post #262

Earlier quoted context omitted.

COM+ also had distributed transactions. I was fortunate not to work with it too much.

Was this in the protocol? I thought that was around the same time as DTCC which is pretty good IMO.

I believe COM+ came along and subsumed DTCC, but I'm not sure.

Re: The Death of Microservice Madness in 2018

#429
post #345

Earlier quoted context omitted.

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…

I am in the land of the shonky tradesman - Australia. Not only are they massively overpaid, they make the UK tradesmen look like gods.

Re: The Death of Microservice Madness in 2018

#430
post #370

Earlier quoted context omitted.

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…

I think there are two things at work here. 1 - there are very good professionals, but they aren't cheap and have all the work they need 2 - an amateur can always decide to take economically irrational amounts of time on a project; a professional can't. So the result is that as a careful amateur you can end up with a job you probably wouldn't be able to convince yourself to pay for. We can probably all agree that the…

Here where I live (Australia) it is near impossible to find good professional tradesmen. While it might be irrational on a financial level to spend my time painting or other trades, I get the quality I want by doing it myself.

Even on the financial level tradesmen here in Australia are so overpaid (compared to everyone else) that it makes sense even for me to do it myself. My house was painted by "professionals" just before we moved in (purple??) and it cost the previous owner $20,000. My wife and I repainted it white (this required 5 coats of paint) and it took us two weeks including the time I had to spend getting the purple paint off the windows and floors and patching all the holes that had been painted over.

Tip. If you are selling your home don't paint it some unusual color. I managed to buy my home $200K under its actual market value and quite a bit of this was due to the crazy way the place has been painted.

Post reply on HN