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

391–400 of 469 posts

Re: The Death of Microservice Madness in 2018

#391

Post by marcosdumay »

sokoloff wrote: post #362
McP wrote: post #294

Earlier quoted context omitted.

It shouldn't be a big deal. https://en.wikipedia.org/wiki/Continuous_delivery

It shouldn't, but in practice sometimes is. It's not the pushing of bits that's hard; it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs. Imagine you have a library that implements the serialization and deserialization of something in your system (or anything else where the library implements two "halves" of some func…

> it's the ensuring that the library got everywhere it needed to go and that the new release of the other users of that library didn't introduce any bugs.

And guess what, you have to do the same thing with microservices. You must ensure that all its clients are pointing to the correct version, and you must ensure that the new version didn't add any bugs in the clients.

Adaptations for new service versions will also get into the release queue, and can also get blocked by other stuff.

Re: The Death of Microservice Madness in 2018

#392

Post by crescentfresh »

eadmund wrote: post #155
nemothekid wrote: post #33

Earlier quoted context omitted.

Once when starting a new gig I inherited a "microservices" architecture. They were having performance problems and "needed" to migrate to microservices. They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. Of course if you were using microservices, you needed docker as well, so they had also developed a giant docker container containing all 12 microservices which they de…

> They developed 12 seperate applications, all in the same repo, deployed independently it's own JVM. I've dealt with an even worse system, with a dozen separate applications, each in its own repo, then with various repos containing shared code. But the whole thing was really one interconnected system, such that a change to one component often required changes to the shared code, which required updates to all the oth…

> then with various repos containing shared code

What source control system?

Also, from the article:

> even though theoretically services can be deployed in isolation, you find that due to the inter-dependencies between services, you have to deploy sets of services as a group

This is the situation we are in, like you were.

Re: The Death of Microservice Madness in 2018

#394

Post by ChicagoDave »

corpMaverick wrote: post #387
ChicagoDave wrote: post #186

I've delivered two major applications (400k users, critical internal apps) using micro-services in the cloud reducing cost and increasing continuous delivery capabilities. There are definitely special cases, but overall, after 33 years building software, domain driven design, PaaS, micro-services, and continuous delivery is the most productive paradigm I have ever seen.

How big or small are your micro-services ? how many do you have ? How do you draw the boundaries ?

I can only refer you to Eric Evans book (https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...) and other domain driven design material.

Boundaries are by domain, and yes that's not a simple thing to define. Sometimes, domains have varying interfaces, which makes building micro-services more complex, especially when trying to adhere to REST/Swagger standards (something I'm not overly find of).

But keeping things as simple as possible is really the best approach.

All micro-services should be small. When I see someone say "big", then I'm guessing there are a lot of ad-hoc actions...those need to be broken down into their proper domain or relegated to a query service.

Re: The Death of Microservice Madness in 2018

#395

Post by crescentfresh »

corpMaverick wrote: post #380
kumarvvr wrote: post #233

Earlier quoted context omitted.

> It's not a micro-service if you have API dependencies Just out of curiosity, what alternatives are there to avoid API dependencies? Is it really possible to make non-trivial apps while avoiding internal dependencies? At some level, is it really possible to have a truly decoupled system?

> Just out of curiosity, what alternatives are there to avoid API dependencies? Very important how the boundaries a drawn. Generally, the more fragmented the micro-services the more API dependencies. Also, look at the Bounded Context concept. https://martinfowler.com/bliki/BoundedContext.html And Conway's Law certainly plays a role. http://www.melconway.com/Home/Conways_Law.html > At some level, is it really possible…

I'm wondering if the original "API dependencies" comment didn't mean "shared API dependencies". As in, multiple API/services depending on the same shared code/library.

APIs calling other APIs is...well, I'm having a hard time understanding how that could be construed as fundamentally wrong.

Re: The Death of Microservice Madness in 2018

#396

Post by ChicagoDave »

virmundi wrote: post #223
ChicagoDave wrote: post #186

I've delivered two major applications (400k users, critical internal apps) using micro-services in the cloud reducing cost and increasing continuous delivery capabilities. There are definitely special cases, but overall, after 33 years building software, domain driven design, PaaS, micro-services, and continuous delivery is the most productive paradigm I have ever seen.

Please go on. Can you provide details?

This was one of the projects I was on: https://www.accenture.com/us-en/success-performance-manageme...

Re: The Death of Microservice Madness in 2018

#397

Post by ensignavenger »

nostrademons wrote: post #306
vanderZwan wrote: post #274

Earlier quoted context omitted.

Aside from the "sample size of one"-issue: how much time did your parents take, and how much effort and preparation time, and how did that compare to the time and effort the professional needed? It could be a trade-off issue there. Also, note that this thread started with a comment about how many developers don't appreciate what the actual hard problems in their own line of work are, and how that produces poor result…

My family painted about half our house ourselves when I was about a pre-teen. My mom just hired a painter to paint her new house. The painter didn't take an appreciably shorter time period than a couple pre-teens did. IIRC, it took us about a week for about 800 square feet worth, and it took the professional 3 weeks for 2400 square feet. And yeah, we did the whole masking-tape, dropcloth, and primer routine as well,…

When you weigh hiring a professional versus DIY, you have to consider the impact of income taxes, not just what you earn/hr versus pay/hr. You have to pay the pro with post-taxed earnings, and then the pro has to pay tax on what you pay them before they can do anything with it. Whereas, if you DIY, you aren't taxed for it. (Also, many people can't just 'work ore hours' to get paid more).

Re: The Death of Microservice Madness in 2018

#398

Post by corpMaverick »

paulddraper wrote: post #5

https://en.wikipedia.org/wiki/Law_of_conservation_of_complex... Broadly speaking, microservices make small, limited changes/update less complex, and large, sweeping changes/updates more complex. This is why generalizations like "larger, established organizations [which make mostly relative small changes] should lean more to microservices than smaller, younger organizations [which make mostly relatively large changes]…

I have been trying unsuccessfully to articulate this. You do have to find the right boundaries(therefore the right size). But the "micro-services" term doesn't help since it implies the size is really small.

Re: The Death of Microservice Madness in 2018

#399

Post by versk »

SOLAR_FIELDS wrote: post #315
brisance wrote: post #212

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'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?

Re: The Death of Microservice Madness in 2018

#400

Post by corpMaverick »

stevenmays wrote: post #4

I posted this a few days ago... I wonder why HN didn't keep the original post. https://news.ycombinator.com/item?id=16159589

... and I tried to see comments on it days ago.

https://news.ycombinator.com/item?id=16149039

It is strange how no one was interested when previously submitted and sudden it attracts a lot of interest.

Post reply on HN