My team's currently building a proof-of-concept microservicey replacement for a chunk of our company's platform, based on solid understandings of the problems t

My team's currently building a proof-of-concept microservicey replacement for a chunk of our company's platform, based on solid understandings of the problems the existing one has, what it'll need to do in the future etc. The architecture offers some very compelling solutions to these problems. But we based this on evidence, we're testing everything to destruction, we're embracing tooling to help us manage everything (we could not do this without Terraform or something of similar capability)... but actually, our domain maps to microservices extremely neatly. It's probably the first place I've ever worked where that's the case. I like this article, because it draws attention to very real issues and problems with these architectures, and there is an overall danger and enormous risk in using an architecture "because it's good" or "because it's the way of the future" rather than the only correct reason to choose an architecture: because it's the right fit for your problem. Oh also, because our thing is still a proof-of-concept, we may yet throw it all away and build something else. While initial results are promising, we haven't properly proved the concept yet. But what a joy to work somewhere that lets us do this.