Infrastructure Elasticity
The Problem
Say we run an e-commerce business and have varying traffic load. Without elasticity we need to run our infrastructure at the scale necessary to support peek traffic at all times incurring the highest cost at all times or we need to try to anticipate traffic and scale things up and down manually. This, as you can deduce, is very inefficient and expensive.
The Goal
The goal is to make our infrastructure efficient and cost effective, or in other words, elastic. This means we run only the capacity we need based on the traffic or load at any given point in time.
The Solutions
There are a few approaches we can use to achieve the goal.
Serverless
As we all know by now, serverless doesn't literally mean there are no servers.
What it actually means is that we won't be dealing with any servers or infrastructure. Instead somebody else (cloud provider) will be dealing with the elasticity and availability of the infrastructure.
This is really a good deal because it means we can spend much more time on our application i.e. actual business instead of the hard topics of infrastructure, scalability, availability etc. and have zero cost when the application is not used.
Some of the options are listed below.
AWS:
- Lamda - Functions
- Fargate - Containers
- SQS - Queues
- SNS - Notifications
- Step Functions - Workflows
- EventBridge - Events
- DynamoDB - Persistence
GCP:
- Cloud Functions - Functions
- Cloud Run - Containers
- Cloud Tasks - Queues
- Cloud Pub/Sub - Notifications
- Eventarc - Events
- Workflows - Workflows
- Firestore - Persistence
Cons Of Serverless
- Mostly proprietary with high vendor coupling
- Costs can skyrocket if proper guardrails are not in place or mistakes are made in the architecture e.g. infinite loops.
Containerized
Another way to achieve infrastructure elasticity is by running containerized applications on orchestration platforms.
This way we write our applications using which ever languages / frameworks we like and leverage auto-scaling features of the platform to achieve elasticity.
Some of the options are listed below.
AWS:
- App Runner - Simple Container Platform
- EKS - Managed Kubernetes
- ECS - Proprietary Orchestration Platform
- Fargate (EKS, ECS) - Serverless Container Orchestration
- Auto-Scaling Groups - Instance (EC2) auto-scaling configuration
GCP:
- Cloud Run - Simple Container Platform
- GKE - Managed Kubernetes and fully automated with autopilot mode
Cons of Container Platforms
- Can get highly complex depending on the choice
Conclusion
Infrastructure elasticity using serverless and container platforms is, IMHO, relevant and can be used at any scale. If you are not utilizing them, you are most likely missing out.