‘Cloud Migration’ is a phrase that can scare even the bravest of today’s businesses, but it doesn’t have to be quite so scary. Last year, Davies successfully migrated all its applications from a conventional data centre into AWS (Amazon Web Services) and here we share some of the useful things that we learnt along the way. A quick disclaimer before we begin: this isn’t a step-by-step guide to creating a cloud migration plan, but rather a few useful pointers that we’re glad we considered when deciding how to make that daunting move into the cloud. 

Learn the environment 

Cloud infrastructure shares many traits with conventional data centres in the services it provides, but beyond the high-level concepts, it can approach things in a very different way. Start by learning about the offerings from the cloud provider, and how it is recommended that they are all plumbed in together. AWS for example provides a Well Architected Framework which shares their best practices. Spend time trying to learn to think in a ‘cloud native’ way and then adapt this to fit your existing workload, rather than trying to copy your existing set-up into the cloud. One of the main advantages about cloud infrastructure is having the ability to utilise managed services. Copying existing infrastructure and patterns is a sure-fire way to negate this benefit. 

Build for failure 

This is closely linked to the previous point but is important enough to warrant its own section. The cloud gives you great tools to scale for both performance and resilience. You can spin up multiple servers, load balanced across various data centres around the world, right from your desk! Without too much extra configuration, Davies is running a highly resilient system such that when any server that fails it is immediately terminated and a new replacement rebuilt from scratch without any application downtime. Using this approach from the beginning and treating every server as disposable, eliminates a huge amount of risk. 

Work out what you want to do yourself 

As mentioned above, cloud platforms allow you to make use of many managed services, where the maintenance and management is offloaded and hidden from you. We have used these services wherever possible, leaving maintenance and day-to-day tasks to AWS, allowing us to concentrate on bigger and better things. 

This won’t always work though. If your requirements are more complex, then you may be missing some functionality that is hidden by the managed process. Finding this out early is key in ensuring you don’t waste time deploying a managed service, only to realise later that you can’t use it. 

Use infrastructure as code 

Getting a bit more technical now, but Infrastructure as Code (IaC) allows you to make reusable templates that describe everything about your cloud environment, from what servers are running, to which firewall rules are active and which domain names you own. This might seem like a bit of a nightmare (creating a new server in IaC will take about 10 times as long as clicking the button in the web console) but trust us, it is worth it: 

• Replication – you can deploy this server as many times as you want, in exactly the same state each time. 
• Change Management – by using a version control system on your templates you can very easily implement a change management process around infrastructure 
• Disaster Recovery – rogue employee decides to delete all your assets? Hopefully not, but if you use IaC then you can just spin them all up again in minutes using the templates. 

Automate, Automate, Automate! 

During a recent interview, our lead Cloud Infrastructure Engineer said that he loved developing in the cloud because “everything is an API”. At the time the true impact of this didn’t hit me, but it is a very important concept to understand – everything that can be done in the cloud can be automated. Do you need to email a monthly compliance report from your firewall? Or temporarily create pen test users and whitelist their IP addresses? You get the idea, everything can be automated. 

When Davies migrated our applications into the cloud last year we used these guidelines to inform our decision-making process. The results? We have successfully built a cloud-first, future-proof platform, whilst managing to avoid some of the more common pitfalls with migrating into the cloud. In fact, this approach was so successful, that it is now the foundation of everything we deploy in AWS.