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

441–450 of 469 posts

Re: The Death of Microservice Madness in 2018

#441

Post by ska »

philipodonnell wrote: post #417
ska wrote: post #389

Earlier quoted context omitted.

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

   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.
That’s an oversimplification, and not the argument I was attempting.

For what it’s worth, I don’t think we are really disagreeing much.

Re: The Death of Microservice Madness in 2018

#442

Post by tehlike »

deepsun wrote: post #411
tehlike wrote: post #137

Earlier quoted context omitted.

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.

Were the previous ones not getting the job done? 4 rewrites over what time period?

I am more in the camp of "let's do something useful" than "let's rewrite this because previous guy didn't do it good, or it no longer meets our demands". Because whatever you do it will get rewritten again, and it's imho useful to resist the urge.

Ps: also a googler.

Re: The Death of Microservice Madness in 2018

#443

Post by mathattack »

ianamartin wrote: post #309
mathattack wrote: post #80

Earlier quoted context omitted.

Do you have examples of micro services and good data warehouses working well side by side? Your point makes sense, but I keep hoping for a way to have One Data Source Truth working side by side with the services that across it.

A data warehouse really should be completely orthogonal to any architecture choices. Good data warehouses are fed by data engineering pipelines that don’t care if you have a single rdbms or multiple document stores or people dropping CSVs in an FTP directory. I hate to burst your bubble, but you shouldn’t and can’t have truth working along side systems that access it. Data is messy and tends toward dishonesty. The on…

This is my intuition too - but better written. Thanks!

Re: The Death of Microservice Madness in 2018

#445

Post by alenmilk »

bigiain wrote: post #216
mauritzio wrote: post #207

Earlier quoted context omitted.

Sounds for me like productivity went down...

I think the complexity of solutions has gone up (especially in webdev), it seems to me perhaps complexity has gone up way further than actual requirements or new features would suggest... Which seems to end up meaning productivity has gone down when measured by "things end users of websites can do", even though modern FE devs end up creating much more code and html and css than "the old days". (Admittedly, if you inc…

In the old days if you managed to create a website it was great. Now people compare everything with Google and Facebook. If you just put something together fast people would just laugh at you. So everything takes a lot longer. The effect is that you get to solve less problems.

Re: The Death of Microservice Madness in 2018

#446

Post by hoopladler »

pluma wrote: post #345
danieltillett wrote: post #299

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…

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 consistently rising, it often makes more sense to let lots stay empty, rather than building (which is always a massive risk). It also makes sense to do any repair or upkeep work as cheaply as possible - since in a rising market, the only way you can lose money is by expensive development costs.

Re: The Death of Microservice Madness in 2018

#447

Post by SOLAR_FIELDS »

versk wrote: post #399
SOLAR_FIELDS wrote: post #315

Earlier quoted context omitted.

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'm skeptical 800 million dollar projects would pass through local government at that level in 5 minutes, unless everyone who voted in favor had already been canvassed or taken part in intense debates at other meetings or were rubber stamping a special committee decision etc. What regional authority was it where 800 million dollar projects happened so regularly?

This was a transportation authority for a large metro region. CTRMA (Central Texas Regional Mobility Authority) is an example that works with large projects like this all the time, though it wasn’t the one I worked for.

Re: The Death of Microservice Madness in 2018

#448

Post by philipodonnell »

ska wrote: post #441
philipodonnell wrote: post #417

Earlier quoted context omitted.

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

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. That’s an oversimplification, and not the argument I was attempting. For what it’s worth, I don’t think we are really disagreeing much.

Not at all, merely pointing out an aspect of this trade-off that I often hear described as irrational based on the exact oversimplification that you pointed out. Consider my comment an addendum to yours. :-)

Re: The Death of Microservice Madness in 2018

#449

Post by ivan_gammel »

coldtea wrote: post #335
ivan_gammel wrote: post #290

Earlier quoted context omitted.

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.

You'd be surprised. With a microservice you still need to coordinate the release with other consumers of it.

I'm well aware of that. This type of coordination is much easier, than producing a new build in a complex corporate environment. The delivery of microservice is limited in most cases to the change in environment inventory file and integration testing. The delivery of the build requires source code management (you'll need to push the dependency change in the right branch), probably, full application SQA cycle (to make sure there's no side effects, e.g. due to transitive dependency update) and only then - deployment and integration testing.

Re: The Death of Microservice Madness in 2018

#450

Post by mattknox »

It's fascinating to me that people don't point out that you can get many of the benefits of microservices with all your code in a monolith, indeed, all in a single runtime. Of the 4 benefits he lists (1: independent development, 2: independent deployment 3: independent scalability, 4: reusability) you can mostly get 2-4 by deploying your monolith to different server pools that are deployed and routed to independently.

Microservices get to be necessary for large dev teams, but probably a lot later than most teams think.

Post reply on HN