Springload has evolved into a mature, highly automated public cloud provider. We have AWS-certified staff skilled at relocating workloads to the cloud, and identifying opportunities for optimising speed and automation.

But how did we get here?

Before starting our journey to the cloud, our infrastructure was hosted virtually everywhere. We were spread over multiple hosting services, virtual private servers, and our own on-site hosts. Running these came with a high maintenance overhead as each was configured uniquely – commonly known as ‘pets’ in the industry. 

We kept some consistency between our hosts through server orchestration and management tools like Puppet. But that was as good as it got. 

This was an inefficient way to manage an increasing number of hosts and services. Monitoring was ad-hoc and we had little oversight over our hosts’ performance. That’s when we knew we had to look at alternatives, and the cloud was becoming a more appealing option everyday.

Our early cloud services were hand built using the AWS console, with Ansible handling configuration management. Even at this stage, we experienced a number of benefits from cloud computing:

• Reliability – we could verifiably demonstrate our uptime.
  
• Auto scaling – our services could cope with traffic spikes.
  
• Redundancy – we survived an AWS outage due to our multi-az configuration (where services are configured to be available in a number of distinct geographical zones).
  

We’d gone some way to reducing reliance on our ‘pets’ by reusing machine images for deployments. But we still had a time-consuming task ahead of us – configuring and building the infrastructure. Not to mention a number of new challenges to overcome:

• Our thinking (and building) was still influenced by conventional server architecture
  
• We had no way of dependably repeating our builds, or tracking changes to the cloud infrastructure
  
• Our initial configurations were not cost effective
  
• AWS account management and billing was complex
  
• Developer tooling was rudimentary and painful.
  

We still had a lot of work to do to fully realise all the benefits of the cloud. Specifically, figuring out challenging issues around easy developer access while keeping accounts and client data secure.

Over the following months we built up our knowledge and practice. We tried out and tested a number of strategies for further automating our work and improving our tooling.

Eventually, we discovered and settled on Terraform, an IAC workflow for the public cloud. It drastically reduced the time it took us to stand up and maintain our infrastructure. We now take a modular approach with an established model for primary deployment. With Terraform up and running, we had more time to spend on:

• Improving our tooling
  
• Improving the developer experience
  
• Optimising our set-up to reduce costs.
  

We’ve come a long way since those first few months exploring AWS. We’ve migrated over 40 applications and services – almost all of our client base. Importantly, we’ve solved the problem of auditing, tracking and building reliable, cost-optimised infrastructure.

Through experimentation, success, and the occasional misstep, we’ve learnt how we’d do things differently.

• It’s important for each client or project to have its own account – this simplifies billing, logging and creates a neat security boundary.
  
• We cannot overstate the value of automation and of IAC – which for us means Terraform.
  
• Observability, metrics, monitoring, and alerting are often overlooked early on, but are important components of a healthy cloud environment.
  
• Cross account roles and permissions are vital for security and easing access for developers.
  
• Docker is a great unit of delivery for cloud-based services – we’ll explore this further in another post.
  
• Automated mechanisms for setting up developer and operations access – both to the console and for command-line interface access are key to delivering efficiency.
  

We’ve put together an experienced, highly skilled infrastructure and DevOps team. So if you’re thinking about moving your workload or infrastructure to AWS or Google Cloud Platform, get in touch.