In enterprise you might end up with different gate keepers, each maintaining a differe service... getting changed or added is impossible
Ask HN: What's your biggest struggle with Microservices?
21–30 of 77 posts
Re: Ask HN: What's your biggest struggle with Microservices?
#22Just some topics, can elaborate on those later, if you want:
- Development Setup (e.g. minikube)
- Circuit Breakers
- Managing Backpressure
- Service Discovery
- Encryption
- Monitoring / Metrics
- Domain Translation
- Load balancing / Fail over / retry
Re: Ask HN: What's your biggest struggle with Microservices?
#23Convincing 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…
We should upvote this to the top, it's a pretty good summary of the whole situation.
Re: Ask HN: What's your biggest struggle with Microservices?
#24Micro-services must be under the same mantra as bomb defusers:
1- You first mistake is wanna to (be a bomb defuser) use micro-services.
Don't
2- You second mistake is (getting close to the bomb) start building a micro-service infrastructure.
Not.
3- You third and worst mistake is believe (you can defuse the bomb safely) you can build a microservice solution correctly.
The only reason to (be a bomb-defuser) use microservices is (you are part of the police or army and somebody must do this) you ALREADY HAVE SOLVED THE MAIN THINGS FOR YOUR APP and now are in the hostile territory where micro-service truly make sense. You are facebook-alike.
Re: Ask HN: What's your biggest struggle with Microservices?
#25Convincing 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…
I agree with you that these things should probably start with monoliths and then migrate to microservices.
I'm lucky that the project that I'm working on has support to use JHipster (https://jhipster.github.io/) with microservices deployed to OpenShift (https://www.openshift.com/). I used MiniShift to test my deployments, metrics, monitoring, orchestration, and logging locally. This was mostly for a proof-of-concept.
Re: Ask HN: What's your biggest struggle with Microservices?
#26Testing 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.
This is interesting. Can you provide an example - where it wouldn't have made sense to collapse two such interacting services into one? My understanding is that an important litmus test for carving up microservice boundaries is ensuring 'true' isolation/separation of concerns. Admittedly, I don't have enough practical experience to know if this is a misguided assumption.
Re: Ask HN: What's your biggest struggle with Microservices?
#27I'm privately skeptical about starting with microservices-first for new application development. I have seen a lot of literature about starting off with a monolith and then breaking that down as you see fit. This makes more sense to me than introducing a ton of complexity up front.
Or is it better to deal with that complexity up front and then adding new services/functionality will be easy as time goes on?
Re: Ask HN: What's your biggest struggle with Microservices?
#28Micro-services must be under the same mantra as bomb defusers: 1- You first mistake is wanna to (be a bomb defuser) use micro-services. Don't 2- You second mistake is (getting close to the bomb) start building a micro-service infrastructure. Not. 3- You third and worst mistake is believe (you can defuse the bomb safely) you can build a microservice solution correctly. The only reason to (be a bomb-defuser) use micros…
Totally agreed. Few months ago we started building micro-services infrastructure. We were waiting with that for a bunch of years until things started to get harder and harder to maintain within one app. This is really costly at the beginning if you want to do that correctly.
Re: Ask HN: What's your biggest struggle with Microservices?
#29One of my biggest hurdles was trying to figure out if microservices were right for us (a small distributed team) and then communicating/selling the benefit of them to my team and bosses. This involved creating a mutually agreed upon definition of what we actually meant by "microservices". I literally repurposed paragraphs out of Sam Newman's book to do this. As a small team, I also didn't have examples to support my…
What did you end up deciding? And what were you thinking the benefit might be?
My sense is that for a small team a microservices architecture might be more trouble than it's worth, but I can definitely see how some kinds of applications - or even kinds of teams - it could be a good fit.
Re: Ask HN: What's your biggest struggle with Microservices?
#30The biggest struggle is dealing with the dependency chain when you need to update multiple microservices in order to deliver a major new feature to customers. You have to get everyone to agree on changes to the service APIs, then change the lower level services, deploy them, then move up a level and repeat. This is especially problematic if different developers are responsible for each service; lots of opportunities for delay and misunderstandings. It seems counterintuitive, but if you need to move quickly then a single monolithic application can actually allow for more rapid changes.