4 ms·

Delivering pre-packaged meals to people requires _hundreds of microservices_. That is truly astounding.

elbear 7y ago
If you turn every function into a microservice, then you can have hundreds of microservices. I still don't see the benefits though.
- TeMPOraL 7y ago
  Given where this is going, couldn't we just skip a couple iterations of the hype cycle, and simply port BEAM runtime to work directly on machine clusters instead of machine code? This way we'll jump straight to one actor = one microservice = one VM.
  - elbear 7y ago
    Isn't that serverless, ie. AWS Lambda?
    - TeMPOraL 7y ago
      You would also need an orchestrating layer on top of it.
larrywright 7y ago
I think it’s a safe assumption that any given problem domain has more complexity than is obvious at first glance.
roytries 7y ago
I work for a large webshop. I was amazed by how many engineers work here. But now, after two years, I understand why we need them. Handling millions of customers, sending millions of parcels, logistics, storage, customer support, etc... requires a lot of systems. It is definitely more complex that you would image at first glance. All of those systems need each other's information. The shop needs to know if a product is available, and what price it is. Customer Service needs to know how it was sent and the tracking code etc,... We've built hundreds of microservices to manage this. This is definitely not something that is easy in a monolith. (We came from a monolithic architecture, we're really happy we're now using microservices). We're now also rolling out Istio on GKE. So who knows, they might be on to something at Hello Fresh.
pianoben 7y ago
It's not entirely unreasonable on its face; physical fulfillment is a complicated business domain. You might have services dealing with suppliers, customers, delivery vendors, regulatory compliance, payments, sales taxes, so on, so forth. You might have ML services to predict product availability or customer demand. Those subdomains might themselves be decomposed into API services, vendor gateways, background workers, etc. This doesn't factor in infra-related things like data stores, caches, etc. Even if you only sipped the microservices kool-aid, I can easily see dozens of services. Granted, it seems reasonable that a handful of monoliths could get the job done. Without having worked at HelloFresh, I'm inclined to think there's more to the story that we don't know. Maybe there's a good reason to have as many services as they do.
- hcnews 7y ago
  I would wager that its because ex-Uber folks work there and carried their ways with them.
  - pianoben 7y ago
    That's rather pointed, but also matches just about every system-design interview I've ever given to an Uber engineer. Next time, I want to ask them how they keep track of all those services! edit: replaced an incorrectly-used idiom
    - jordanbeiber 7y ago
      Tip - use a database. Computers are awesome at automating things, that goes for dev tooling as well. If you’ve touched the ITSM space you’re used to managing and maintaining many thousand of assets. A few hundred microservices is nothing, really. My team use what you could call a simplified CMDB (configuration management database) which is cross referenced against the service discovery. The cmdb keep info about every service, such as persistent data-sources, vm’s etc, but most important - relationships: domain, team, services and resources. A microservice is basically a ”ci” (configuration item) with a managed lifecycle.

If you turn every function into a microservice, then you can have hundreds of microservices. I still don't see the benefits though.

TeMPOraL 7y ago
Given where this is going, couldn't we just skip a couple iterations of the hype cycle, and simply port BEAM runtime to work directly on machine clusters instead of machine code? This way we'll jump straight to one actor = one microservice = one VM.
- elbear 7y ago
  Isn't that serverless, ie. AWS Lambda?
  - TeMPOraL 7y ago
    You would also need an orchestrating layer on top of it.

larrywright 7y ago

I think it’s a safe assumption that any given problem domain has more complexity than is obvious at first glance.

roytries 7y ago

I work for a large webshop. I was amazed by how many engineers work here. But now, after two years, I understand why we need them. Handling millions of customers, sending millions of parcels, logistics, storage, customer support, etc... requires a lot of systems. It is definitely more complex that you would image at first glance. All of those systems need each other's information. The shop needs to know if a product is available, and what price it is. Customer Service needs to know how it was sent and the tracking code etc,... We've built hundreds of microservices to manage this. This is definitely not something that is easy in a monolith. (We came from a monolithic architecture, we're really happy we're now using microservices). We're now also rolling out Istio on GKE. So who knows, they might be on to something at Hello Fresh.

pianoben 7y ago

It's not entirely unreasonable on its face; physical fulfillment is a complicated business domain. You might have services dealing with suppliers, customers, delivery vendors, regulatory compliance, payments, sales taxes, so on, so forth. You might have ML services to predict product availability or customer demand. Those subdomains might themselves be decomposed into API services, vendor gateways, background workers, etc. This doesn't factor in infra-related things like data stores, caches, etc. Even if you only sipped the microservices kool-aid, I can easily see dozens of services. Granted, it seems reasonable that a handful of monoliths could get the job done. Without having worked at HelloFresh, I'm inclined to think there's more to the story that we don't know. Maybe there's a good reason to have as many services as they do.

hcnews 7y ago
I would wager that its because ex-Uber folks work there and carried their ways with them.
- pianoben 7y ago
  That's rather pointed, but also matches just about every system-design interview I've ever given to an Uber engineer. Next time, I want to ask them how they keep track of all those services! edit: replaced an incorrectly-used idiom
  - jordanbeiber 7y ago
    Tip - use a database. Computers are awesome at automating things, that goes for dev tooling as well. If you’ve touched the ITSM space you’re used to managing and maintaining many thousand of assets. A few hundred microservices is nothing, really. My team use what you could call a simplified CMDB (configuration management database) which is cross referenced against the service discovery. The cmdb keep info about every service, such as persistent data-sources, vm’s etc, but most important - relationships: domain, team, services and resources. A microservice is basically a ”ci” (configuration item) with a managed lifecycle.