Why should I use containers instead of deploying build artifacts directly to Azure App Services or AWS Elastic Beanstalk?

Question

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?

Answer 1

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.

Answer 2

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.