Running “on” the cloud or “in” the Cloud: which one are you doing?
Maybe you are neither and trying to weigh up moving your business “to” the cloud. However it stands a good chance if you are already utilising the power of the cloud you are still only “on” it not “in” it.
Now the excessive use of air quotes may already have some of you thinking “what is this guy on about?” so let’s explain the difference. For the purposes of this blog I’m going to focus on one relatively simple space, running a mail server.
On the cloud
I’m going to start with an Amazon EC2 instance, all is going well and I feel accomplished in my use of cloud technology to provision a server in seconds. Next I start to install software in order to turn my vanilla EC2 instance into a fully functioning mail server. I configure the server to meet my requirements and within a relatively short amount of time I’m up and running and able to send email via my new instance — great job.
Then two weeks later I get a notification from AWS telling me that there is some maintenance required and my nice email server is due to be restarted during the busiest part of my day! Okay, no worries, it’s the cloud so I will just stay up the night before and perform the restart myself at a more suitable time. That was annoying but thank god for the cloud, because if that was a server in my old data centre it would have been hours of work.
All is going well again when suddenly I realise no emails are being sent. Some quick investigations show that AWS is reporting a network problem in the availability zone that hosts my instance (it does happen) and I’m without a functioning mail server. That’s right, I deployed to the cloud but didn’t consider that it can still fail so I have no redundancy. D’oh. Not to worry though, I’m becoming quite the EC2 expert and I can build a new server in another zone using an AMI I created from the first one. Now I’m back up and running. PHEW.
I’m now pretty concerned by the amount of support I’m having to do to keep this mail server running, so after that last outage I decide to create and run multiple copies of the mail server, running in different zones for redundancy, with their own specific IP addresses that I can use to improve the confidence in email delivery. I go back to feeling satisfied with my latest and greatest deployment. Running 3 mail servers in different zones for full redundancy wasn’t something I could of dreamed of in my own data centre. Hurrah for the Cloud!
Then I arrive to work one morning to find a CVE (Common Vulnerabilities & Exposures notice) for my mail software. It’s now vulnerable to attack allowing a person to bypass security and snoop on my emails. Quick, let’s follow the guidance and begin applying patches to the multiple mail servers that I now have deployed.
Are you seeing a pattern here? Deploying “on” the Cloud does offer you speed and flexibility but it doesn’t take away all the support you had to stay on top of when in your own data centre.
In the cloud
I select the SES service (Amazon’s Simple Email Service), configure my domain and follow the instructions for configuring SPF and DKIM etc. I pick a few dedicated IP addresses and I’m done. I now have a mail service that is truly “in” the cloud, I no longer have to maintain the servers to run it. I have all the multi zone redundancy of the manual solution in just few minutes of config.
I also gain a handful of features that I wouldn’t have even dreamt as possible whilst running my own instances, such as all mail events including delivery and bounce notifications being funnelled into S3 via Kinesis for later analysis using Athena.
This is the life! I have everything I ever wanted from my mail service and none of the stress of keeping it running for just a couple of $ per month.
Conclusion
Now some of you out there will say that SES could fail too and you would be right. The difference is that using a service “in” the cloud means the cloud provider is the one responsible for restoring it. If I build “on” the cloud then all that is restored are the basic services I’m using such as EC2 and not the mail services themselves. Combined with the failover, security and patch management all being handled by the cloud provider… why would I want to build this myself? Perhaps using a mail provider seems like an obvious choice today, and I would imagine very few people still deploy mail servers themselves, but it’s a nice example to illustrate.
If you go back to your own use of the cloud, can you spot where you are just running “on” the cloud vs “in” the cloud? For example:
MySQL on EC2 = On the Cloud
MySQL on RDS = In the Cloud
Java on EC2 = On the Cloud
Java on Lambda = In the Cloud
The point of the cloud is to reduce the cost and complexity of what an engineer is responsible for. It’s there to make your life easier, it’s not just an exercise in building exactly what you would build in your own data centre but in a cloud provider’s data centre.
Utilise everything the cloud offers you, so you can get on with solving problems that adds value to your business and your customers experiences.
