Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What's your biggest struggle with Microservices?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Ask HN: What's your biggest struggle with Microservices?

#11

Post by BjoernKW »

Convincing people that microservices are not a cure-all but just another design pattern.

You have to start out with a monolith and only if you realise along the way that some components might work better as a service (micro or not) you should extract those. Until then, commonplace modularisation will serve you just fine.

Once you have more than 1 microservice running infrastructure becomes a huge problem. There's no real turnkey solution for deploying and running internal / on-premises microservices yet. You basically have to build monitoring, orchestration and logging infrastructure yourself.

Re: Ask HN: What's your biggest struggle with Microservices?

#13

Post by avenoir »

We started with a monolith which made determining service boundaries that much easier. What we struggled with the most is the concept of sharing data between services. We started off with publish/subscribe method which quickly became very strenuous to maintain. Ended up switching to plain service-to-service communication over HTTP/S. This allowed us to focus on resiliency and performance of each micro-service more so than before. And so far it's been paying off great. Other things like having an overall view of the health of the entire system and having a way to consume and analyze logs in one place is absolutely detrimental to success in this type of architecture.

Re: Ask HN: What's your biggest struggle with Microservices?

#14

Post by pwm »

Testing and debugging inter-service concerns. These, in my opinion, are inherently difficult to do when working with this architecture. In other words a lot of ugly real-world complexity hides in the space between the neatly maintained gardens that is the inside of a single service giving a somewhat false view that the problem has been successfully chopped up into small, compose and manageable pieces.

Re: Ask HN: What's your biggest struggle with Microservices?

#15

Post by kenoyer130 »

avenoir wrote: post #13

We started with a monolith which made determining service boundaries that much easier. What we struggled with the most is the concept of sharing data between services. We started off with publish/subscribe method which quickly became very strenuous to maintain. Ended up switching to plain service-to-service communication over HTTP/S. This allowed us to focus on resiliency and performance of each micro-service more so…

detrimental?

Re: Ask HN: What's your biggest struggle with Microservices?

#16

Post by dionian »

Our org made all the right decisions at the top, invented their own microservice fabric stuff with way too much tech debt, end result was a very bad (inefficient and painful) development experience with way more technical debt than the monolith we replaced.

There was so much fragmentation between each autonomous team that we were forced to standardize on a common framework (think of build/integration pipelines and common modules) which could almost never be changed or refactored.

The upside was that there was way more automated testing and flexibility in deployment, so overall it was a net gain.

Still, the actual ergonomics of working with the build/release system was so painful it made me leave to work somewhere where I could do actual innovation.

There was so much waste that was already 'baked into the system' and the other teams finished their work so if you had struggles with it it was your problem

Re: Ask HN: What's your biggest struggle with Microservices?

#20

Post by eludwig »

kenoyer130 wrote: post #15
avenoir wrote: post #13

We started with a monolith which made determining service boundaries that much easier. What we struggled with the most is the concept of sharing data between services. We started off with publish/subscribe method which quickly became very strenuous to maintain. Ended up switching to plain service-to-service communication over HTTP/S. This allowed us to focus on resiliency and performance of each micro-service more so…

detrimental?

instrumental?
Post reply on HN