3 ms·

Maybe, though Lambdas are .Net on Linux, which probably means a lot of the existing workloads aren't a straightforward move.

by tyingq 5y ago

jayd16 5y ago
.NET 6 is fairly new and after the .NET Core reunification so I wouldn't say moving to Linux is exactly the complicated part of upgrading legacy .NET apps.
- phillipcarter 5y ago
  It can be. There’s a bunch of windows-specific and “this was a mistake to build” APIs that aren’t available in modern .NET. And for good reason! The big legacy .NET Framework apps all inevitably use some of them. I got a good taste of this when building the try-convert tool, and that was only focused on converting project files and package references.
- runevault 5y ago
  Depends on how far you're moving. Already on Core 3.1? Probably not an awful lift. If you're still trying to get off Framework if you are using certain libraries/namespaces (System.Data, WCF, System.Web, System.Addin) there is a lot more pain involved.
  - smackeyacky 5y ago
    The move from 3.1 core to .NET 6 was reasonably painless for me. A few of the setup classes on a web app changed but that was about it. It was much easier than .NET core 2 -> 3.1
tomnipotent 5y ago
What dependencies do you imagine code running in lambdas would have that preclude Linux as a deployment candidate? I was under the impression most of the Windows-only issues involved GUI frameworks.
- cm2187 5y ago
  Not necessarily lambda candidates but from what I have seen: COM dependency, or native specialised assemblies (in my case math libraries, internal enterprise components that aren’t under development anymore), anything to do with system.drawing. The crypto library is also very integrated with windows, .net core only partially implemented the API.
  - eropple 5y ago
    AFAIK System.Drawing has been separated out adequately in Core? System.Web is what comes to mind as a potential problem for a move like this, though.
- jmull 5y ago
  The TCP and socket APIs have significantly different async behavior. Double that if you want to cancel anything. (That's the first thing I tried cross-platform. So maybe just my bad luck, but I have doubts everything will work smoothly.)
- jeswin 5y ago
  Here's my experience as a consultant who has worked with several .Net shops: A significant percentage of .Net teams (in more enterprisey companies) have tech teams who haven't seen anything other than Windows. Deploying on Linux gets shot down in meetings by senior decision-making folks who again have seen only Windows. It's a bit of self-preservation, plus fear of the unknown.
- tyingq 5y ago
  >What dependencies do you imagine code running in lambdas would have that preclude Linux as a deployment candidate? The context was "Shit-ton of .Net running in on-prem corporate environments still", not code already running in a Lambda. There are plenty of Windows dependencies/assumptions that are not GUI code. Porting a .Net service, for example, which would be pretty common. And just lots of mundane stuff that's still work, like logging, file locations, etc.

Maybe, though Lambdas are .Net on Linux, which probably means a lot of the existing workloads aren't a straightforward move.

by tyingq 5y ago

Maybe, though Lambdas are .Net on Linux, which probably means a lot of the existing workloads aren't a straightforward move.

jayd16 5y ago

.NET 6 is fairly new and after the .NET Core reunification so I wouldn't say moving to Linux is exactly the complicated part of upgrading legacy .NET apps.

phillipcarter 5y ago
It can be. There’s a bunch of windows-specific and “this was a mistake to build” APIs that aren’t available in modern .NET. And for good reason! The big legacy .NET Framework apps all inevitably use some of them. I got a good taste of this when building the try-convert tool, and that was only focused on converting project files and package references.
runevault 5y ago
Depends on how far you're moving. Already on Core 3.1? Probably not an awful lift. If you're still trying to get off Framework if you are using certain libraries/namespaces (System.Data, WCF, System.Web, System.Addin) there is a lot more pain involved.
- smackeyacky 5y ago
  The move from 3.1 core to .NET 6 was reasonably painless for me. A few of the setup classes on a web app changed but that was about it. It was much easier than .NET core 2 -> 3.1

tomnipotent 5y ago

What dependencies do you imagine code running in lambdas would have that preclude Linux as a deployment candidate? I was under the impression most of the Windows-only issues involved GUI frameworks.

cm2187 5y ago
Not necessarily lambda candidates but from what I have seen: COM dependency, or native specialised assemblies (in my case math libraries, internal enterprise components that aren’t under development anymore), anything to do with system.drawing. The crypto library is also very integrated with windows, .net core only partially implemented the API.
- eropple 5y ago
  AFAIK System.Drawing has been separated out adequately in Core? System.Web is what comes to mind as a potential problem for a move like this, though.
jmull 5y ago
The TCP and socket APIs have significantly different async behavior. Double that if you want to cancel anything. (That's the first thing I tried cross-platform. So maybe just my bad luck, but I have doubts everything will work smoothly.)
jeswin 5y ago
Here's my experience as a consultant who has worked with several .Net shops: A significant percentage of .Net teams (in more enterprisey companies) have tech teams who haven't seen anything other than Windows. Deploying on Linux gets shot down in meetings by senior decision-making folks who again have seen only Windows. It's a bit of self-preservation, plus fear of the unknown.
tyingq 5y ago
>What dependencies do you imagine code running in lambdas would have that preclude Linux as a deployment candidate? The context was "Shit-ton of .Net running in on-prem corporate environments still", not code already running in a Lambda. There are plenty of Windows dependencies/assumptions that are not GUI code. Porting a .Net service, for example, which would be pretty common. And just lots of mundane stuff that's still work, like logging, file locations, etc.