Where was the Cloud when I was Younger?

John Ferlito, Chief Technical Officer, Bulletproof

John Ferlito, Chief Technical Officer, Bulletproof

As the CTO of a large and rapidly growing business, it is becoming rarer and rarer that I am able to get my hands dirty, well at least on weekdays. Over the years I have been involved in a number of start-ups - two to three man bands where everything is everyone’s responsibility, from architecture design and building the infrastructure to cutting the code. Ten years ago there was a great deal of work involved in creating a start-up and getting product out the door was measured in months.

Cloud has fundamentally changed the way in which we build products to service our customers. Delivering new features or products to customers can now be measured in weeks and sometimes days. The functionality now offered by the leading cloud providers can dramatically reduce the effort required to get off the ground and start running towards the first drops of revenue.

There are a number of players in the cloud eco-system, however when it comes to truly leveraging the benefits and scale of cloud it is really a two horse race between Amazon Web Services (AWS) and Microsoft Azure, with AWS holding a dominant lead in pure breadth and depth of offerings.

One of the fundamental ways that cloud accelerates delivery to market is through the numerous Platform as a Service (PaaS) offerings that are available. Let’s take AWS Relational Database Service (RDS) for example. Traditionally when deploying database services, there are a number of steps that need to be considered. Firstly, hardware needed to be procured, perhaps in your own data center or possibly via a co-location provider. Next an operating system, usually Linux or Windows would be installed. Finally, the relevant database software would need to be installed and configured.

At this stage, some would consider the project complete, as the application is now able to connect to the database.

However, there are a number of items that are yet to be considered:

· Is the solution highly available?

· How, where and when will the data be backed up?

· How will upgrades be handled?

· Is the system availability and performance of the system being monitored?

In the early days of most start-ups, these items sit at the bottom of the back log and usually only rear their heads when there is a related production outage. With Amazon RDS all these aspects are taken care of. With a single API call to AWS I can specify:

· That an instance should be created

· It should be backed up every day

· These backups should be kept for 30 days

· The instance should be highly available across 3 Data Centres

· It should automatically be upgraded every Monday at 8am to the latest version

With a couple of extra API calls I can even make sure that I am alerted via email and SMS if monitoring metrics reach certain thresholds. Amazon takes care of all of these mundane tasks for me, allowing me to concentrate on the real business value that I want to deliver to my customers.

"With everything in the cloud being API driven it means that all environments are reproducible with a couple of clicks"

Another good example of how things have changed is the emergence of server less infrastructure. Let’s take a simple example that almost every web application needs to deal with, profile photos. In a typical architecture we would set up a web server. It would display a web page to the user, where they would upload an image. After receiving the image, the web server normally creates a number of extra images of different sizes for use in web and mobile applications where appropriate. This web server needs to be running Rx whether images are being uploaded or not.

Utilizing some key features of Amazon’s cloud allows us to take a different approach. The web page that is used to upload the image, could be stored in Amazon S?O, an object store which can be accessed via HTTP. This web page can be generated in such a way that when the user uploads the image, the image is uploaded directly to S?O for storage. S?O can then be configured to send a notification to AWS Lambda. Lambda allows you to upload a piece of code to Amazon that only runs if an event occurs, you are only charged when the code is running. In this particular case the code could fetch the uploaded image and create the different sizes, again storing them back in S?O. Once complete it could update a database in RDS to show the images as having been generated. All these images can now be served to the user directly from S?O or perhaps even using Amazon’s CD, Cloud Front.

In this example, there is no server running, costs were only incurred when uploads are taking place to store the images and when they are served to the users via HTTP. The potential cost savings here are significant, as well as the operational benefits of having one cluster of servers to manage.

These are just a few simple examples of how cloud can be leveraged to accelerate product development and projects. Having these types of technology at our fingertips means that as a CTO I can now place much more focus on solving a problem for my customers and much less on the operational concerns of running the platform. Above all that with everything in the cloud being API driven it means that all environments are reproducible with a couple of clicks. This allows us to now focus on innovation rather than the mundane

Sometimes I wonder what I would have been able to achieve a number of years ago if I had today’s technology at my fingertips…