VMs Create a Lot of DevOps Work
You can implement your backend using raw VMs, or use higher-level abstractions like serverless. If you choose the former, you’re talking on a lot of DevOps work:
• VM instance types are bound to a specific hardware version. One company I work with is running m4 instances from years ago, paying more to run on older hardware with lower performance. We need to manually migrate to newer hardware. On the other hand, with serverless platforms like Lambda, you specify a minimum set of requirements, like 10 GB memory and 6 vCPUs. You don’t specify the hardware generation like m4 or m5. This way, your code can automatically benefit from newer hardware generations.
• Updating the instance type may also require you to update your AMI, since older ones don’t support new instance types. So a hardware upgrade drags along a software update. And even if you don’t upgrade your hardware, AMIs reach end of life after a few years, requiring you to upgrade your VM image, anyway. On the other hand, with serverless, you don’t worry about upgrading the underlying OS.
• You need to select a Linux distribution. The aforementioned company is using an outdated one. Should we move to Amazon Linux 2, which is optimised for AWS? It’s supported till 2023. Or should we use Red Hat Enterprise Linux 8.4, which is supported till 2025? This isn’t a decision I should have to make, and I don’t, with serverless.
• You need to periodically reboot your VMs to apply security patches. I’ve seen VMs run continuously for more than 4 years1, which is risky, like not updating your laptop ever. Serverless eliminates this risk.
• You need to manually apply non-security updates by SSHing in to each VM, running sudo yum update and rebooting. Otherwise, you’re running old versions of all the software included in the OS. Serverless eliminates this chore.
• You need to upgrade your EBS volumes from the older gp2 to gp3 for better performance at lower cost. Serverless eliminates this chore.
• You should manually set up autoscaling, while serverless platforms have autoscaling built in.
• An EC2 instance runs in only one availability zone, while serverless platforms automatically migrate your app to another zone when one fails, so you automatically have a certain degree of fault tolerance.
• EC2 instances by default store logs on their local disk, which means you don’t have a centralised view of logs in order to generate dashboards, identify frequently occurring Java exceptions to fix, set up alerts and spot security incursions. Serverless platforms centralise logs automatically.
• EC2 instances are generally long-running and can run out of disk space unless you take care of it, while serverless instances are generally shorter-lived and ephemeral.
• EC2 instances require you to figure out a mapping of microservices to VMs, while serverless platforms abstract this away, letting you deal with each microservice at a logical level, forgetting the physical VMs.
• VMs require you to install the CloudWatch agent to gather important monitoring data like memory utilisation, while serverless platforms automatically collect relevant monitoring data.
• VMs require you to figure out a deployment tool and process to distribute code updates, while serverless platforms have deployment built-in.
For all these reasons, think twice before you choose raw VMs for your backend. You want to focus on generating business value, not reinventing the wheel.
Which is a testament to AWS engineering.