Azure App Service vs AKS vs Service Fabric
Because my previous article turned out to be very popular, I decided to make a followup article that extends the comparison of Azure Kubernetes Service and Service Fabric to Azure App Services for Linux (Docker). This is a very reasonable alternative for most of developers that are starting with containers and want to begin their journey with containers.
If you haven’t read my previous article, you can find it here: Kubernetes vs Azure Service Fabric
DISCLAIMER
Some parts of this article do not apply to Azure App Service for Windows or Linux without containers.
Azure App Service vs other stuff
Neither AKS nor Service Fabric is a “fully managed” service. Azure gives you SLA only on the underlying virtual machine infrastructure. This means that neither Kubernetes, nor Service Fabric will give you guarantee that your applications still work after any cluster-level failure. I will not go into detail what a cluster-level failure means for me, but I can tell you there is a lot that can happen when you orchestrate tens/hundreds of containers on a set of predefined machines. This also means that you need an automation system in place, in case of a failure. Sometimes you even need a dedicated team of engineers, that monitors your cluster 24/7. There are many intricacies and nuances of running a Kubernetes cluster. The amount of effort to prepare and maintain a Kubernetes environment is non-trivial.
Side note
I believe there are exceptions to these rules. Small clusters that are not mission-critical are also a viable option for small businesses. I had been running production workloads without any interruption for almost half a year on a small Kubernetes cluster. It all depends on what a production-ready cluster is for you.
App Service for Linux - the good parts
Azure App Service for Linux is much easier to manage than Kubernetes and Service Fabric. It is a fully managed service, which means that there is an SLA guarantee on your application working in the environment.
Azure App Service is easy to scale. You get automatic scaling, such as by CPU usage, out-of-the-box. App Services also provide you with free SSL certificate for one of the Azure domains that you get along with the service.
Setting up an App Service is also very straightforward. It takes maximum of few hours to deploy your first container, even without prior experience with it.
Azure App Service also supports simple deployment scenarios, such as blue/green or canary deployments. There is a very simple mechanism called “deployment slots” that enables you to swap production container with one of the pre-heated containers that are running in a “deployment slot”. There is also an option to route parts of the traffic to one of the deployment slots.
App Service for Linux - the bad parts
There is a basic auto-scaling in place, but don’t expect to cost-optimize your solutions or be able to co-locate dependent services. In case you do, you will quickly realise that co-located services share a lot of risk. If you try to save money, e.g. by putting multiple applications onto a single App Serivce Plan, you surrender control over those containers. It is now Azure’s responsibility to allocate memory and CPU time for those containers. This has serious implications as Azure does not know which containers should be kept alive at all cost, and which can be killed in case of resource scarcity. You also cannot configure it in your App Service Plan. Therefore, it is rather recommended to run a single application per a single App Service Plan, unless you are ready to live with the consequences of co-locating services.
Running applications in App Service Plan is much more expensive than running them in AKS or Service Fabric. E.g. running AKS cluster is entirely free. You pay only for the underlying VM infrastructure. With App Service Plan, you also pay for managed service that makes sure your containers are always working.
App Service experience in Azure Portal is still not there. Looking at logs in the Azure Portal is a pain for my eyes. 
The textbox is claustrophobically small and cannot/needs to be resized every time you open azure portal. Also the logs are not displayed in real-time. There is sometimes a few minutes delay between your action and log display in the portal. I am not sure if refresh button works as well. For those frustrated with Azure Portal, there is also an option to download logs in the zip file.
You are not always aware in what state your container is. If the image that you want to run does not exist, Azure App Service might get confused and not accept any other image change afterwards. Combination of a lag in log output as well as inconsistent user experience in the portal cost me a lot of headaches in the past.
Conclusion
Azure App Service is NOT a container orchestrator. This means that you will not get all the flexibility of a container orchestrator. Don’t treat it as such then. It is a much simpler service, though. It does not require a lot of knowledge or experience with running containers and is definitely recommended for people that don’t know where to start with Docker.
On the other hand, if you need a microservice platform and you already possess significant experience with containers, you probably are better off with AKS or Azure Service Fabric. Remember that the price you pay is the knowledge and time effort to setup those solutions.