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

411–420 of 469 posts

Re: The Death of Microservice Madness in 2018

#411

Post by deepsun »

tehlike wrote: post #137
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…

If something isn't broken, do not fix. I think part of it is that large companies can keep engineers happy by giving them rewrites. Otherwise, not enough projects to keep everyone entertained.

Well, the best architectured project I've ever worked on in Google was actually rewritten 4 times from scratch. I believe rewriting is always good for the project. Not always for business, though. Fortunately, Google had resources to allow rewrites to happen.

Rewrites also serve as thorough code review and security audit.

Re: The Death of Microservice Madness in 2018

#412

Post by efa »

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 100% agree. I even catch myself thinking I didn't know what I was doing when looking at code I wrote years before. I'll jump into rewriting it and discover it was written that way for a reason. I've learned to trust my former self wasn't an idiot.

Re: The Death of Microservice Madness in 2018

#413

Post by cjalmeida »

jimktrains2 wrote: post #53
cjalmeida wrote: post #42

Earlier quoted context omitted.

In proper microservices architecture only a single application access the DB. Other apps get the data via an API call. Thus you can drop the column (maybe it's derived data) and still keep the API interface. In the end, it's mostly about enforcing contracts and making devops simpler.

I mean, that's not true at all. No two apps should be working off the same database. Different services can have their own datastores.

Reading back, my post was confusing. What you wrote was what I actually meant. Each app may have it's own non shared DB.

Re: The Death of Microservice Madness in 2018

#414

Post by gadders »

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…

Things you should never do, Part 1: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: The Death of Microservice Madness in 2018

#415

Post by slackpad »

flukus wrote: post #140
Chiba-City wrote: post #92

Reminds me of distributed architectures like CORBA turning into spaghetti in the 90's.

Seems like every ten years or so a new architecture comes along and quickly devolves into into being yet another distributed RPC mechanism. There was CORBA, SOAP, SOA and now micro services. All promised to fix what came before and all ended up repeating the same mistakes in practice. Can any of the old timers here name any predecessors to CORBA?

Sun ONC RPC - https://en.wikipedia.org/wiki/Open_Network_Computing_Remote_...

Re: The Death of Microservice Madness in 2018

#416

Post by maxsilver »

bonesss wrote: post #310
bmer wrote: post #157

Earlier quoted context omitted.

> ...but too often extrinsic factors such as the arrangement of dev's desks dictates the architecture. hahaha Do you know if there are some well chronicled cases of this happening? I find it very believable, but you know, would love to read something "actual".

[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 does Microsoft's App Store not have Microsoft's own Apps in it? Office isn't the only missing app, Visual Studio is missing too (even the free 'Code' electron editor).

- Why does the phrase 'Microsoft Store' refer to something 100% different (in products and functions) than 'MicrosoftStore.com'?

- Why does the Office team have their own app updating utility, when there's already supposed to be one 'blessed' place for App Updates inside the Store? (Same question for Visual Studio Code).

---

Anyway, I know a lot of the above is org chart related, or enterprise needs / backwards compatibility related. But they are all reasonable questions despite that.

And stuff like this is part of the reason why reasonable people still fall for phishing schemes. The above sounded to me like some weird popup advertisement trick, until I saw it first hand.

Re: The Death of Microservice Madness in 2018

#417

Post by philipodonnell »

ska wrote: post #389
marcosdumay wrote: post #386

Earlier quoted context omitted.

> economically irrational I am not sure that description is apt. Underdelivering is only rational for the painter because the client won't be on the market long enough to gather sufficient information. The client is getting cheated, and it creates a lemons market, the fact that it is a Nash equilibrium does not make avoiding the entire thing irrational. And the entire thing has parallels on software development...

I meant it in a similar sense to that in which some hobbies are often irrational if you consider them only for market value. I probably could have chosen a better term. An amateur painter will often spend far more time than any reasonable estimation of the market value of that job would justify. Part of this is lack of efficiency and experience, but another part is doing things with sharply diminishing returns. For e…

> amateurs can easily arrive at a finished job (of painting, in this case) that they would never be able to convince themselves to pay market rate for.

If you're looking at it from a economic standpoint, to be considered irrational, the tradeoff between the value of time vs the cost of hiring a professional would have to assume that the value of the time is greater than the value of the professional.

I always hear this compared to "what is your hourly rate in your job" or "my time is worth more than that", but I think for most people this just isn't a fair comparison. Just because I can spend 10 hours painting my room and I make $x/hour and it would cost For most people on a salary (where your pay is fixed no matter how much time you put in), their time outside of the job is, in a very real sense from an economic standpoint, valueless, and it would be perfectly rational to spend that time yourself, no matter how cheaply a professional could do it.

Re: The Death of Microservice Madness in 2018

#418

Post by GordonS »

lmm wrote: post #300
philwelch wrote: post #209

Earlier quoted context omitted.

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.

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

Re: The Death of Microservice Madness in 2018

#419

Post by philipodonnell »

SOLAR_FIELDS wrote: post #354
crdoconnor wrote: post #341

Earlier quoted context omitted.

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

In that case it was a jobs program (to help construct roads) and the rationale against it was that they were extending beyond their purview of what the commission was meant to do.

Isn't that sort of rational then?

Re: The Death of Microservice Madness in 2018

#420

Post by romaniv »

bonesss wrote: post #336
ozim wrote: post #266

Earlier quoted context omitted.

Services consuming other services, sounds like recipe for spaghetti. I hope people use layering where you don't call stuff that is in the same layer.

> Services consuming other services, sounds like recipe for spaghetti. Can we extend that logic to classes or interfaces? Accessing data operations through a well-established API is generally seen as a good thing and is the exact cure for spaghetti... Service APIs also entail load balancing and decoupled deployments, so they eliminate unclear architecture that arises at the app level when trying to tune the whole for…

>Can we extend that logic to classes or interfaces?

This was one of the main ideas behind the original definition of OOP. The original notion of "object" was very similar to our current notion of "service":

https://www.youtube.com/watch?v=QjJaFG63Hlo

Objects received messages, including messages sent over the network. There was not supposed to be a clear distinction between local and remote services - by design. A lot of inter-computer stuff could be/was handled transparently.

Post reply on HN