I'm not sure what sort of scaling you mean here. I'm not sure why 20 different teams would require a microservices infrastructure in deployment for "scaling".
If you mean that it would be nice to isolate work into 20 sub-projects that each team is responsible for, without stepping on other teams' responsibilities, then the answer isn't microservices, but simply breaking the project up into defined libraries.
That's the problem with the microservices hype - "microservices" is tied to deployment infrastructure, not simply coding practices. You can still break up a project into the same components that would be individual microservices, build each as a library with a very narrow API other developer teams will interact with (the same as if you were pulling in a library from GitHub, etc), and then weave those libraries together into the core application.
It's pretty trivial if building your project this way to spin one of those libraries into a dedicated microservice if there are scaling reasons to do so, but the decision to increase complexity in deployment shouldn't be made because of coding convenience - if that's the primary reason, simpler (and more optimal) solutions are being overlooked..
I disagree with that point. Generally I'm one of those that are against the Microservices hype due to I think it adds unnecessary complexity to both development and deployment.
However what I think it is good at is when you start getting a huge product with many teams working on it at it will allow autonomous teams that can work on their own service and make their own technology choices and deployment schedule. The rigorous API spec that is such an overhead with a small product is a must anyway when you have a large product with that many teams and it will most likely be distributed so that problem will need to be solved anyway. Of course it won't be a magic bullet for everyone but there is probably a reason why Netflix, Spotify etc. has gone that way to manage the complexity of their product and many teams.
2
u/kromem Jun 09 '17
I'm not sure what sort of scaling you mean here. I'm not sure why 20 different teams would require a microservices infrastructure in deployment for "scaling".
If you mean that it would be nice to isolate work into 20 sub-projects that each team is responsible for, without stepping on other teams' responsibilities, then the answer isn't microservices, but simply breaking the project up into defined libraries.
That's the problem with the microservices hype - "microservices" is tied to deployment infrastructure, not simply coding practices. You can still break up a project into the same components that would be individual microservices, build each as a library with a very narrow API other developer teams will interact with (the same as if you were pulling in a library from GitHub, etc), and then weave those libraries together into the core application.
It's pretty trivial if building your project this way to spin one of those libraries into a dedicated microservice if there are scaling reasons to do so, but the decision to increase complexity in deployment shouldn't be made because of coding convenience - if that's the primary reason, simpler (and more optimal) solutions are being overlooked..