Public cloud computing offers the tantalising promise of elastic computing, but few IT practitioners know what it means, let alone how to make it work for them.
My job is to know this stuff, the new and cutting edge of IT. I need to know it to educate my clients, but also because I get paid to write about it. I have worked with public cloud computing for years, yet I still run my own workloads on fairly archaic designs.
The goal for this article was to take a workload I actually care about and can't allow to fail and move it from my old-school design to an elastic compute model.
Feel the elasticity
It was time to put my theoretical knowledge to practical use. I originally pitched this article to my editor as "how to create an elastic computing setup on Microsoft's Azure”.
After having actually lit up elastic workloads, I have come to realise that is not the article that needs to be written.
As it turns out, making a workload elastic on Azure is so push-button simple that devoting an article to the topic borders on insulting the intelligence of the readership.
Making a workload elastic and having that workload do something you actually want it to when the triggers are met are two completely different things.
A functioning web application needs two things: storage and compute. Storage usually comes in two forms: file storage and database storage. Compute is the web server and its associated security and network settings.
In a modern web application, files don't usually change dynamically. They are the web application in a very real way, and changes to those files should occur only with the blessing of the developers – hopefully with some care and attention paid to quality assurance.
The database is where all the data is stored – user information, configurations, content for the site, you name it.
The database must be kept consistent. Every user accessing the web application must access the same information in the database. Files, on the other hand – which are typically about how you access the database, the user interface and so forth – can usually handle a fair amount of drift between compute instances before there is a real problem.
Light the LAMP
In a traditional web server – the kind I have been running most of my sites on for years – all these of these roles are installed in the same virtual machine. I use a classic LAMP setup: Linux, Apache, MariaDB and PHP.
Put the virtual machine on an SSD and it can handle tens of thousands of simultaneous users without problem. Using Virtualmin, I can run hundreds of websites on a single server. This is perfectly adequate for most small businesses.
To make a bare-basic "elastic", I need to at a minimum split this into two virtual machines in two tiers: database and application. A minimum setup would be one database virtual machine and one application virtual machine, where the application virtual machine could be grown or multiplied when it starts to look like it is experiencing stress.
As a sysadmin who owns and controls every last element down to the ground, I start by simply cloning my existing virtual machine so that there are two copies. The application virtual machine retains a copy of the file storage (the scripts that make up the web application) inside the virtual machine itself but it doesn't need a copy of the database, so I delete that and remove the MariaDB server on that node.
The application virtual machine will connect to the MariaDB database on the database server using the internal network. Azure puts all virtual machines behind a firewall and assigns them internal IPs only by default, so this is as simple as going into my scripts and changing the database target from "127.0.0.1" to the internal Azure DNS name of the virtual machine I will use to host my database.
Seems good. I have two tiers. If I were to set up the application layer to simply spawn more instances whenever load got high, I'd be good. Yes?
Not so much.
You see, I had inadvertently chosen the most complicated possible way to go about creating a scalable website. To do what I wanted to do, I would have to create at least two cloud services, one for each tier.
Services which are meant to be scalable (for example, the application layer) would have to consist of a minimum of two identical virtual machines that Azure could turn on as resources were needed.
Now that's a problem, because suddenly I have to worry about making sure that my application layer virtual machines have access to up-to-date file storage when they are started, but they are off until they are called.
So now I need at least three tiers: database, file storage and application. I could trust in Microsoft to provide storage by linking to a storage resource, but then again I could also do away with my database tier in the same way, assuming I am willing to move from MariaDB to Microsoft SQL.
If I want to control all aspects of my application then I need to set up a virtual machine (or cluster of virtual machines) that will handle my storage and put them in their own cloud service. I haven't even begun to figure out bursting of those virtual machines and how they would handle repopulation, so chances are my file storage tier wouldn't be elastic.
My application virtual machines would then get their storage over the network from the file storage cluster and they themselves would be a cluster of burstable virtual machines. My database (or cluster of database virtual machines) will have to be another cloud service, possibly two tiers, as I probably want to have a central master and a tier of elastic slaves.
I would then need to toss a load balancer in front of the application layer, and probably a CDN (both consumable as services in Azure). Tweak all the settings, test, load balance, test some more. At this point I would finally have a working fully scalable website consisting of a gaggle of virtual machines with components scattered across the world that should be scalable and bulletproof.
All of which is great if I am designing for millions of visitors a month and am willing to pay the roughly thousand dollars a month my design would cost. For that money I could buy a really great server cluster, toss it in a colo facility and run thousands of websites, each handling SMB levels of traffic (say 10,000 users).
This cloud thing is not looking so hot, so where did I go so wrong?
Press the button
My problem was that I kept thinking like an ops guy. I ignored the button labelled "website" and went straight to making virtual machines.
I have a whole environment – Virtualmin – that I am comfortable with for hosting my websites. It handles DNS, web services, databases, email, spam filtering, and gives me full control of the underlying operating system, all from one user interface. It is a nerd's happy place.
I am so comfortable with the idea of "owning" the infrastructure – of being able to control everything from patches to editing the config files by hand – that when presented with the various options in Azure I did not even consider simply letting Microsoft control everything.
When I stepped back and realised that my approach – where I control everything down the ground by using virtual machines – was expensive and more than a little unwieldy, I forced myself to use the website button.
Compared with weeks of fighting to design my undefeatable website, creating a scalable WordPress site was depressingly easy. You can even create this site and put it on the "free" tier. You don't have to pay for it.
That rhythmic sound you hear is the repeated thudding of my head against my desk.
Now, the official method is letting Microsoft put your website on IIS and use SQL as a database. But you can use MySQL too; you just have to choose custom. Or you can just choose website then add a web app, and instead of feeding it a WordPress install you can just choose WordPress as an app. Because cloud.
I have created fully elastic applications using the "spam many virtual machines" method before because there was good reason to do so and we were essentially using Azure as a form of hosted infrastructure, but that is the wrong way of thinking about Azure. To make use of the public cloud you need to stop thinking about the infrastructure and start thinking about the services.
I use Virtualmin to get all the cloudy provisioning goodness of creating those websites one at a time, but all shared on a virtual machine I control down to the ground. I made a capital investment up front in the form of a server purchase and the time investment required for configuring my environment.
I could see far ahead when I might run up against the capacity or performance limits of my hardware. Once set up, it was massively over provisioned, and adding additional websites cost me nothing.
Most critically, I know exactly what my costs will be from one month to the next because they consist of colocation and saving for the next server refresh. Backups are a matter of copying out the virtual machine periodically, doing regular pushes of the files to cloud storage every night.
I run the database in master-slave with a second virtual machine that I just popped in my local cloud provider, CloudA, and do nightly backups.
The worst-case scenario is that my host goes down. I could take a monthly virtual machine backup and light it up on any x86 computer I have lying around, or a cloud service. I then inject the files from the latest backups and can be back up and running in minutes.
I find the predictability comforting. I know how this all works and I can personally control every element.
My initial approach was to attempt to replicate that environment in Azure. That's not how Azure is designed.
In Azure you just trust Microsoft. If you want to set up 50 websites you create 50 websites within the UI. You don't create a virtual machine filled with 50 websites.
If you want email then you light up Office 365 and you pay per user per month. You don't host 1,000 users off the same system that runs the websites and let Virtualmin handle DNS, user creation and so forth.
In my world, everything is deeply intertwined because it has to be to be efficient. In the world of Azure, everything is separate and distinct. Each service has firm borders. Those borders are carefully guarded.
Rationally, it is probably the saner, more security-conscious approach to everything, but a lifetime of working to get as much IT as possible for as little money as possible instils thought patterns that are hard to override.
By simply handing over control of everything to Microsoft we are deep into territory that makes me uncomfortable. I am paranoid about being able to move my workloads quickly and easily from one service provider to another.
Asking me to take every website, email, DNS and so forth that I run and putting them one at a time into Azure is like asking someone allergic to bees to start juggling beehives without protective gear.
Azure is simple. It is so simple it is actually hard to understand for someone used to old-school IT. If you haven't lit services up on it then go there right now, sign up for Azure and create a fully elastic website.
There is no substitute for hands-on experience when it comes to learning what the public cloud is like. Unless you are already hardcore into DevOps or containers, it will change your entire professional outlook on how IT should be provisioned.
Leap of faith
None of this is to say that I can't have both ease of use and freedom of choice. It means I need to learn different tools to accomplish the task. DevOps tools like Puppet can wrangle clouds, as can scripting languages like PowerShell.
I need to redesign my applications, my entire user infrastructure, how I handle emails, DNS and pretty much everything else, but I can then make everything into little automatable containers that are provider agnostic.
Websites could be injected into AWS, Azure, Docker containers, you name it. Email and user setups would be independent LDAP entities and need a lot more scripting to move than copying off the homefolders, but it is doable.
Once that jump is made, however, there is a whole world of possibility open to me. Cloud infrastructure is scriptable and dynamic. It is not "just virtualisation with some automation", it is a whole new approach. Packaged and separate services; one website at a time, not a virtual web server that handles hundreds.
There is an appeal here, especially for those who didn't know IT in the pre-cloud era. If we want to adapt to this new world, we need to re-learn not only how this computer stuff works but how to think.
Ultimately, the next generation won't consume their IT any other way. Managers and less technical people won't stand for anything different.
Like it or not, the days of the sysadmin's death grip on IT are behind us. The future is services, and that brings with it different models for provider independence, different backup challenges and even different ways of calculating the economics of things.
The public cloud won't be for everyone, but for those who can take the plunge, it sure is easy. ®