1

Recently, I have been told by others to look into containerization of my stateless web applications (in this case .NET Core 2.x and 3.1). All of my dependencies are retrieved from public and private Nuget feeds.

For a few years, I have been deploying to Azure App Services (Web apps) with no issues and only some very simple configurations on creating the App Service. Azure (and I'm guessing AWS) seems to be able to handle common configurations like mine pretty well. What am I missing out on by not using containers?

Do Docker containers really just solve a problem that I don't have?

Kyle J V
  • 226
  • 1
  • 8
  • 1
    See my answer here: https://softwareengineering.stackexchange.com/a/404692/6509 It answers the general why containers rather than straight VMs question – Berin Loritsch Feb 05 '20 at 17:55
  • And ASP.NET doesn't really change the general concept. Although I will say my experience with small Elastic Beanstalk deployments has been very lackluster. Both performance and when Beanstalk wants to restart the images seems very arbitrary. – Berin Loritsch Feb 05 '20 at 17:58
  • @BerinLoritsch , thanks for the link, but my question involves App Services vs Container, not VM vs Containers. The advantages of a container in your answer are for the most part already realized in an App Service, except for "Containers behave the same whether they are hosted in the cloud or on premises, allowing you to be "Cloud Ready" before your company is ready to pull that trigger" – Kyle J V Feb 05 '20 at 17:58

3 Answers3

3

On a very high level, you are not missing out on anything crucial. Docker (and Kubernetes) provide a runtime environment, control plane, deployment, network abstraction etc. which are also provided by cloud vendors. They are different mechanisms but they solve the same problems.

With containers, it's a little easier to avoid vendor lock-in. Although AWS and Azure perform similar functions, it's going to be a lot of pain to migrate if you need to. Also it's more convenient to run services not natively offered by the cloud vendor. It's just another container.

It's a little bit like Netflix vs. buying movies one by one. If you are happy with the content mix on Netflix, you are fine. In the future the content mix may change or they fall behind the competition in features. But I wouldn't necessarily spend my evenings researching IMDB instead of just watching stuff.

Martin K
  • 2,867
  • 6
  • 17
3

A full answer to your question depends on the complexity of deployment. If you are looking to host a single ASP.Net (core or classic) website, with no additional services, then I would recommend the Azure App Services specifically.

When testing Azure App Services, the end-to-end story is really nice:

  • Integration with github or Bitbucket git repositories allowed you to deploy once changes were merged into master (Azure App Services would check out the repo, build the app, and deploy it)
  • Hosting the site was rock solid, and appropriately sized

When testing AWS ElasticBeanstalk, the end-to-end story is not as pretty:

  • No direct integration with git, so you have to publish using the AWS plugin. The package is not a standard Visual Studio web deployment package
  • Hosting is shaky. If the VMs are too small they restart randomly, and start times are measured in minutes

Growing beyond simple web applications

When you have a group of web services that work in concert as a whole application, containers start to be worth the investment. Typically, containers start up much faster than AWS EC2 instances (what your app is running in with ELB) which means that using an orchestration service like EKS to scale your application much more attractive.

The next thing to think about is cost. In AWS you pay for every EC2 instance you are using, directly or indirectly. Not sure how some of the managed services work in Azure, but it is likely a similar story. Many times there is spare capacity in your EC2 instance that could be used to host another instance of your application, or another microservice. Containers let you use that space while ensuring the configuration is correct.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • so what you're saying is that if the application has anything "weird" and ".net on AWS is weird", then containers make sense. So I've just have had a golden scenario for a while with .net + Azure app services? – Kyle J V Feb 05 '20 at 18:30
  • 1
    Essentially. I'm in a continual battle with Elastic Beanstalk at the moment. It's a classic ASP.Net application using managed elastic search. AWS Managed databases and search services are usually really good. Its EBS I'm having issues with. – Berin Loritsch Feb 05 '20 at 18:36
1

I would say in this context it is about the flexibility containers bring to your app. Sure dotnet is cross-platform nowadays, but containers give you portability to be able to run it anywhere where containers can be run. App Services, AKS, ACI or even AWS or other cloud providers. Th analogy I always use is a container image is a lot like a DVD - as long as someone has a DVD player, they can play your DVD. It is a similar story with containerized apps. You can literally host the container app anywhere from a complicated service that provide orchestration and scale like AKS, to more simple, single-instance services that do not provide scale like ACI. App Service provide a kind mix between the two but just to prove the point I am making, strictly speaking your container app should also run on a Pi device (not that you will do this) if it has a container runtime installed.

SO, in short, portability and flexibility.

Johan Myburgh
  • 19
  • 1