91–100 of 233 posts
Earlier quoted context omitted.
I've seen at least one place with many more than that in recent years. If you have one microservice "listener" per queue and another for the database processing and persistence (business logic) and another providing an API for one or more frontend UI's related to it then the microservice tally goes up very fast. It's kind of surprising to read so many comments indicating HN readers weren't aware of this.
sounds like a massive nightmare
Earlier quoted context omitted.
Deployments != unique codebases.
Try but read the full comment chain again to understand the context of our discussion.
Do you mean that your original point was about deployments to begin with?
FWIW I work in a microservices shop for a global app in an extremely regulation heavy industry, and we run a single codebase per service, segregating regulator-imposed behaviour via flags to deployments
Earlier quoted context omitted.
I wonder what setting up a local dev instance is like for anything involving more than one or two of those.
In general in a micro service environment, you try to build things so that 1) you don't need to run other things locally, and 2) if you did need to, the services are just containers so it's pretty easy to run one. But you tend to try to write your service so that it treats everything else it depends on like a vendor-provided API. Like, if you were building a Slack bot, you wouldn't ask Slack to let you pull down and…
I find the opaqueness of other services to reduce development speed quite drastically. With local code I can view both sides of the fence and easily see if I'm using it wrong or if it's a bug in my colleagues code.
Seems that if you're constantly developing against opaque services you'd end up in the same quagmire quite quickly?
Earlier quoted context omitted.
I've worked on a couple of extremely large micro services projects. And the thing is that nobody ever needs to run the entire stack other than end to end tests which get run in the cloud. You just checkout the services you need and because they are designed to be isolated the dependencies will usually be automatically stubbed out. So it's just a matter of running them or chaining them together if you have a particula…
Question for you: how does performance measurement and optimization work in that environment? Is the key some sort of meta tooling that understands relationships between microservices? How would you express such relationships in the first place? Q2: How do you ensure the stubbed deps behave like the real thing? Q3: how do you handle logging and metrics in an unified way across the stack? And related to this: how do y…
SRE here. Generally speaking, each API or each service will have a contract that it must adhere to depending on upstream and downstream relationships and their fail safes. Each service (or API) will then load test in isolation.
After that, if you want to be really sure about regressions (which would include fail safes) you load test the whole thing put together.
> Is the key some sort of meta tooling that understands relationships between microservices?
This is quite hard to do when you have a lot of transactions. I don't think there's commodity software that does this because you'd need to configure that software to map on keys, then map those keys to services. Generally, the easiest way is to get engineering teams to declare upstreams and downstreams.
> Q2: How do you ensure the stubbed deps behave like the real thing?
Generally, generation. Something like protobuf or Open API generation will do.
> Q3: how do you handle logging and metrics in an unified way across the stack?
You issue high level standards like, "We'll use JSON logging with UTC time formatting". At the end of the day logging is very contextual and in a service ownership model the service owners are usually the ones reading and alerting on their logs.
> And related to this: how do you ever get to upgrade services crosscutting concerns that ideally are not invented in every service?
Shared dependencies. I'm not actually sure what's a cross cutting concern; generally services that are this small should be designed to operate mostly independently. They're small, but "microservices" tend to have a lot of fail safes built in. If you're referring to how do we not write 4000 config loaders then there's usually a team that builds a very generic config loader and everyone or a majority use it.
Earlier quoted context omitted.
Yup Pornhub serves much more video than Netflix and they do so without that insane amount of complexity.
Isn't pornhub free, their only monetization being ads? Also does Pornhub have personal recommendations, per country and region libraries, an android, ios and android TV apps? Probably not. That is a much easier business model and a lot lower level of complexity than Netflix. I imagine running pornhub is essentially running a large website that hosts video. Probably just the billing side of Netflix is more complicated…
Does Uber really need 4000 microservices?
Uber is a global company (70+ countries) operating Uber and Uber Eats. So almost certainly they are duplicating their entire stack per-country if only to get around the vastly different regulatory environments.
Earlier quoted context omitted.
Yup Pornhub serves much more video than Netflix and they do so without that insane amount of complexity.
Isn't pornhub free, their only monetization being ads? Also does Pornhub have personal recommendations, per country and region libraries, an android, ios and android TV apps? Probably not. That is a much easier business model and a lot lower level of complexity than Netflix. I imagine running pornhub is essentially running a large website that hosts video. Probably just the billing side of Netflix is more complicated…
Earlier quoted context omitted.
Yup Pornhub serves much more video than Netflix and they do so without that insane amount of complexity.
Honestly Pornhub's stack is genuinely impressive. More start-ups should just use PHP and get shit done
My peak “wtf” moment was when we had a SEV because two services that should communicate actually used different versions of thrift, both hard forked by Uber, with different implementations for sets. Passing a set from one service to another caused everything to break.