Engineering Note
DevOps is not becoming serverless. It is becoming more abstract.
A few years ago, deploying a Rails application often meant managing:
EC2 instances.
Nginx.
Load balancers.
OS updates.
Scaling rules.
Then containers became common.
We moved the application into Docker and made environments more consistent.
Now serverless and platform services are taking another step:
Less infrastructure to manage.
More infrastructure handled by the platform.
But this doesn't mean containers or EC2 are disappearing.
Each approach has a trade-off.
Serverless
Less infrastructure management, but more platform constraints and different cost behaviour.
Containers
Good control and portability, but you still own deployment and runtime operations.
Platforms
Faster developer experience, but less control over the underlying infrastructure.
For a Rails SaaS, the right question isn't:
> “Which DevOps trend should we follow?”
It's:
> “How much infrastructure do we actually need to own?”
Early-stage product?
A managed platform may be enough.
Growing SaaS with specific infrastructure needs?
Containers can give you the right balance.
Complex workloads requiring deep control?
More direct infrastructure management may still make sense.
Important learning:
The goal of modern DevOps isn't to remove servers.
It's to remove unnecessary infrastructure work from the engineering team.
The less infrastructure you own, the more important it becomes to understand what the platform owns for you.
EC2 instances.
Nginx.
Load balancers.
OS updates.
Scaling rules.
Then containers became common.
We moved the application into Docker and made environments more consistent.
Now serverless and platform services are taking another step:
Less infrastructure to manage.
More infrastructure handled by the platform.
But this doesn't mean containers or EC2 are disappearing.
Each approach has a trade-off.
Serverless
Less infrastructure management, but more platform constraints and different cost behaviour.
Containers
Good control and portability, but you still own deployment and runtime operations.
Platforms
Faster developer experience, but less control over the underlying infrastructure.
For a Rails SaaS, the right question isn't:
> “Which DevOps trend should we follow?”
It's:
> “How much infrastructure do we actually need to own?”
Early-stage product?
A managed platform may be enough.
Growing SaaS with specific infrastructure needs?
Containers can give you the right balance.
Complex workloads requiring deep control?
More direct infrastructure management may still make sense.
Important learning:
The goal of modern DevOps isn't to remove servers.
It's to remove unnecessary infrastructure work from the engineering team.
The less infrastructure you own, the more important it becomes to understand what the platform owns for you.