Re:Ask HN: What's your biggest struggle with Microservices?
by JamesBarney on Tuesday July 25, 2017 @03:10PM
(#14850919)
Yeah I could totally see how if you have very strict uptime requirements and you want to allow different pieces of the infrastructure to be able go down at different times then it's an exception to the rule.
Just for every team that I see that has a good use case for micro services, and does the hard work of instrumentation and deployment, I see 8 teams that go with microservices because they think it's a magic bullet. Then they don't spend the time and effort necessary to get instrumentation and orchestration up and running. They don't aggregate logs, they don't spend the time to create defined contracts between the services, they don't make services robust to the failure of other services. They just complicate their debugging, deployment, uptime, and performance scenario without getting any of the benefits.
Re:Ask HN: What's your biggest struggle with Microservices?
by klodolph on Wednesday July 26, 2017 @02:21PM
(#14858740)
In this case, we don't have strict uptime requirements. But there are enough times where our integration tests don't catch some kind of error, and it's nice that the service doesn't have to go completely down for that.
It's also a lot easier to prioritize process scheduling than it is to prioritize thread scheduling.
The number of different services is close to the number of people on the team.
This is working very well for us, and it provides us with some welcome isolation when there are problems with one of the microservices. Maybe we can go into read-only mode or stop processing batch jobs for a while, depending on what services have problems.
But we also have good infrastructure support, which makes this a lot easier.