.NET core - opening doors for Dockerization and Fargate
I found some sparse articles across the internet on the subject of getting Umbraco running on .NET core, and I've recently gained considerably more interest in this subject after getting another web service running on Amazon Fargate on the Elastic Container Service (ECS). Fargate is pretty awesome because it allows elastic web application hosting without ever needing to manage VMs. It's a technology I have been seeking for years because I always felt intuitively that there should be a way to deploy an application and obtain fully elastic hosting without needing to manually scale VMs. VMs are painful for many reasons, but one of the biggest issues is the 20 minute cold start time that makes full elasticity very difficult to achieve in practice.
I was able to get a docker container on Fargate to achieve a cold start time of < 120 seconds (usually closer to 60 seconds), which was quite surprising because my docker image is huge (~6 GB due to the need for many very large math and compute libraries). As per guidance from an AWS solutions architect, a smaller Docker image would have a much faster cold start time. (Cold start time could be more than 2-3 orders of magnitude faster if it's anything like AWS Lambda service if the Docker container is sufficiently light weight.)
This capability could open a lot of doors for Umbraco where that elasticity is needed, and the inability to utilize technology like that could also be prohibitive or negatively impactful for Umbraco's future.
Accordingly, I would like to revisit the subject of getting the latest Umbraco working on .NET core because that would allow us to dockerize the application and, aside from the many benefits of being able to leverage Docker, it would allow us to move towards a more fully elastic or "serverless" type of cloud hosting model.
So, what are the current barriers to being able to move the latest Umbraco to .NET core?
Is anyone else interested in working on this?
Then again, using App Services on Azure is almost like a kind of docker. ;) (Yes, I know they're not the same, but still...)
@cultiv, last I heard v9 was the one to be core since v8 is all DI and legacy removal. But then, v8 with variants should have been launched this january, right? ;) I guess you hear it more often than me.
Soz for not contributing, just couldn't help myself.
Yes, I agree that it doesn't have to take 20 minutes to scale out Umbraco installs. With load balancing and Azure App Services this is all possible withing seconds instead of minutes. I don't have any experience with AWS so I'm not sure how it works there.
@Lars-Erik - yeah, well you know how it goes when developers make a plan 🙈
So, obviously we're pretty behind on that plan and as far as I can tell it doesn't look we will be able to remove all legacy code and release a v8 this year. There's no shame in releasing major versions more often though so I think that would be a better way to go. :)
In any case: we'd LOVE to get on the .NET Core bandwagon, but it will take quite a bit of time for us to get there.
We are currently running our app of U10 on the following stack: AWS ECS -> Fargate -> RDS DB -> Media on EFS
We are struggling with auto scaling our ECS pods. The backend turns white and is unusable. Plus, media transfer via Usync exporter/ Usync Publisher and even manually, is causing data integrity issues. These errors usually cause the entire app to crash and show 503 error.
Is someone here running their Umbraco on ECS and can explain their architecture / what might be the issue with our architecture?
.NET core - opening doors for Dockerization and Fargate
I found some sparse articles across the internet on the subject of getting Umbraco running on .NET core, and I've recently gained considerably more interest in this subject after getting another web service running on Amazon Fargate on the Elastic Container Service (ECS). Fargate is pretty awesome because it allows elastic web application hosting without ever needing to manage VMs. It's a technology I have been seeking for years because I always felt intuitively that there should be a way to deploy an application and obtain fully elastic hosting without needing to manually scale VMs. VMs are painful for many reasons, but one of the biggest issues is the 20 minute cold start time that makes full elasticity very difficult to achieve in practice. I was able to get a docker container on Fargate to achieve a cold start time of < 120 seconds (usually closer to 60 seconds), which was quite surprising because my docker image is huge (~6 GB due to the need for many very large math and compute libraries). As per guidance from an AWS solutions architect, a smaller Docker image would have a much faster cold start time. (Cold start time could be more than 2-3 orders of magnitude faster if it's anything like AWS Lambda service if the Docker container is sufficiently light weight.) This capability could open a lot of doors for Umbraco where that elasticity is needed, and the inability to utilize technology like that could also be prohibitive or negatively impactful for Umbraco's future.
Accordingly, I would like to revisit the subject of getting the latest Umbraco working on .NET core because that would allow us to dockerize the application and, aside from the many benefits of being able to leverage Docker, it would allow us to move towards a more fully elastic or "serverless" type of cloud hosting model.
So, what are the current barriers to being able to move the latest Umbraco to .NET core? Is anyone else interested in working on this?
Version 8 is going to prepare for .Net Core support but we'll not be able to get rid of all legacy code at this point yet.
We expect v9 to be ridding most legacy code and I (personally, not speaking for the company here) expect v10 to be .net core compatible.
In other words, it will still be a few years before we get there :-)
FWIW you can run it in Docker using the Windows Server docker image, there's a bunch of images on Docker Hub - https://store.docker.com/search?q=umbraco&source=community&type=image
Sure it's probably like 7gb of image, but it's a start somewhere ;).
Then again, using App Services on Azure is almost like a kind of docker. ;) (Yes, I know they're not the same, but still...)
@cultiv, last I heard v9 was the one to be core since v8 is all DI and legacy removal. But then, v8 with variants should have been launched this january, right? ;) I guess you hear it more often than me.
Soz for not contributing, just couldn't help myself.
Yes, I agree that it doesn't have to take 20 minutes to scale out Umbraco installs. With load balancing and Azure App Services this is all possible withing seconds instead of minutes. I don't have any experience with AWS so I'm not sure how it works there.
@Lars-Erik - yeah, well you know how it goes when developers make a plan 🙈
So, obviously we're pretty behind on that plan and as far as I can tell it doesn't look we will be able to remove all legacy code and release a v8 this year. There's no shame in releasing major versions more often though so I think that would be a better way to go. :)
In any case: we'd LOVE to get on the .NET Core bandwagon, but it will take quite a bit of time for us to get there.
Wait, did you forget it's 2018 or are you saying v8 is delayed for '19?
No I am not saying that 😂
We wouldn't be able to release v8 this year if we were to do a thorough cleanup. Obviously, v8 is (finally) coming this year. :-)
\o/
I don't mind if it's 8.4 that will be the version that finally rid itself of all hard dependencies. :)
That's really disappointing to hear. V8 was announced years ago.
We are currently running our app of U10 on the following stack: AWS ECS -> Fargate -> RDS DB -> Media on EFS
We are struggling with auto scaling our ECS pods. The backend turns white and is unusable. Plus, media transfer via Usync exporter/ Usync Publisher and even manually, is causing data integrity issues. These errors usually cause the entire app to crash and show 503 error.
Is someone here running their Umbraco on ECS and can explain their architecture / what might be the issue with our architecture?
is working on a reply...