Moving your workloads to the cloud can bring a lot of benefits, but creating a design document should be done way before you begin spinning up virtual machines in Amazon or Azure. You need a plan, otherwise you end up creating a solution that may not match the problem you’re trying to solve. But what does a cloud design look like? Here’s my take on it with a simple template you can reuse any time you want to move an application or workflow process to the cloud.
The first step is to define your objectives. This shouldn’t be an in-depth technical discussion, instead it should be a high level overview of a paragraph or so, describing what the design aims to accomplish. For example, maybe you’re trying to cut costs by having your workload in the cloud rather than on-premise. Maybe you experienced some reliability or scalability issues and you want to take advantage of the cloud’s natural advantages when it comes to robust infrastructure. Or maybe you want to scale your workload worldwide, and it makes a lot more sense to utilize the existing Amazon datacenters rather than opening your own offices in diverse locations.
Before thinking about the way your process will work once in the cloud, it’s important to fully understand how things work right now. It’s easy to make a costly mistake here by taking an individual process in isolation, without thinking of everything else that process relies on. For example, let’s say you have a web app hosted in your own datacenter and you want to move it to AWS so you can scale it up. However, that web app relies on a large amount of data that lives on physical disks in your datacenter. Will that data also be moved to the cloud? How long will the transfer take? How much will this impact costs? Can you keep the data locally and have the cloud app fetch the data through a VPN link, or will latency be an issue? These are all considerations to take into account.
By making a diagram of your existing processes, you can also come up with a checklist of requirements that you need to meet before the migration can start. The last thing you want is to transfer a piece of code to the cloud and then find out that it won’t run because of a missing requirement. Both the business side and your technical staff should be involved in crafting this part of the design, making sure to involve every stakeholder so there’s no surprise down the line.
Once you know what your existing process looks like, you can design your cloud workflow. This typically involves creating a cloud diagram showing how each piece of the puzzle will work together. This is where having an experienced freelancer help you can be very useful. The cloud tends to prefer specific types of workflows, and depending on your needs it may end up being less costly to adjust how you do things so it can be migrated more easily. For example, if you’re migrating a web app that only requires minimal CPU resources, instead relying on a large amount of data, you could migrate everything as-is on a series on EC2 instances and EBS volumes, however it may end up being far cheaper in the long run if you can re-engineer it to run as a serverless application using Lambda functions, and move your data to S3 buckets, which cost a lot less than traditional disk storage.
There’s an important balance between keeping things that work and changing processes so they cost less or operate more efficiently in the future. Your design should take all of the options into consideration and you should come up with the best solution for your time and budgeting constraints. This is also where security must be taken into account, especially since your data may be residing in the cloud. Between network ACLs, security groups, application firewalls and more, it’s important to fully map out what security will look like and how access will be controlled.
Timelines and costs
Once your workflow is decided, it’s important to lay down a timeline with well defined steps. If you’re using an Agile methodology, you want a series of sprints that will accomplish noticeable improvements, without putting too much pressure on your existing staff. You also need to have a good breakdown of the costs, both for the migration itself and for the resulting environment. This is where things like the Amazon Cost Explorer can come in handy.
There are many advantages in moving to the cloud, but having a good design document prepared beforehand will help you tremendously in avoiding common pitfalls and cost overruns.