I’ve spent quite a lot of the last few working day trying to sort out an inherited EC2 server.
Someone decided a few years ago, to build a website with Wordpress and a bunch of plugins and other things like forums, on top of a big EC2 instance.
This EC2 instance is not only the webserver but also the MariaDB database server. Because the person that set it up had either never heard of RDS or hadn’t got a clue what they were doing and were blindly following a server based setup of Wordpress et al (they were probably a designer…).
After years of not upgrading the various components and years of neglect, the site eventually reached me.
The original team told me that it was all “in the cloud”, handed over a bunch of limited docs, and I (after some due dilligence) believed them.
It’s a single EC2 monolith that could blow itself up at any minute.
The first thing I did last year was try back it up. This proved problematic and broke the build, because the team had used iptables in some way that wasn’t retained after an instance restart.
Even more pain. I think I’ve fixed it, but it scares me.
And now I’m trying to backup the database, but I can’t turn the website off to do this (because I’m paranoid about it breaking for the above reason).
Oh and thousands of people use this site everyday.
So, this database has meant logging into the server, and setting up the database server for replication, backing up the database while it’s still running (I did it at a reasonable time for maintenance and by attaching a separate volume to the instance), and then creating a new RDS instance for the database, importing the data and setting it up as a slave.
Yup. I had to do all that, for a system that’s already up and running.
And I had to do that simply to stop the site from having about 14 single points of failure.
And I haven’t even got to scaling and load balancing the front end (which scares me even more).
The vendor runs the database, and the scaled containers and the file storage, and helps with the backups and the infrastructure management and…
You get the picture.
I have hardly had to ssh to somewhere on AWS in two years. The system I manage has scaled, it has managed bursty loads, it has changed and grown with relative ease, and all because it was thought through.
Imagine never having to ssh into an instance?
That’s what serverless is.
If I inherited a serverless system? I’d not have to touch it, or worry about it to anything like the level I am with this system. In fact, maintaining it is minimal at best. It might take a bit of getting your head around, but it’s not going to blow up at midnight in the same way, or fail in the same way.
Now, you might say that the team could have done a better job of building it in the first place.
And you’d be right.
But the thing is, that there is no standard way of building stuff in the cloud. If you’re not experienced at it, you build rubbish, and develop an unhealthy overreliance on the “cloud” because it’s the “cloud”.
There are many sites on the internet that are exactly like the one described. They are badly put together and badly managed, and fixing them is a lot harder than one might think.
And that is my point.
Maintaining stuff and fixing stuff is hard.
Serverless for me is all about limiting maintenance and getting maximum benefit.
Just the very act of ssh-ing into a server is now strange to me.
And I know what I’m doing (most of the time).