Amazon launched its first AWS services in 2006: S3 for Storage and EC2 for Compute. Now there are a plethora of services and offerings from various cloud vendors like AWS, Azure, and Google Cloud. It can be overwhelming to evaluate so many options and pick the right one for you.
Selecting the right infrastructure alternative is not only about the technical requirements of your application but also about expertise in your team and the growth stage of your business.
In this article, you will learn about the kinds of cloud deployment alternatives available today, and how to select the right one for your needs. We will also dig into serverless alternatives, and what can make the migration across alternatives easier as your team and business grow.
Cloud Computing
Let’s quickly review what Cloud Computing is and why it has become so widespread.
Cloud Computing is the virtualization of the most fundamental computer resources and making them available on-demand:
- Compute: CPU, GPU, and memory
- Storage: persistent disk
- Network: bandwidth for data IO
Other cloud services such as databases, event-queues are built on top of these raw resources.
Users don’t have to physically maintain the IT infrastructure. Instead, computer resources are consolidated in distributed data centers and shared among users. The value proposition of the Cloud is:
- Freedom from CapEx planning for IT infra
- Ability to grow IT infra on-demand, and
- Economies of scale due to infra consolidating in data centers.
There are two kinds of cloud IT infra:
- On-Premises: when you run your own data center consolidating IT infra for your teams across your company.
- Public Cloud: when you outsource it to a cloud vendor (AWS, Azure, Google Cloud, IBM, etc.), whose IT infra is shared by multiple customers.
There are different service models (IaaS, PaaS, SaaS, etc.) depending upon the level of control and abstraction you desire in your cloud deployments. We will examine each of these models, but let’s first understand Serverless Computing.
Serverless Computing
Serverless does not mean that there are no servers. It is just that developers don’t interact with or manage the servers. Serverless Computing has three characteristics:
- No Server Admin: no upfront provisioning, no management of servers
- Auto-scale: infra scales automatically with usage and is highly available
- Pay-per-use: no idle infra cost, pay for only what you use
All three major cloud vendors offer several serverless cloud services like databases, data warehouses, event streaming, and API gateways. In this article, we will focus on Serverless Computing options for the fundament computer resources (compute, memory) that you use to deploy your applications and services.
Serverless deployment offers two benefits:
- Rapid Development: Reduced DevOps frees up resources to focus on development and improves developer productivity. You can develop and launch your apps and services faster.
- Lower Cost: You can pick a cost-effective serverless alternative (thanks to pay-per-use) while enjoying insurance against sudden load spikes (thanks to auto-scale). Only at a very high scale, it is more economical to move away from serverless and manage the compute-scaling yourself.
Cloud Deployment: IaaS vs CaaS PaaS vs FaaS vs SaaS
Let’s walk down from On-premises to all the way to SaaS to understand the cloud deployment spectrum.
On-Premises (on-prem)
In traditional On-Premises cloud deployment, you build and operate data centers in multiple geographies. You control and manage everything starting from bare metal hardware.
Clearly, this approach is suitable only for very very big corporations like Facebook and Google. Not everyone can afford to set up their own multi-geo data centers and do continuous capacity planning of that scale. Even Twitter considered moving everything from on-prem to cloud and migrated data processing and analytics to Google Cloud.
Infrastructure as a Service (IaaS)
This is the simplest of the options. You get a virtual machine on the cloud. You do everything you would have done on your local machine, but now through ssh to a remote virtual machine. You can start (and shut down) as many as you want with a click on a browser.
Your cloud vendor is virtualizing the hardware using a hypervisor to divide and allocate resources. It may even offer you an option for dedicated machines without sharing them with any other tenant.
- AWS: Amazon Elastic Compute Cloud (EC2), EC2 Dedicated Host, EC2 P3 for GPU
- Azure: Azure Virtual Machine, Azure Dedicated Host, Azure GPU Optimized VMs
- GCP: Google Compute Engine, Sole-Tenant Nodes, Cloud GPUs
Container as a Service (CaaS)
Containers are lightweight packages of application code and all the necessary dependencies (e.g., specific versions of programming language runtimes and libraries) required to run application services.
Just as Virtual Machines virtualize the computer hardware, containers virtualize the operating system. Containers define precise application runtime, ensuring the same execution environment regardless of whether you are running the application on your laptop or on a public cloud.
The container engineer can be run on a bare-metal physical machine, but in the production environment, it is typically run in a Virtual Machine.
The containers are orchestrated using a tool like Kubernetes. You have to configure a Kubernetes cluster and define rules for scaling. As the load increases on your service, Kubernetes will create more container instances and virtual machine nodes depending upon the configuration.
- AWS: Elastic Container Service (ECS) or Elastic Kubernetes Service (EKS) with EC2
- Azure: Azure Kubernetes Service (AKS)
- GCP: Kubernetes Engine
Serverless CaaS
Whether it is virtual machines or containers with an orchestrator, both require provisioning and managing servers. Serverless CaaS delegates the responsibility of provisioning the clusters to the cloud vendor. You run your containers on clusters managed and scaled by the cloud vendor.
You don’t need to make any changes in the container to switch between CaaS and Serverless CaaS. Both run the same container. The only difference is who manages the server cluster, you or the cloud vendor.
Serverless CaaS has all benefits of containers but without the hassle of managing the Kubernetes cluster.
- AWS: App Runner; Elastic Container Service (ECS) or Elastic Kubernetes Service (EKS) with Fargate
- Azure: Azure Container Apps
- GCP: Cloud Run
Platform as a Service (PaaS)
PaaS offerings predate CaaS. Various cloud vendors offer a set of canned runtimes along with auto-scale. You can pick the runtime that suits your web app or services.
In a way, the canned runtimes are like containers, albeit defined by the cloud vendor and not you. I foresee Serverless CaaS overshadowing PaaS. Why will you limit yourself to the runtime canned by vendors when you can pick your own with a container?
- AWS: Elastic Beanstalk
- Azure: App Service
- GCP: App Engine
Function as a Service (FaaS)
You design your application as a collection of stateless, event-driven, and short-lived “nano” services. In a typical 3-layer design, you have an API Gateway that maps the service APIs to a Function. The Functions may interact with datastores to perform the business logic and then return the result.
Cloud vendors support several programming languages in their Function offering. But do check the cold-start time: the time it takes to launch the function upon receiving the trigger.
Upon receiving the triggering event (which can very well be a REST API call), the Function is launched. It shuts down upon completion. So you are billed only for that duration. Since a Function is launched (or reused) for each event trigger, scaling is transparent.
- AWS: Lambda
- Azure: Azure Function
- GCP: Cloud Function
Software as a Service (SaaS)
A SaaS encapsulates the logic for a task. For example, Amazon Cognito does user sign-up, sign-in, and access control, so you don’t have to even code that logic. Similarly, Google’s Speech-to-Text service does automatic speech recognition and transcribes an audio stream to text.
The SaaS universe for common tasks reduces the development time. You pick the right services, configure and stitch them together, and code only the business logic specific to your app. You pay for each API invocation.
Serverless Architecture
Serverless Architecture is an approach to designing applications and services that eliminates the need to provision and manage underlying server infrastructure.
You design an application by weaving the services provided by the cloud vendor and coding only your business logic.
That means you will use databases, identity services, API gateway, event queues, and other serverless services provided by the cloud vendor instead of deploying those on your own. A drawback of this approach is vendor lock-in because you have tied your services intimately with those provided by the cloud vendor.
You can mitigate that risk to some extent given the similarities between ecosystems of major cloud vendors. If necessary, you may consider building thin Facade and Factory Method design patterns to isolate code specific to cloud vendors and keep your business logic untainted.
Serverless != FaaS
Many people consider only FaaS to be Serverless. In my opinion, that is an extreme definition of Serverless. Implementing all business logic as short-lived, stateless, event-driven (“nano”) services is neither always ideal and may cost you more, especially when you have consistently high usage.
As long as you are not provisioning, configuring, and managing the server clusters to run and scale your services, I consider it Serverless. In my book, packaging even a monolith service in a container, and deploying it on Serverless CaaS is Serverless.
Cloud-Native Development Strategy
I do not believe in a technology-centric development strategy. It is important to consider team capabilities and business circumstances. Definitely think about making your tech decisions future-proof, but not at the cost of the present.
If you are building PoC or initial Minimal Viable Product
You want to put it into users’ hands as soon as possible, and time is the most precious commodity. Also, your service load will be very low and sporadic. FaaS solution will be the simplest and fastest to build provided it suffices your technical needs.
If FaaS does not work out, then try out PaaS runtimes from your vendors. Only in rare cases, you will need to go for Serverless CaaS or beyond.
You have a Product Market Fit and know what you need to build
You can stay with FaaS or PaaS, especially if you expect a sparse traffic load for quite some time. But at this stage, it is time to clean the mess your FaaS/PaaS might have become while iterating over PoC/MVP.
The design decisions you make at this stage will stick around for quite a while. Since you have clarity on business needs and have a fair idea of what you need to build, you should take a close look at your application architecture and ensure it will last 100x traffic growth.
I recommend starting with CaaS. You want to focus on serving your customers’ needs, and do not want to firefight daily with intermittent unreproducible bugs. You should invest in defining containers for your services, and use them across dev, stage, and prod deployment.
The choice boils down to CaaS and Serverless CaaS. Answer these two questions:
- Do you currently have Kubernetes DevOps capabilities in your team?
- Are your cost modeling projections lower for CaaS?
If the answers for both are “Yes”, then go for CaaS, else go for Serverkess CaaS.
Remember that this mistake is not that costly, you can easily reverse this decision because the same containers can be deployed on CaaS or Serverless CaaS. Switching between the two does not require any change in the container or application code.
If you need full control of VMs for some crazy reason
Well, you are doomed to be stuck at IaaS.
Cloud Migration Strategy
If you are migrating an existing application or service to the cloud, the first question is: do you want to migrate it “as is” or want to optimize it for the cloud?
Lift and Shift
You can migrate an app to the cloud without redesigning it or making code changes. It is also called rehosting.
If the application can be containerized, then you must define containers for it and enjoy the benefits of a uniform runtime. The choice between CaaS and Serverless CaaS is the same. Choose CaaS if you have Kubernetes skills in your DevOps team and CaaS is cheaper, else go for Serverless CaaS.
If the app can’t be containerized but one of the PaaS runtimes suits it, then go for PaaS, else you have to go for IaaS.
Cloud Optimized
If you are redesigning the app and optimizing it for the cloud, then you are in the same situation as developing a new app with two caveats:
- If you will need VM-level control, then there is nothing to redesign. You will be going to use IaaS, so stick to lift-cand-shift.
- Since it is an existing app, you already have Product Market Fit. So, follow that same decision path.
Summary
A quick recap of what this article covered:
- What is cloud computing?
- What is serverless?
- Cloud deployment spectrum: IaaS vs CaaS vs PaaS vs FaaS vs SaaS
- Compute alternatives in the major clouds: AWS vs Azure vs Google Cloud
- Cloud-native development and migration strategies
Hope you found this article useful. Please give your feedback and suggestions in the comments.
