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

461–469 of 469 posts

Re: The Death of Microservice Madness in 2018

#461

Post by warrenm »

logfromblammo wrote: post #404
madshiva wrote: post #292

Earlier quoted context omitted.

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.

The hardest part is knowing when it is a better use of your time to hire someone else to do it for you. You can just follow all the same steps as you usually do: 1. Define the problem. 2. Determine the desired outcome. 3. Measure the existing state. 4. Note the foreseeable failure modes. 5. Plot the path from existing state to desired outcome as a series of reasonable steps, avoiding the failure modes. 6. Recursively…

>You can't, for instance, justify buying a specialized tool to finish just one job

You must be new to DIY :)

Re: The Death of Microservice Madness in 2018

#462

Post by warrenm »

maxsilver wrote: post #416
bonesss wrote: post #310

Earlier quoted context omitted.

[Disclaimer: I've never worked for MS or Amazon, working solely off of reported info here...] A kinda-random example off the top of my head of "shipping the org chart" would be the historical gaps between Windows, Development, and Office at Microsoft. Ie Office is getting a new ribbon, but no development can't supply those icons or any components because they're an "office thing", or the internal API/VBA battles alon…

My favourite Microsoft 'ship the org chart' example is their app store. Microsoft has an app store built into every Windows 10 computer worldwide. And of course, you can not download Microsoft Office from it. However, it does helpfully tell you to get Office by heading to 'MicrosoftStore.com'. It's all sort of head scratching. A normal person might ask a lot of totally reasonable questions about this, like: - Why doe…

Definitely a broken "app store" vs, say, Apple's model - where you can get any Apple software you want from it for your Apple devices.

(Isn't it the only way to get Apple software for your Apple devices, even?)

Re: The Death of Microservice Madness in 2018

#463

Post by mstade »

warrenm wrote: post #457
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…

You need to be keeping a ledger on technical debt, the same way any and all other "debt" is tracked - http://www.hydrick.net/?p=2394 "Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off wh…

I was wondering how such a ledger might work, given that it should be about as difficult to quantify this kind of debt as it may be to estimate the time and effort required to implement certain changes in general. Later on in the post, there's this nugget of gold:

    So how would this ledger work? Well, for starters it has to
    track what we can’t do because of current technical debt.
    It should also be updatable to note any complications to 
    subsequent work or things you can’t do yet because for old 
    design decisions. At this point, you’re tracking the 
    “principle” (the original design decision causing technical 
    debt) and interest (the future work that was impacted by 
    the debt).
That's it, isn't it? You need to define the principle and the interest, and these two are actual tangible things in the form of specific decisions (principle) and things that are now adversely affected by them (interest.) If these are linkable, then it should become trivial to compute a number to this debt, whether it is simply just the number of things adversely affected or some other kind of aggregate like the combined estimated effort of those adversely affected things. This debt could probably be calculated in many different ways, but the fact that you can properly quantify it should make decisions on whether to tackle or ignore the debt much more informed.

This was an eye opener for me – thanks for sharing!

Re: The Death of Microservice Madness in 2018

#464

Post by danieltillett »

Nomentatus wrote: post #454
danieltillett wrote: post #430

Earlier quoted context omitted.

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…

Next time two (or at most three) coats - the first coverup coat should be black, since the purple (or red or whatever) won't show through black.

I think black to white is going to take more than two coats of white.

I have used gray before to go from red to yellow as it seems to work in fewer steps.

Re: The Death of Microservice Madness in 2018

#465

Post by Ericson2314 »

saryant wrote: post #204
Ericson2314 wrote: post #172

Microservices (in practice) are like polyglot: throwing away type safety for no good reason. This shit needs to stop.

You don't have to use JSON-over-HTTP. You can use something like Thrift or Protobuf which gives you statically-typed inter-process communication.

You're completely missing the point. I shouldn't be able to connect two interface-mismatched services in the first place.

Re: The Death of Microservice Madness in 2018

#466

Post by ingas »

klodolph wrote: post #152

Background… I’ve been on good and bad projects that used microservices, and good and bad monolithic projects. The madness is going away but the microservices are staying. There are some rationales for microservices that are conspicuously missing. 1. Fault isolation. Transcoder stuck in a crash loop? Upload service using too much RAM? With microservices, you don't even really have to figure out what's going on, you ca…

But "OO design itself" had(still has) a major flaw: it was not clearly defined. Everybody had his/her own unique vision of "OO design".

Re: The Death of Microservice Madness in 2018

#467

Post by pluma »

hoopladler wrote: post #446
pluma wrote: post #345

Earlier quoted context omitted.

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…

It doesn't make too much sense to do quality work in the UK, on the whole. House price / rent value is basically dependent on location. Money spent on fitting is generally wasted. There are a lot of great craftsmen in the UK, but they tend to work on a subset of jobs - restoration, passion projects, really high-end stuff. PS: This is also a direct result of ever-rising house prices. If land/house prices are consisten…

That explains a lot. Thank you.

Re: The Death of Microservice Madness in 2018

#468

Post by therealdrag0 »

walrus1066 wrote: post #269
z3t4 wrote: post #43

Earlier quoted context omitted.

You don't always have to know why but it's somewhat frightening that so many "engineers" don't have a clue why they are doing something (because Google does it). And I'm of course guilty of it myself jumping on the hype-train or uncritically taking advice from domain experts only to find out years later that much of it was BS. Most of the time though, you will not reach enlightenment. I guess it's in our nature to fo…

They're only following their incentives. What's gonna look better on a devs CV: 'spent a year maintaining a CRUD monolith app' vs 'spent a year breaking monolith into microservices, with shiny language X to boot'. We can be a very fashion and buzzword driven industry sometimes. EDIT: this perverse incentive goes all they way to the top, through to CTO level. Sometimes I wonder if businesses understand just how much m…

"Resume driven development" :)

Re: The Death of Microservice Madness in 2018

#469

Post by warrenm »

mstade wrote: post #463
warrenm wrote: post #457

Earlier quoted context omitted.

You need to be keeping a ledger on technical debt, the same way any and all other "debt" is tracked - http://www.hydrick.net/?p=2394 "Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off wh…

I was wondering how such a ledger might work, given that it should be about as difficult to quantify this kind of debt as it may be to estimate the time and effort required to implement certain changes in general. Later on in the post, there's this nugget of gold: So how would this ledger work? Well, for starters it has to track what we can’t do because of current technical debt. It should also be updatable to note a…

Figuring how to link the “principal” and “interest” is definitely the lynchpin ... but if you’re not even noting there is principal and interest, you’ll never be able to recover
Post reply on HN