There are hundreds of cloud services. AWS alone has over 200. Trying to memorize them all is a lost cause. The key is to identify the architectural patterns that repeat across providers.
Recurring patterns
- Object storage: S3 (AWS), Blob Storage (Azure), Cloud Object Storage (IBM).
- Managed databases: RDS, Azure SQL, IBM Db2 on Cloud.
- Serverless functions: Lambda, Azure Functions, IBM Cloud Functions.
- Containers: ECS/EKS, AKS, IKS.
- Messaging: SQS/SNS, Service Bus, Event Streams.
Simplified comparison
| Pattern | AWS | Azure | IBM Cloud |
|---|---|---|---|
| Compute | EC2, Lambda | VMs, Functions | VPC, Functions |
| Object Storage | S3 | Blob Storage | Cloud Object Storage |
| Kubernetes | EKS | AKS | IKS |
| Relational DB | RDS | Azure SQL | Db2 on Cloud |
| Messaging | SQS/SNS | Service Bus | Event Streams |
The important thing isn't the tool, it's the pattern
When you learn that object storage is for immutable files at scale, you can apply that knowledge on any cloud. When you understand that serverless functions are good for events and bad for long processes, it doesn't matter if it's Lambda or Azure Functions.
Multi-cloud decisions
The real multi-cloud question isn't "which cloud is better?" but rather:
- What does my team already know?
- What regulatory restrictions do I have?
- What services does this provider have that the other doesn't?
- What's my exit strategy if I want to change?
A good cloud architect doesn't memorize services: they understand patterns and know how to apply them regardless of the provider.
