They keep saying “Cloud-Native Developers” in a bunch of titles and the text, but I’m pretty sure this is mostly going to be Azure-cloud focused.
Since AWS only supports LTS versions, a lot of things have been stuck on dotnet6 there. (Unless you install your own frameworks or docker or own ec2 images or something) - But no proper native cloud support for a lot of dotnet7 from AWS
For example, Lambdas don’t natively support anything besides dotnet6, and dotnet8 is still scheduled to be released (Mentions February 2024, but used to mention January 2024, so who knows when it’s actually going to be released)
Since dotnet6 and dotnet8 were LTS, I doubt dotnet9 is going to be as well, and is going to be STS again. So all the Cloud-Native stuff in dotnet9 is pretty much going to be Azure
I don’t use AWS but I updated one of my apps (https://dnstools.ws/) to use AoT and really like it since it avoids having to deploy .NET to the servers. Saves quite a bit of disk space which is useful since this app is deployed to a bunch of small servers.
I suppose you are right. If AWS doesn’t support STS versions, these will be only applicable to Azure (I know nothing about GCP). It probably makes sense for AWS to stick to LTS versions (I would do the same). But isn’t that a choice made by AWS (rather than Microsoft).
But isn’t that a choice made by AWS (rather than Microsoft).
Well it’s both, though my comment wasn’t to blame Microsoft on this. But LTS is a relative, non-defined term. AWS has a policy to only support LTS versions because they (understandably) don’t want to deal with new versions every couple of months. Within Microsoft terminology STS (Standard TS) is 18 months of patching, LTS is 36 months of patching.
So it’s just semantics. dotnet-STS is not some goofy hobby language that gets new versions every couple of months. 18 months from a massive team with a massive userbase is pretty long term compared to some other frameworks.
So either AWS could not be so nitpicky about it not being labeled LTS - or Microsoft could just label one version (dotnet7, dotnet9) as LTS, and the 36 months version as Extra-LTS or whatever lol. And all the dotnet versions would fall within the AWS native-support parameters
I don’t use AWS but it seems like a big limitation if you can only use frameworks they officially support? What happens if you use a non supported framework?
They keep saying “Cloud-Native Developers” in a bunch of titles and the text, but I’m pretty sure this is mostly going to be Azure-cloud focused.
Since AWS only supports LTS versions, a lot of things have been stuck on dotnet6 there. (Unless you install your own frameworks or docker or own ec2 images or something) - But no proper native cloud support for a lot of dotnet7 from AWS
For example, Lambdas don’t natively support anything besides dotnet6, and dotnet8 is still scheduled to be released (Mentions February 2024, but used to mention January 2024, so who knows when it’s actually going to be released)
Since dotnet6 and dotnet8 were LTS, I doubt dotnet9 is going to be as well, and is going to be STS again. So all the Cloud-Native stuff in dotnet9 is pretty much going to be Azure
We’ve switched to deploying everything as self-contained apps as we got tired of waiting for AWS to update their stuff.
If Lambda cold-start is important for you, publish the app with native AOT.
I saw an amazing demonstration of a GUI app’s cold start time with .NET 9 AoT on Twitter: https://x.com/wieslawsoltes/status/1757488043143942528?s=20
I don’t use AWS but I updated one of my apps (https://dnstools.ws/) to use AoT and really like it since it avoids having to deploy .NET to the servers. Saves quite a bit of disk space which is useful since this app is deployed to a bunch of small servers.
I suppose you are right. If AWS doesn’t support STS versions, these will be only applicable to Azure (I know nothing about GCP). It probably makes sense for AWS to stick to LTS versions (I would do the same). But isn’t that a choice made by AWS (rather than Microsoft).
Well it’s both, though my comment wasn’t to blame Microsoft on this. But LTS is a relative, non-defined term. AWS has a policy to only support LTS versions because they (understandably) don’t want to deal with new versions every couple of months. Within Microsoft terminology STS (Standard TS) is 18 months of patching, LTS is 36 months of patching.
So it’s just semantics. dotnet-STS is not some goofy hobby language that gets new versions every couple of months. 18 months from a massive team with a massive userbase is pretty long term compared to some other frameworks.
So either AWS could not be so nitpicky about it not being labeled LTS - or Microsoft could just label one version (dotnet7, dotnet9) as LTS, and the 36 months version as Extra-LTS or whatever lol. And all the dotnet versions would fall within the AWS native-support parameters
I don’t use AWS but it seems like a big limitation if you can only use frameworks they officially support? What happens if you use a non supported framework?
Pretty sure they are referring to AOT and docker when they say that. That seems to be the direction they are pushing with their cloud stuff.
.net Aspire is their new toy and that is generally targeting kubernetes for deployment.
The article specifically talks about AOT and kubernetes so I think that’s a safe bet at what they mean.