> The Vagrant repo itself was called something along the lines of “full-stack in a box”, and the idea, as you might imagine, was that a simple `vagrant up` should enable any engineer in the company (even frontend and mobile developers) to be able to spin up the stack in its entirety on their laptops.
This is honestly not that hard to get working, if you have Docker and good tools. For simple cases, "docker-compose" will work well enough. For complex cases, my employer open-sourced a tool for exactly this: http://cage.faraday.io/ This extends docker-compose with the idea of multiple pods, staging/production environments, etc.
For testing, we have plenty of unit tests, and we've been experimenting with pact https://github.com/pact-foundation/pact-js, which turns microservice consumer mocks into provider contracts.
But at the end of the day, it appears to be absolutely necessary to have end-to-end tests that run in a staging environment whenever a service is updated. Otherwise, something inevitably falls through the cracks. It's a nice idea to think that you can develop each microservice in isolation, but somebody ultimately has to watch site-wide quality.
A variety different factors. More moving parts == more stuff that can break. Knowledge about a specific service becomes less widespread, so issues take longer to resolve. Also, just hardware scaling becomes a problem. It also really sucks to have to have 50 people rebuild dev environments because you bumped a system dep in a container that your app now depends on. At some point, just building and bringing up all those containers becomes really slow, and you're going to have to build more and more systems to aid in that.
There's also all the stuff that's tricky to automate - say you're using AWS Lambdas, step functions, SQS queues. Translating that across different developer envs is a challenging problem.
I'm very much on the monolith-first approach. There are cases for microservices for specific business functions when you have few engineers, but in general it's far more of a scaling layer for engineer count. Single-app workflows are typically much more productive compared to microservice workflows up until a certain point.
This is honestly not that hard to get working, if you have Docker and good tools. For simple cases, "docker-compose" will work well enough. For complex cases, my employer open-sourced a tool for exactly this: http://cage.faraday.io/ This extends docker-compose with the idea of multiple pods, staging/production environments, etc.
For testing, we have plenty of unit tests, and we've been experimenting with pact https://github.com/pact-foundation/pact-js, which turns microservice consumer mocks into provider contracts.
But at the end of the day, it appears to be absolutely necessary to have end-to-end tests that run in a staging environment whenever a service is updated. Otherwise, something inevitably falls through the cracks. It's a nice idea to think that you can develop each microservice in isolation, but somebody ultimately has to watch site-wide quality.