Goodbye Servers Hello Cloud

"A School Lunch Program Without Servers"

Virtualizing the servers at FoodDays was a great step. It meant a school lunch program that had a fantastic uptime however, there's always a 'but' and this one was the aging hardware.

The servers that we used at our datacenter had already clocked nearly 50,000 hours of runtime and, whilst that's not unusual, I would say that nearly every month included at least one heart-in-the-mouth moment where an alert from the the storage array or server control board would stop me in my tracks. Most were benign alerts to let me know that a fan had slowed down a little or that the power had wobbled but some included hard disk failures that necessitated re-configuring the storage array or reinitializing a disk, or, even, a trip to the datacenter to replace a drive.

At this time, in the early 2010's we now had dozens of schools and 10's of thousands of parents on our school lunch program with food vendors depending upon the daily reports to direct their orders. All of this was contained in a few cubic feet of computing hardware. I started to wonder about the what ifs? What if three disks fail together? What if two many power supplies go at one or fans jam? It's all very unlikely but, it's always possible.

We run FoodDays lean and mean, there's not a lot of profit to ensure the best fund-raising experience for the schools so another big investment in hardware seemed a stretch and it wasn't long before I was checking out cloud hosting solutions where I could bake in a small monthly commitment into the running costs of the service.

Amazon Web Services (AWS) ticked all of the boxes and, with a lot of free-for-the-first-year basics, I was able to create a virtual cloud datacenter for the school lunch program.

Since moving to AWS, I've looked at Oracle Cloud, Google Cloud and Microsoft Azure but have yet to see any reason to switch. None offers the breath of services at the price of AWS.

Our journey into cloud thought is far from complete. When we first moved to AWS, we simply re-created the lunch program servers as virtual servers in AWS - it was little more than moving from one virtual server to another, albeit without having to worry about disk failures anymore. However, as time progresses, we're on a journey to serverless, a place where there are no servers to worry about at all, where FoodDays really doesn't have servers.

Tech deep dive:

The choices for cloud hosting in the early part of the 2010's was not broad. Azure was new and already had a track record for stupid mistakes resulting in global failures, Google Cloud was also new and seemed to be limited for now. The obvious choice was the big man in town; Amazon Web Services; AWS.

What is Cloud?

Moving to the cloud works at different levels, some see it as simply moving your physical servers to a datacenter that's managed by someone else - that's not cloud to me. Others see it as moving your applications to servers provided by and managed by someone else - that's not cloud to me either.

So, what do I consider cloud to be? At the very very simplest, it's:

• A virtualized infrastructure that is provided by someone else.
• Where the underlying hardware is unknown to me.
• Where basic services like disk storage and networking is always on and never needs repair.

AWS is actually quite fun to set up - I don't mean a laugh-a-minute, but rather it contains all of the building blocks that an enterprise might want or, that an enthusiastic small-business could use. I remember having company-wide meetings at the firms I've worked for to discuss the purchase of an upgraded firewall! In my virtual datacenter at AWS, I'm able to select from software firewalls and application load-balancers that rival the functionality of blue-chip solutions at will. Also with AWS, you can can provision the simple basics like a DB or PHP stack from a template or, you can construct an isolated three-tier infrastructure with fine-grained control over access permissions and boundaries, right down to the Mac address.

All of this comes at a cost, but the shocker, is how little. Servers are priced at cents/hour, storage is cents/GB, networking firewalls and routers are free. There is one caveat though, the costs, whilst small, can add up and sometimes, mistakes can invoke expensive consequences. I uploaded and then deleted ½ TB of data into S3, the object store, and received a bill for $1,500! Only the good graces of the Amazon accounts team saved me from that. The moral of the story is to keep an eye on costs and, know the potential cost before experimenting! AWS does include a cost monitor that detects unusual spikes and I have that enabled now.

It was reasonably easy to move FoodDays to AWS and I cannot think of any reason to move it again, especially as they continue to innovate and offer more and more options to both improve performance and further reduce costs.

What is Serverless?

Cloud for me, means serverless – Building services without thinking about servers at all. Even with the FoodDays lunch service hosted by AWS, I still had virtual servers running web servers and databases which still means deciding where to place them and how many to run. What if there was a way to have AWS just run FoodDays? Forget servers, database engines and backups, etc.? That is the drive behind server less.

Out first example of serverless was the database engine. Since its inception, I'd run a database server. Even into the AWS hosted environment, I had a virtual server that ran the database. I had to make decisions about how much memory to use, how many CPUs and what disk space I needed. The real goal of serverless is to make even these go away.

In 2018, we made the move to DynamoDB. DynamoDB is a shared serverless NoSQL database-as-a-service. You make no decisions about CPU, disk or memory, you just create tables and connect your application to it. It is also the database that powers Amazon and wow, does it scale! Alex De Brie writes a great deal on DynamoDB including how DynamoDB was forged in the heat of Amazon Prime Day when cottage database engines like Oracle couldn't hack it! His book on DynamoDB illuminates the concepts of SQL versus NoSQL, eventual consistency and even the idea of single-table database design – which as an RDBMS native turned my thinking inside out!

DynamoDB is the first multi-zone solution that we used at FoodDays. We had previously viewed redundancy as storing data redundantly in a storage array across multiple disks with multiple power supplies but what if the data center looses its Internet connection? DynamoDB stores its data across multiple data centers, at least 1KM apart and, can optionally sync to DynamoDB in other regions around the world - that's redundancy. It doesn't protect from idiot mistakes though but includes per-second backup so that I can restore to any second in the last month or any month since 2018.

Our next step was to take the reporting engine serverless. When administrators call for reports from the admin web site, the server would pull those together in real-time which would block the site for the user and slow down the whole system for all the other admins, sometimes for minutes. We took the report generation code and moved it to a Lambda function. These are short lived – fifteen mins max – processes that can be triggered from a number of events. They exist as a single C# function and are uploaded to Lambda for execution on demand. They are single function and simple. Today, when a report is requested, the Admin website drops the request on a queue which triggers AWS to load the function, execute it and drop the results in S3 (object store). The admin web interface no longer does the heavy lifting nor is it limited to one at a time - many admins can request many reports simultaneously, it's up to AWS to find the resources.

In time, we've moved many processes to Lambda and this year, we'll be eliminating the servers used to power our client interface – simplicity and cost. Remember that, despite there being many users on FoodDays they tend to order when convenient to them so, not in the middle of the night, not on holidays and, importantly not in the seconds as they ponder their selections. With Lambda, we pay for the fractions of a second needed to process requests and nothing when the functions aren't running so, for most days, we're paying for a few minutes of compute time, not 24 hours. Now that's really serverless.