4 ms·

You're not wrong. People who don't work in "enterprise" or even in small/medium business IT shops will never know it though. However, I think the downvotes are

You're not wrong. People who don't work in "enterprise" or even in small/medium business IT shops will never know it though. However, I think the downvotes are probably a reaction to the hint of attitude which suggests that you're not overzealous about OSS.

eropple 11y ago
I wonder why, then, the enterprise-by-any-reasonable-standard place I'm currently consulting is moving away from .NET and Windows to a polyglot microservice architecture on Linux. Surely it isn't the severe drag of dealing with C# and the incredible mess of .NET deployment in a rapidly iterating environment (and, to be fair, this is also in part Windows's fault, there's no good disposable-server model for Windows in a cloud environment because the provisioning stuff is not great, so you make bad decisions like persistent servers and Octopus). As it happens, I like C#, as a mostly-portable language for writing video games because the runtime has been ported almost anywhere I care about. I have a lot of open-source C# stuff in my Github and have been doing open-source C# since about 2007. But as an ecosystem for high-velocity, agile work, it's got problems. Maybe CoreCLR on Linux, once the bugs are well and truly killed, will be an answer, but it's not there yet.
- tacos 11y ago
  "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."
  - eropple 11y ago
    Here's the thing: literally none of that is right. You had to assume a lot of facts not in evidence to be that much of a jerk. It was a big task. But you did it! - 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.
    - tacos 11y ago
- deleted 11y ago
  [deleted]
- WorldWideWayne 11y ago
  Good luck with that! I hope it goes better for you than it did for the city of Munich.
  - eropple 11y ago
    So, okay, dude, let's have some real talk: you're generally a low-information troll here on HN--not bad enough to flag, bad enough to notice when your name comes up because it's almost never constructive or useful. But literally even you, as wrapped up in the weird little agendas you consistently show through your posting history, should know that attempting to use a desktop transition program (which, as it happens, I said nothing about) to slag on a migration of server software to another environment--and with CoreCLR, a very similar one by the same people--is weak sauce. HN doesn't need shitposters. Do better, yeah?
    - WorldWideWayne 11y ago
      That's your real talk? At least you could have been a tad more original or at least entertaining if you're going to resort to insults.

eropple 11y ago

I wonder why, then, the enterprise-by-any-reasonable-standard place I'm currently consulting is moving away from .NET and Windows to a polyglot microservice architecture on Linux. Surely it isn't the severe drag of dealing with C# and the incredible mess of .NET deployment in a rapidly iterating environment (and, to be fair, this is also in part Windows's fault, there's no good disposable-server model for Windows in a cloud environment because the provisioning stuff is not great, so you make bad decisions like persistent servers and Octopus). As it happens, I like C#, as a mostly-portable language for writing video games because the runtime has been ported almost anywhere I care about. I have a lot of open-source C# stuff in my Github and have been doing open-source C# since about 2007. But as an ecosystem for high-velocity, agile work, it's got problems. Maybe CoreCLR on Linux, once the bugs are well and truly killed, will be an answer, but it's not there yet.

tacos 11y ago
"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."
- eropple 11y ago
  Here's the thing: literally none of that is right. You had to assume a lot of facts not in evidence to be that much of a jerk. It was a big task. But you did it! - 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.
  - tacos 11y ago
deleted 11y ago
[deleted]
WorldWideWayne 11y ago
Good luck with that! I hope it goes better for you than it did for the city of Munich.
- eropple 11y ago
  So, okay, dude, let's have some real talk: you're generally a low-information troll here on HN--not bad enough to flag, bad enough to notice when your name comes up because it's almost never constructive or useful. But literally even you, as wrapped up in the weird little agendas you consistently show through your posting history, should know that attempting to use a desktop transition program (which, as it happens, I said nothing about) to slag on a migration of server software to another environment--and with CoreCLR, a very similar one by the same people--is weak sauce. HN doesn't need shitposters. Do better, yeah?
  - WorldWideWayne 11y ago
    That's your real talk? At least you could have been a tad more original or at least entertaining if you're going to resort to insults.