Howdy folks! Choosing the right Azure service for your hosting needs can be overwhelming, especially if you are new to the cloud or just came from some other vendor. In my previous article, I looked at the Azure platform from a high level, which can help you get to the right set of services for your hosting needs. However, if that's not enough, here's a comparison of Azure App Service, Azure Service Fabric, and Azure Kubernetes Service from an apple to apple perspective.
1. Native Cloud Features
Architecturally, it is standard practice to leverage as much as cloud-native functionalities(PaaS/CaaS as compared to IaaS) as possible, or leveraging a standard that is portable across the cloud vendors. It leads to increased developer agility, stronger operational control, awesome developer tooling, offloading cross-cutting concerns and functionality to cloud like auditing, role-based access control, authentication, authorization, DevOps integration, log analytics, telemetry etc. Cloud native computing foundation has put up an awesome set of resources and tooling information that you can look to get to the right practices and architecture for a solid future ready cloud architecture.
App Service with the App Service Environment is the native PaaS offering in Azure with maximum cloud-native functionalities backed in. It has everything you would expect to leverage cloud-native features. It is a fully managed PaaS offering with maximum integration and support of native cloud functionalities including SSL encryption/termination, load balancing, auto-scaling, public/private addresses, log aggregation, SCM integration, DevOps, FTP, Kudus, process exploration, log streaming etc. However, it is not completely portable and not vendor agnostic, we will look into a couple of these aspects later.
Azure Kubernetes Service is a CaaS offering which sits somewhere between a PaaS and an IaaS. That said, it does not offer complete native cloud integration and offers a managed version of the open source Kubernetes orchestration engine. Although, it should be noted that Kubernetes is one of the open source standards of cloud-native foundation and the recommended architectural tooling for an inter-operable cloud architecture. That said, AKS miss some of the native functionality that could be offered by Azure out of the box. It means some of the functionalities like SSL encryption/termination, load balancing(partial), SCM, kudus, auto-scaling etc. has to managed on our own. It does provide native functionalities like log analytics, managed service identity, encryption etc. However, I must say it's a new offering in the Azure stack and none of the vendors(excluding Google) has much powerful native support for this. But, looking at the industry trend, it is a much demanding landscape and Azure is trying hard to add as much native support as possible. Quick fun fact: a number of commercial PaaS solutions like OpenShift is built on Kubernetes and recently Amazon has also launched a managed Kubernetes offering.
Azure Service Fabric is yet another PaaS offering, but unlike App Service, it is a different beast. As a matter of fact, App Service internally is built on the Service Fabric. It is an amazing product for large scale complex production application where 24x7 availability and resiliency is of utmost importance. It has a ton of native functionality, including native development framework, development tooling, powerful native orchestration, cluster management, auto-scaling, self-healing, etc. It's a proprietary Microsoft stack and if you are not worried about using Microsoft tooling like Visual Studio, .Net framework and the likes; Service Fabric definitely wins on the cloud-native features and is also inter-operable because it is also recently open sourced by Azure.
2. Architecture/Usage Patterns
Not every cloud offering suits every architectural need in the long run. It is vital to understand the requirements of the product and then looking for an appropriate service offering to meet the needs. An architecture might require complex orchestration, service discovery, rigid perimeter boundaries, network isolation, etc.
App Service is well suited for small to medium-sized applications including web jobs, web API, mobile API, n-tier architecture etc. It could be challenging to achieve complex mesh communication and networking needs with App Service. There are specialized tiers(App Service Environment) with the Isolated pricing tier that allow some advanced networking facilities. Lift and shift architecture or the needs of the micro-service communication including service discovery, throttling, rate limiting, circuit breaker etc. is not something it can achieve gracefully.
AKS, on the other hand, is built specifically for micro-service and event-driven architecture where complex networking isolation, multi-tenancy, orchestration, discovery, advanced clustering are the basic needs. It can easily be used for lift and shift architectural styles and large-scale projects. Plus, it has the blessings of Cloud Native Foundation, of which Microsoft is a founding member.
Service Fabric is also built for the micro-service and event-driven architectures and pretty much support everything that AKS offers from the architectural standpoint. Where AKS is strictly a service orchestrator and handles deployments, Service fabric also offers a development framework that allows building modern stateful/stateless reactive and 12-factor applications. It is, however, a very opinionated framework with a large inclination towards Microsoft proprietary tooling.
Accept it or not, Containerization is the future. While Containerization might not be the must-have requirement for a lot of applications today, it is by no doubt a state of the art technology that is becoming mainstream with the DevOps and agility trends.
App Service for containers support containerization by deploying pre-built containers onto the app service plan, which seamlessly integrates with all the cloud-native features. The containers can also be connected with the Azure Container Registry for a seamless DevOps pipeline. There is, however, no orchestration or discovery support for a complete mesh micro-service communication. Also, advanced control like the resource quota, co-location and leveraging every single ounce of the infrastructure will not be possible.
AKS is built on the industry standard open source Kubernetes Engine with fully managed support. If containerization is one of the primary needs of the product, this is an absolutely perfect offering. It has everything that exists today in the containers ecosystem and is a completely managed and seamlessly integrated with Azure ecosystem.
Service Fabric also supports containerization, which is nicely integrated into the existing SF orchestration and discovery platform. However, containers are not the first class citizen and run as a guest executable. It means a lot of complex setup like resource quota, limits, advanced infrastructure placement, co-location etc. cannot be gracefully achieved.
4. Programming Languages/Working Environments
One of the primary motivation of the DevOps and the micro-service culture is to leverage the diversity in the team expertise, agility, and tooling of the service needs and keeping DevOps isolation. It is an industry-wide standard to have a 2 pizza micro-service team, which can operate with complete autonomy including the programming language and work environments.
App Service has native support for .Net, Java, NodeJS, Python, and PHP. While with the support of containers, any language could be used, containers unlike native language won't support remote debugging, Kudus, SCM, etc. but features like log aggregation, console and process exploration would still be available.
AKS, by the sheer nature, is language agnostic. It has plethora or industry standard open source tooling and other tools for DevOps, remote debugging, etc. AKS can be used with almost anything in the open source community ecosystem. In fact, if you would like to change the managed server with custom tooling or extensions, it is also possible.
Service Fabric is more than a service orchestrator. It has a service development framework with .Net and Java support, while primary inclination, community and major API support is on the .Net front with tooling of Visual Studio. Additionally, the framework is highly opinionated with lack of extensions if one is inclined towards another open source stack like Spring Boot, Lightbend Reactive stack etc.
5. Azure Costs
Let's be honest, whatever the leadership is saying, the biggest motivation of cloud migration is money and every ounce counts. Business owners are rushing to move to the cloud to save cost and Cloud vendors are trying to eagerly fetch the accounts with monetary discounts.
App Service starts at a fairly cheap offering with a number of hosting options including free, pay per use and fixed dedicated premium plans and pretty much everything in between. While it sounds appealing at first, but fully managed service comes at a cost. As soon as you start looking for complex enterprise needs with dedicated compute power, secured VNet etc., costs start to rise up significantly with premium tiers like App Service Environment(Isolated pricing tier) etc.
AKS is free as of now, which means there is no charge for cluster management and the API usage(guess what master servers with full HA are for free). The chargeback is only applicable to the underlying nodes infrastructure, i.e. VM and disk storage. However, AKS is a relatively new service now and by no means, it is going to be free forever. Comparing it to the EKS(Elastic Kubernetes Service) of Amazon, it may start charging a monthly flat fee for cluster management soon.
Service Fabric offers pay per use model, which is similar to pay per use model of the Virtual Machines and disk storage. You have the option of paying for reserved underlying storage and get away with free cluster management APIs. However, as with AKS, we can expect a monthly flat fee coming soon.
6. DevOps/Operational Costs
Cheap Services are cheap! You get away with cheap infrastructure, but then spend thousands of hours managing it and having a dedicated support team. While recurring infrastructure cost is an obvious factor, the enterprise trends and engineering maturity is geared largely to incorporate the DevOps pipelines in their existing projects. This is driven by the motivation of minimizing operational costs and streamlining faster release cycles, especially with cross location teams.
App Service offers multiple models of DevOps integration with the possibility of SCM(git) integration, FTP, Kudus, docker, secure DevOps, etc. Additionally, it has also inbuilt support for canary releases, blue-green deployment via features like deployment slots.
AKS does have an obvious benefit of leveraging industry standard tooling and community support for lowering the operational costs. While it does take some uptime to get familiar with complex operational features, it is fairly easy to integrate the standard DevOps pipelines with containers, HELM, Jenkins(or the like) and Azure Container Registry. Azure also has a built-in DevOps pipeline and toolkit to get started easily.
Service Fabric as we know is a Microsoft proprietary technology. Although it was open sourced some time back, it still lacks the large community support and open source tooling for the DevOps. It has the great support of Azure Secure DevOps toolkit, but that is again tied to proprietary MS stack. Also, it has a large learning curve to understand the operational features and unlike Kubernetes, does not have a lot of community tooling and resources(books, courses) etc.
7. Infrastructure Control
While infrastructure control is not something that might seem crucial at first, it soon seems vital as the application grows. Adding custom OS agents for enhanced monitoring, disk encryption, premium shared storage, custom multi-tenant networking needs, GPU infrastructure etc. are some of the examples, we need more control for.
App Service offers minimal infrastructure control and is highly opinionated on the available resources. While there is limited control on the environment, Azure has done an amazing job of providing pretty much everything in the service. Some features like App Service Environments, go a step forward by adding a layer of abstraction of master/worker topology by default to offer more control. However, features like GPU machines are still not there and are strictly meant for simple web based applications.
AKS offers industry standard features and control on the worker topology and services. It is extremely customize-able to the extent of an IaaS, yet offering a layer of abstraction for ease of use and operations. The architecture of the AKS itself allows the use of any combination of infrastructure including custom ingress and egress controllers, GPU machines, custom API gateways etc. Additionally, Azure allows you to customize the fully managed server application by extending it with custom tooling and version desired.
Service Fabric also offers tight control over the underlying infrastructure. However, topology control is limited considering the proprietary technology and limited open source tooling and community work. While definitely, it is possible to control everything on service fabric, it is definitely not something everyone can do.
8. Vendor lock-in
Well, don't kid me! Moving across vendors happens in a lifetime. However, it is fair to asses the migration cost if a need arise.
App service being a complete PaaS offering has the highest degree of vendor lock-in. However, some degree of inter-operable architecture can be achieved by using standard DevOps processes, containers, and container registry. Similarly, using traffic manager instead of native deployment slots, using Terraform instead of Resource Manager Templates, etc. adds to a standardized process without vendor lock-in.
Managed Kubernetes service is offered by pretty much all of the major players (Amazon, Microsoft, Google etc.) and is easy to setup on premise as well. There is absolutely no vendor lock-in. A good way to start with cloud migration is to also do a lift and shift from on-premise Kubernetes cluster to AKS.
Service Fabric is a managed proprietary service. However, with the Microsoft recent stand on SF with the open source solution, it can be deployed and hosted on any cloud platform including on-premise. However, it also has to be considered that the other cloud vendors are not going to be offering the managed solution of the Service Fabric and it's migration though possible could be one of the hardest operational challenges for any migration.
9. Community Support
Whatever level of commercial support or partner engagement you have, community support is the biggest thriving factor of any technology in today's IT ecosystem. There is a reason why Java and other open source technologies are much more adapted as compared to .Net irrespective of an amazing ecosystem .Net has to offer.
App Service is a proprietary PaaS service. It has limited community support compared to the likes of any open source technology. That said, it is the most widely used service of the Microsoft stack and the best in terms of community support you may expect. Also, Microsoft has done an amazing engineering effort in building the service and documentation, and I don't expect you would need much support.
AKS being built on open source Kubernetes has the best community support. You can pretty much find a solution to every problem you might have and there are large chances someone else has had the same problem as you in the past and you have an open source tooling, or resource available to consume.
Service Fabric was recently open sourced. The adaption is not that great as compared to Kubernetes. Service Fabric Github repo has mere 2.5K+ stars as compared to whooping 45K+ stars on Kubernetes. However, it is slowly getting traction, and we are yet to see where it lands.
10. Agility/Learning Curve
Well, we don't need technology, that no one can understand. But that said, the entire idea of DevOps and micro-service ecosystem is to build an engineering culture where the standard process can be built where no team has to worry about the site reliability and deployment per se.
App Service has everything seamlessly integrated into the platform and does not require much effort to get started with. It is a pre-baked service that a junior engineer can get on and be productive in a couple of hours. Yes, you lose a lot of advanced features, but if you are ok with it, it could be the best choice.
AKS, by the sheer nature of Kubernetes, is a beast. It is by no-doubt complex enough to get screwed because of improper configurations. Yet, it has got almost everything you would need to learn and get started. There are a plethora of courses, blogs, books and community projects that one can pick and be productive faster.
Service Fabric is if not anymore, but at least as complex as Kubernetes. However, it lacks the community resources, books, courses, open source tooling etc. It can make you stuck in an ugly situation where you have to rely on the opinionated ways Microsoft documentation has recommended. If commercial support is good enough for your need, then there is nothing better than Service Fabric.
Business needs commitment! It really doesn't matter how amazing technology is if it is not backed by guaranteed uptime and performance. That said, Microsoft SLA's are credit backed. It means that for any infringement of SLA's, you get a given credit amount back and for any mission critical system, that can never be enough.
App Service at the time of writing this article offers a 99.95% SLA. It pretty much comes close to 43 seconds of downtime per day, which is fairly good even for a mission-critical application.
AKS, at the time of writing this article, do not offer an SLA on the API server. It offers an SLA on the underlying resources, which is 99.95% for Virtual Machines. However, looking at the technology trends across the industry, I expect a financially backed SLA for API server to be coming soon.
Service Fabric does not offer an SLA on the orchestration and the API server either. The SLA is backed on the underlying infrastructure as with the AKS. However, I am surprised by Microsoft not offering financially backed SLA on service fabric, when they claim it to be far superior and matured than Kubernetes.
Well, you may shrug it, but almost every industry is in some form of regulatory compliance today. Even if not, security is vital for everyone and every customer finds some satisfaction on the security compliance offered by the Vendor.
App Service is wonderful from the compliance perspective. Azure has put maximum effort in trying to get almost all the security and governance compliance in place for App Service. It is HIPAA, HITRUST, GDPR, PCI and a lot of other standards compliant.
AKS is relatively new. It is still under a lot of compliance process. It is already HIPAA compliant and HITRUST is in progress.
Service Fabric is relatively lacking in terms of compliance. Azure is prioritizing the services based on market pressure. Service Fabric has still not got that traction and hence the compliance processes are a little bit on the back foot.
Gosh, honestly that's a tough question. The above metrics helped me clearly compare what was important for my architectural and business needs. I hope it helps you too. Do, let me know if I missed some metric.