| "polyglot microservice architectures" eh? Hey Bill! We've got 20 years of legacy code that handles everything from Arrivals Boards to seat assignments in 1627 different aircraft configurations. We got a room full of .NET devs downstairs. How about we re-write everything in multiple languages! Remember that time we went down for two days because we muffed up our NET 2.0 to 4.0 migration? Imagine how much fun we'll have when we're doing it with Python, Ruby, Rust, Swift, Javascript and Go! We'll break out the seat assignments in Go. Do the signboards in Python. Web app for refunds in Ruby. I don't know what Rust is but one of the guys downstairs has a book on it with a woodcut of a beaver on the front. Think of all the time we'll save! Plus our consultant says it's so much easier to spin up Linux VMs! "Bill, it's the same damn button to spin up a Linux server anywhere. Even on Azure. You just check the Penguin instead of the four squares first. And our deploy scripts work just fine. Even our stupidest apps from the 1990s are one binary file and one text file now. And nobody but Tim is allowed to change the text file." |
- Almost every developer was converted to .NET to work there, because Microsoft's credibility among startup-focused developers is not great outside of a few specific tools like SQL Server. It's a lot easier to get enough hands to get the job done when you let them use Node (which, I'll be honest, I don't even really like, I'd personally rather write C# but I don't write application code here so it doesn't matter) instead of making them write C#.
- The legacy stuff isn't being rewritten. It's going to be ported to Linux, using Microsoft's own CoreCLR. Parts will be broken out into their own services in order to directly scale them and make it easier to provide separation of concerns; whether it gets rewritten or just parted out is an engineering decision, but so far they seem content to part out legacy code instead of rewrite.
- I'm a DevOps guy. I automate. And you can automate a lot more, to go a lot faster, in a Linux environment. Chef's made strides in Windows, and that's honestly and truly cool, but it's only a first step. There's a reason that most devops folks I know have settled on disposable architectures, where a config change means that the machine should be canned: it reduces ambiguity by removing convergence in favor of guaranteed state. This is extremely difficult in Windows because of the amount of drag induced by the tooling. It takes literally-literally twice as long to bake a Windows Vagrant box as it does a Linux one--I've timed it. It takes longer to build a Windows AMI. It takes longer to deploy one, making your auto-scaling groups less responsive.
-This company's load patterns are unpredictable enough and spiky enough that there is an actual, no-bullshit need for scaling on the order of seconds, not 5-10 minutes, and you literally can't do that in AWS with Windows (and I don't think you can with Azure, either); containerization technology (ECS, Mesos, whatever) is making it very practical to meet these sorts of response requirements.
- Languages must be approved; right now it's just Node and Mono (soon to be CoreCLR), but the build environments (both through Chef and, later, through Docker) support multiple languages. To use something else, one will have to make their case. But instead of assuming a certain level of professional rigor, you started frothing and assuming everything would be written in whatever struck somebody's fancy.
Seriously: fanboy harder. It's clearly working.