3 ms·
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 mig
by 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 agoAt 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 agoAnd 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 agoIn 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.