4 ms·

I often read about (Silicon Valley) companies saying things like "we have a thousand microservices" or "we have hundreds of microservices" and I really can't wr

I often read about (Silicon Valley) companies saying things like "we have a thousand microservices" or "we have hundreds of microservices" and I really can't wrap my head around what all of these services do. As someone who has primarily worked on monoliths, service-oriented architecture seems like an intelligent idea to me, particularly with regard to scaleability. However, I can't see getting so fine-grained that you have that many services, especially considering that from what I've read each microservice should be backed by it's own datastore. Perhaps its just my own lack of first-hand experience showing, but it seems like it would eventually devolve into a confusing, fragmented, and non-performant mess.

jfz 8y ago
I have seen companies saying they have a thousand microservices to mean that they have a thousand microservice servers running, but they might have hundreds of application servers in each service pulling from the same queue.
DasIch 8y ago
What you need to keep in mind is that micro services have a huge fixed cost but the marginal cost of adding a new one is small. In other words: Creating or migrating to a micro service architecture is very expensive but once it’s in place, adding a new micro service is trivial. In Zalando the goal is that you can do so within half an hour, that is take an idea, implement it and deploy it to production. This leads to architectural decisions no sane person would make at a smaller company. For example let’s say you get data from an external company via SFTP and you make it internally available, so what do you do? 1. You create a micro service that polls the SFTP of the supplier for new files and sticks them into an S3 bucket 2. You create a micro service that takes the files from S3, parses, transforms into JSON and publishes events to Kafka. 3. You create a micro service that takes those events enriches them with some other data and republishes new events. ... Especially when you use Kubernetes, you also start thinking about infrastructure completely differently. Why use multiple threads or processes for example, when you can just run multiple instances of your application very cheaply and temporarily run further instances to handle background tasks?
- edejong 8y ago
  At Simacan (also a Dutch company) we have exactly the same architecture. All of the deployment code is duplicated, leaving only the business logic to fill in. Fast, easy, simple to understand and scale.
- batiste 8y ago
  And after 1 year running like this you have 50 micro-services by engineer. All of them undocumented, poorly named with unclear responsibilities using the bus to communicate with god knows who... I might be old fashioned by I would take a monolith over this over-engineered mess any day of the week.
  - DasIch 8y ago
    In Zalando, every PR made must be reviewed by at least one other engineer. Every application must be registered which involves giving it name, a description and associates it with the team owning the service. APIs that cross team boundaries must further be reviewed by an API guild, a group of people that are experts in API design, this also applies to events. Events go through Nakadi, which enforces a schema and authorization. You can further tell which services are subscribing to such events and through the before mentioned application registry who is responsible for them. Additionally compliance with various laws and shareholder expectations requires regular reviews, to identify and fix issues such as missing documentation, monitoring, SLOs, data storage restoration tests (in production), load tests etc. The scenario you describe is not possible or allowed. As awareness and adherence to these rules is also part of performance reviews, it’s also not in any engineers in interest to do that. You’re right of course that one needs to be aware of that.

jfz 8y ago

I have seen companies saying they have a thousand microservices to mean that they have a thousand microservice servers running, but they might have hundreds of application servers in each service pulling from the same queue.

DasIch 8y ago

What you need to keep in mind is that micro services have a huge fixed cost but the marginal cost of adding a new one is small. In other words: Creating or migrating to a micro service architecture is very expensive but once it’s in place, adding a new micro service is trivial. In Zalando the goal is that you can do so within half an hour, that is take an idea, implement it and deploy it to production. This leads to architectural decisions no sane person would make at a smaller company. For example let’s say you get data from an external company via SFTP and you make it internally available, so what do you do? 1. You create a micro service that polls the SFTP of the supplier for new files and sticks them into an S3 bucket 2. You create a micro service that takes the files from S3, parses, transforms into JSON and publishes events to Kafka. 3. You create a micro service that takes those events enriches them with some other data and republishes new events. ... Especially when you use Kubernetes, you also start thinking about infrastructure completely differently. Why use multiple threads or processes for example, when you can just run multiple instances of your application very cheaply and temporarily run further instances to handle background tasks?

edejong 8y ago
At Simacan (also a Dutch company) we have exactly the same architecture. All of the deployment code is duplicated, leaving only the business logic to fill in. Fast, easy, simple to understand and scale.
batiste 8y ago
And after 1 year running like this you have 50 micro-services by engineer. All of them undocumented, poorly named with unclear responsibilities using the bus to communicate with god knows who... I might be old fashioned by I would take a monolith over this over-engineered mess any day of the week.
- DasIch 8y ago
  In Zalando, every PR made must be reviewed by at least one other engineer. Every application must be registered which involves giving it name, a description and associates it with the team owning the service. APIs that cross team boundaries must further be reviewed by an API guild, a group of people that are experts in API design, this also applies to events. Events go through Nakadi, which enforces a schema and authorization. You can further tell which services are subscribing to such events and through the before mentioned application registry who is responsible for them. Additionally compliance with various laws and shareholder expectations requires regular reviews, to identify and fix issues such as missing documentation, monitoring, SLOs, data storage restoration tests (in production), load tests etc. The scenario you describe is not possible or allowed. As awareness and adherence to these rules is also part of performance reviews, it’s also not in any engineers in interest to do that. You’re right of course that one needs to be aware of that.