The Death of Microservice Madness in 2018 • Hacker News Board

Re: The Death of Microservice Madness in 2018

#351

Post by chillidoor » Mon, Jan 22, 2018, 1:31 PM UTC

bonesss wrote: post #327

chillidoor wrote: post #295

Earlier quoted context omitted.

While I'm not arguing with you, I have had a different experience working with developers and microservices, perhaps because the teams have been more seasoned/experienced and there is more of a collaborative environment. I found that a lot of the time developers start moving towards microservices when they find that a monolithic app becomes too difficult to work on. For example, multiple teams working on the same cod…

I think that kind of process, slow decomposition based on performance and requirements, is the only sane approach. It's also reflected in how we manage code at the micro-level: collecting related logic into a module until it becomes unwieldy and then separating out independent sub-functionality into their own modules and dependencies as they grow... There is no right size for a class. Smaller is better, but the ideal…

Yep, there is no real "one size fits all" to microservices

Re: The Death of Microservice Madness in 2018

#352

Post by bambataa » Mon, Jan 22, 2018, 1:33 PM UTC

mettamage wrote: post #153

sooheon wrote: post #143

Earlier quoted context omitted.

IOW, good, clean function composition.

While this is a simplification, I often catch myself thinking: isn't programming creating functions and functions of functions and that all way down? And on each layer we call them differently because of the context we're in. Input --> Stuff happens --> Output Again, it's a simplification, although to be fair, I sometimes don't see how -- other than that I'm feeling that I'm ignoring context too much (e.g. underlying…

And not just programming - all of computing really. Logic gates are composed into more complex ones that are composed into even more complex ones and so on upwards.

Re: The Death of Microservice Madness in 2018

#353

Post by dwmkerr » Mon, Jan 22, 2018, 1:34 PM UTC

gfiorav wrote: post #55

Nice article but I'd point out two things: 1. 'Death' is a bit too extreme. I think everybody is excited at first and tries to find an excuse to use microservices. We're assisting to a decline in that initial push, that's all. 2. I think the point about transactions is fair, as well as the expertise and team concerns, but the rest are mostly "it's too hard and complex". It'll get better with time. I think that being…

Thanks gfiorav for the comments!

1. I think here I was going for 'death' more in terms of the end of the hype, rather than the approach! 2. Agreed. As people get more familiar with the patterns, tools and code and so on it does get easier. The point is more that it can be a hell of a journey :)

Re: The Death of Microservice Madness in 2018

#354

Post by SOLAR_FIELDS » Mon, Jan 22, 2018, 1:36 PM UTC

crdoconnor wrote: post #341

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…

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.

Re: The Death of Microservice Madness in 2018

#355

Post by dwmkerr » Mon, Jan 22, 2018, 1:37 PM UTC

adambyrtek wrote: post #82

Great article, but I'd like to dispute one point: > A new version of the subscriptions service may store data in the subscriptions database in a different shape. If you are running both services in parallel, you are running the system with two schemas at once. Microservices should manage their own separate data stores and communicate with others through a well-defined API. Only then services can evolve independently,…

Hi Adam,

Thanks for the point! In this case I meant more the situation that the same service (single service, single DB) might be running with more than one version concurrently (during a rolling deployment, or a canary deployment etc) which can lead to issues. The other case is that if services depend on an old contract there could be times where teams might run multiple versions of a service to allow different APIs to be used, rather than a single version of the service which exposes all current compatible APIs. Although to be honest, this is an issue with any service.

Re: The Death of Microservice Madness in 2018

#356

Post by dwmkerr » Mon, Jan 22, 2018, 1:39 PM UTC

joneholland wrote: post #2

I took his guide at the end and apparently we are supposed to do micro services, which is good, because we do as an engineering org of 800+ people.

I've been working on a number of microservice projects and have found them to at times be wonderful, at times frustrating. All in all I think it's just a case of YMMV, that with or without can be fine, as long as the decision making is sane :)

Re: The Death of Microservice Madness in 2018

#357

Post by linkmotif » Mon, Jan 22, 2018, 1:48 PM UTC

People talk about building monoliths like it’s some simpler alternative. On the JVM it’s not.

When I first started with Java one of the coolest things was that I could embed anything. I could embed Elasticsearch in my web service. Wow! Forget services calling each other! I’ll prototype real quick with everything in one JVM!

But that proved impossible! :( It turned out that until Java 9, the JVM has a single namespace for all loaded classes. For me this was the greatest driving force for building out smaller services. You had to be very careful about dependencies and couldn’t just include Elasticsearch—or even much of anything—in your web service even if you wanted to. You’d be in immediate unresolvable dependency hell. I can imagine the insane artifacts people produce when they try to build monoliths on the JVM. Even with JavaScript now you have one huge flat dependency namespace. Good luck building a monolith.

I can only conclude that the all the people on this thread who are painting “monoliths” as some easy alternative developers are ignoring due to some inexplicable desire to make things complicated have no idea what they’re talking about.

Re: The Death of Microservice Madness in 2018

#358

Post by bpicolo » Mon, Jan 22, 2018, 1:59 PM UTC

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…

> Better scheduling. A service made of microservices is easier to schedule using bin packing. Low priority components can be deprioritized by the scheduler very easily. This is important for services with large resource footprints.

That's harder scheduling, not easier. With a monolith you just give it all the resources and threads will use resources as is necessary. After that it's a matter of load balancing appropriately.

Re: The Death of Microservice Madness in 2018

#359

Post by manigandham » Mon, Jan 22, 2018, 2:00 PM UTC

lulmerchant wrote: post #265

manigandham wrote: post #249

There is no such thing as "microservices", it's just services, otherwise known as a service-oriented architecture (SOA). A service is a logical grouping of functionality as it makes sense in your business domain. A small service for a large company can be bigger than the entire product of a startup; there is no standard unit of measure. Computers also don't care how code is deployed and different services can be boun…

"microservice" is certainly a buzzword, but it's not just service-oriented architecture. Mircoservice architecture is modular design, with all the advantages of effectively infinite scale, incredibly flexible orchestration, and the resilience provided by the public cloud providers. It has it's own set of challenges, and it isn't the right solution for every problem. But it can be fantastic when used properly. I've wr…

All software is modular, whether those modules are individual functions or separate processes called over the network. Like I said, the computer doesn't care so it's really up to the dev team and organization to divide functionality as they see fit.

There's no inherent "infinite scale" that magically shows up; proper architecture and design does that. "Microservices" again just goes back to being a rather badly defined description of a certain way of deployment. Every time I've seen these used (in smaller companies), there's no benefit over just having separate assemblies talking in the same process instead.

Re: The Death of Microservice Madness in 2018

#360

Post by ataturk » Mon, Jan 22, 2018, 2:00 PM UTC

nemothekid wrote: post #33

dvt wrote: post #15

Biggest issue with microservices: "Microservices can be monoliths in disguise" -- I'd omit the can and say 99% of the time are . It's not a microservice if you have API dependencies. It's (probably) not a microservice if you access a global data store. A microservice should generally not have side effects. Microservices are supposed to be great not just because of the ease of deployment, but it's also supposed to mak…

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…

Microservices without using something like Spring cloud which offers service discovery, reverse-proxying, centralized configuration, etc. is not worth it. I only learned this the hard way myself--my previous role had what you described above and while it kinda sorta worked, I was of the opinion that microservices weren't working (they were using NetKernel for a lot of their services, too, kind of a weird, mixed environment spanning multiple generations of service architectures).

At my current job, I learned what I didn't know! This place has a decent microservice infrastructure without all the lumps using Netflix's OSS suite.

The only major drawback we're having now is that as we drive harder to move services into real cloud deployments, we are finding out that Kubernetes would be a huge help and that it conflicts with our existing service discovery and so we may have to re-architect some of it. The good news is that doing so isn't impossible, it just takes planning and effort.

One thing I find very annoying here is that the developer setup doesn't really look like QA or PROD and that our use of Docker is in its infancy and that the developers can't agree on a lot of things. As an aside, several people won't let go of Eclipse.

Overall, NetKernel was total hell for developers, total hell, and migrating off of it cost millions, but was ultimately successful. NetKernel was the only game in town for REST services at one time, however. That company had an architect who was a NetKernel fanboi and who pushed them in a bad direction years after they should have been migrating to something else--that was another HUGE lesson for me--that personality and political clout had far more to do with their decision making than anything else. The guy bullied people because he didn't want to move off of what he knew. Once he finally left the company, the deluge started and within one year, NetKernel was dead.