3 ms·

> If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture. Such a strong statement. Might a lack

by lijok 3y ago

> If your developer count is in the 10s, you are committing professional negligence chasing a microservices architecture. Such a strong statement. Might a lack of industry experience be driving such strong convictions of yours? Here are some reasons, off the top of my head, why a company would want to embrace microservice architecture, with all its benefits and complexities, with a developer count in the 10s: 1. You're building a product that touches multiple deep domains and the business has modelled a very aggressive headcount growth 2. You've outsourced a large portion of your development to a number of agencies 3. You have a team of individuals who know nothing but microservices 4. Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business 5. You're building anything to do with image processing at scale 6. You are a subsidiary owned by a parent company with tons of experience and tooling for microservices 7. One of your VCs has offered up a dev team they own to speedboat your MVP, who specialize in microservices 8. You've received a buyout offer by a party interested in specific IP within your product, with the condition that the IP is isolated from other parts of the system

rkwz 3y ago
> Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business Just curious, how does microservices help here?
- lijok 3y ago
  Great question. Two things you're aiming for with a regulatory submission: 1) Get it approved. 2) Receive back as few rounds of questions as possible from the case officer, as each round delays approval. You can improve 2) by painting a very clear and concise narrative around key concerns pertaining to the particular application you're submitting. Microservice architecture helps to paint that narrative (for CCOs that understand them) as at the high level, it addresses the key concerns (primarily data protection) with simple to convey concepts such as data segregation, service ownership, etc. The implementation of those controls is not as simple, but for the regulatory application, all that matters is that they are sound in practice and simple to convey.
mrits 3y ago
You don't need microservices to address any of that. I would argue that microservices make it harder for different outsourced teams to work together. I tend to agree with OP in that microservices really slow down a smaller team and more aligned with helping giant teams function.
RansomStark 3y ago
1. You're building a product that touches multiple deep domains and the business has modelled a very aggressive headcount growth That feels like premature optimization; split when you need to and not before 2. You've outsourced a large portion of your development to a number of agencies Then your developer count is likely not in the 10s (you need to could the agency developers), plus if you've already outsourced your development in that manner, it suggests you already chose a micro-services architecture and tendered accordingly, this feels like a post hoc justification. 3. You have a team of individuals who know nothing but microservices If a team can build a set of microservices, they can build a monolith, the skill sets are not that different, a microservice is after all just a really small monolith. 4. Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business That's an interesting one, you're trading technical complexity for compliance, and it may well be a use case, there is not enough data to comment here. But there are many ways to be compliant with <insert framework here>, micro-services might be one, but is it the optimal solution for all involved, well that depends... 5. You're building anything to do with image processing at scale This doesn't require micro-services, it probably requires horizontal scalability, if its offline processing you might want a batch process you can turn on and off as required, but that doesn't have to mean microservices, at this point it becomes a semantic argument of what constitutes a microservice, but I would argue the idea of batch processes predates the idea of microservices. Also just because you might need to use microservices in a small part of your application stack, the rest of the solution can still be a monolith: a hybrid architecture if you will. 6. You are a subsidiary owned by a parent company with tons of experience and tooling for microservices Again, if you have tons of experience with microservices that can be easily translated to monoliths, just build a microservice but bigger 7. One of your VCs has offered up a dev team they own to speedboat your MVP, who specialize in microservices It its 10 devs or less, does it matter, build a monolith and optimize when it makes sense to do so 8. You've received a buyout offer by a party interested in specific IP within your product, with the condition that the IP is isolated from other parts of the system Unless that is your goal from day 0, I'm not sure how you could anticipate this, again this feels like a post hoc justification. If, in the unlikely event that that situation occurs, that might be a good time to consider splitting out that functionality.

by lijok 3y ago

rkwz 3y ago

> Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business Just curious, how does microservices help here?

lijok 3y ago
Great question. Two things you're aiming for with a regulatory submission: 1) Get it approved. 2) Receive back as few rounds of questions as possible from the case officer, as each round delays approval. You can improve 2) by painting a very clear and concise narrative around key concerns pertaining to the particular application you're submitting. Microservice architecture helps to paint that narrative (for CCOs that understand them) as at the high level, it addresses the key concerns (primarily data protection) with simple to convey concepts such as data segregation, service ownership, etc. The implementation of those controls is not as simple, but for the regulatory application, all that matters is that they are sound in practice and simple to convey.

mrits 3y ago

You don't need microservices to address any of that. I would argue that microservices make it harder for different outsourced teams to work together. I tend to agree with OP in that microservices really slow down a smaller team and more aligned with helping giant teams function.

RansomStark 3y ago

1. You're building a product that touches multiple deep domains and the business has modelled a very aggressive headcount growth That feels like premature optimization; split when you need to and not before 2. You've outsourced a large portion of your development to a number of agencies Then your developer count is likely not in the 10s (you need to could the agency developers), plus if you've already outsourced your development in that manner, it suggests you already chose a micro-services architecture and tendered accordingly, this feels like a post hoc justification. 3. You have a team of individuals who know nothing but microservices If a team can build a set of microservices, they can build a monolith, the skill sets are not that different, a microservice is after all just a really small monolith. 4. Your chief compliance officer is intimately familiar with the data protection benefits that microservices bring and is leaning heavily into it in their regulatory submissions as a way to compensate for some other gap in the business That's an interesting one, you're trading technical complexity for compliance, and it may well be a use case, there is not enough data to comment here. But there are many ways to be compliant with <insert framework here>, micro-services might be one, but is it the optimal solution for all involved, well that depends... 5. You're building anything to do with image processing at scale This doesn't require micro-services, it probably requires horizontal scalability, if its offline processing you might want a batch process you can turn on and off as required, but that doesn't have to mean microservices, at this point it becomes a semantic argument of what constitutes a microservice, but I would argue the idea of batch processes predates the idea of microservices. Also just because you might need to use microservices in a small part of your application stack, the rest of the solution can still be a monolith: a hybrid architecture if you will. 6. You are a subsidiary owned by a parent company with tons of experience and tooling for microservices Again, if you have tons of experience with microservices that can be easily translated to monoliths, just build a microservice but bigger 7. One of your VCs has offered up a dev team they own to speedboat your MVP, who specialize in microservices It its 10 devs or less, does it matter, build a monolith and optimize when it makes sense to do so 8. You've received a buyout offer by a party interested in specific IP within your product, with the condition that the IP is isolated from other parts of the system Unless that is your goal from day 0, I'm not sure how you could anticipate this, again this feels like a post hoc justification. If, in the unlikely event that that situation occurs, that might be a good time to consider splitting out that functionality.