Can you please do an intro that is an ELI5 on Microservices, how/why/when/where they are used etc...
Ask HN: What's your biggest struggle with Microservices?
51–60 of 77 posts
Re: Ask HN: What's your biggest struggle with Microservices?
#52Convincing people that "stateless" really does mean "stateless", and if you hold state, you're going to have a bad day when your service is stopped.
Latency is another big one - the communication latency between any two points is miniscule, but throw together even 4 services, and suddenly the time required to encode, route, transmit, receive, and decode adds up quickly. If you want to keep round trips to under 100ms in your own code, each microservice you add could easily subtract 10ms from that budget.
Re: Ask HN: What's your biggest struggle with Microservices?
#53From my experience, there are several issues that were mostly touched by the other commenters: * auth / authorization: easy to grasp, tough to implement, opens a world of architectural wtfs * service configuration files / variables * understanding that more microservices can run on the same host * system entry point, credential based, jumpbox And the most important issue I keep seeing across the systems I work with i…
Well, I'd like more info...
What was the case-study? Can you link to it?
What has been your best resource to support/inform any of your arch design considerations?
Re: Ask HN: What's your biggest struggle with Microservices?
#54Convincing 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…
One rules of thumb is "one team one service". If you have multiple teams working on a service then it might start making sense to migrate to multiple microservices.
That's a nice rule of thumb but it's radically different from the team I work on. We run half of one logical service (visible to users outside the team), but that logical service is implemented with a dozen or more microservices internally. We have user-facing services which need high priority, different flavors of batch jobs which need to be orchestrated and prioritized, and various other pieces of infrastructure.
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.
Re: Ask HN: What's your biggest struggle with Microservices?
#55Running microservices is like running a city: you need roads, highways, police departments, fire departments, and so on.
Without an abstraction layer and proper planning, different teams will start building microservices with lots of common functionality like security, authentication, logging, transformations that over time will increase the complexity and the fragmentation of the entire system. Ideally you would want services to simply receive a network request, serve a response, and delegate all the complimentary middleware execution somewhere else, like an API gateway.
Traditionally API gateways in a pre-container world were centralized in front of an API, but modern API gateways can also run in a decentralized way alongside your server process, to reduce latency.
Then once you have everything in place, you end up with a bunch of microservices that your developers (maybe belonging to different departments) will have to use. You will need to fix discoverability, documentation and on-boarding. Some of these services may be also opened up to partners, so there's that too. Traditionally developer portals were only being used for external developers, but they are becoming a requirement for internal teams as well.
Finally, you need to carefully monitor and scale your services. Without a proper analytics and monitoring solution in place it will be impossible to detect anomalies, scale horizontally each service independently, and having an idea of the state of your infrastructure.
Generally speaking running microservices can be split in two parts:
1. Building the actual microservice.
2. Centralizing common functionality, documentation/on-boarding and analytics/monitoring.
Most of the developers or project managers I regularly speak to tend to forget the second part.
Disclaimer: I am a core committer at Kong[1]
Re: Ask HN: What's your biggest struggle with Microservices?
#56Our 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 co…
Overall a net gain, but it made you leave? That definitely does not sound like an overall net gain.
It was a net gain for them..
They were doing even worse before. They upgraded to a CD style pipeline to AWS instead of monolithic java apps. It was better but nobody realized there were deep and very wrong tech debt. The complacency around this was a big factor in causing me to seek new challenges.
The biggest pain points were always not the OSS stuff that was adopted, it was all the “NIH” innovations that were developed because the OSS stuff wasn’t quite right, stuff that “worked” but had no support or allowances for improvement.
Re: Ask HN: What's your biggest struggle with Microservices?
#57Our 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 co…
Overall a net gain, but it made you leave? That definitely does not sound like an overall net gain.
[deleted]
Re: Ask HN: What's your biggest struggle with Microservices?
#58Running microservices is like running a city: you need roads, highways, police departments, fire departments, and so on. Without an abstraction layer and proper planning, different teams will start building microservices with lots of common functionality like security, authentication, logging, transformations that over time will increase the complexity and the fragmentation of the entire system. Ideally you would wan…
Kong is an amazing piece of microservice architecture. I've been very happy with how it behaves.
Re: Ask HN: What's your biggest struggle with Microservices?
#59Running microservices is like running a city: you need roads, highways, police departments, fire departments, and so on. Without an abstraction layer and proper planning, different teams will start building microservices with lots of common functionality like security, authentication, logging, transformations that over time will increase the complexity and the fragmentation of the entire system. Ideally you would wan…
This. I really like the analogy that of running a city. There are just so many concerns in and around building and running microservice architectured systems: security, logging/analytics, failure modes/recovery/detection/self-healing, message protocol versioning, data persistence, capacity scaling and many more. Much of these are easy to defer/overlook early in dev't stage but will later become very hard, if not impossible to incorporate in.
Btw, we thank you and your team as we are Kong users as well. :)
Re: Ask HN: What's your biggest struggle with Microservices?
#60From my experience, there are several issues that were mostly touched by the other commenters: * auth / authorization: easy to grasp, tough to implement, opens a world of architectural wtfs * service configuration files / variables * understanding that more microservices can run on the same host * system entry point, credential based, jumpbox And the most important issue I keep seeing across the systems I work with i…
Well, I'd like more info... What was the case-study? Can you link to it? What has been your best resource to support/inform any of your arch design considerations?
Sure, the case study would be this https://aws.amazon.com/solutions/case-studies/rozetta-techno...
For architecture debates ( yes there were some :) ) the resources used would vary depending on the level of the issue at hand.
For inter-service communication we had a standardized API interface that would need to be exposed and most of the discussions would circle around how does the service solve a problem and what API does it expose to the outside world.
For general system workflow issues we would resort to diagrams or good old fashioned whiteboarding whose artifacts would also get converted into diagrams.
A general rule-of-thumb that I pushed was that every single service would be documented starting with the design process and ending with support info.
Hope that makes any sense :)