In my last post, I started to talk about cloud computing platforms and services. One of the things I alluded to was the fact that it made it easier to deploy your applications and not have to manage any equipment like servers.
While this is true, there are also other areas of cloud computing services that actually require more work of a different type, at least if you want to follow best practices or deploy your programs at scale.
If you use a service like AWS, you’ll be able to login to their platform and start deploying new services, like servers and databases. These can be done with the click of a few buttons by simply selecting the configuration you might want. But, what happens when you start to launch dozens of services? How do you keep track of what’s needed for what app? What if you ever need to redeploy your services, maybe in a different region or account. Would you remember everything needed and how to set it up again? How do you communicate with other developers on your team what services are being used for a specific application? This is where cloud services start to become a little tricky and you might need to learn something new.
The answer to the above question is basically, you need some sort of plan to represent all the architecture and services you have deployed or need. This is where Infrastructure as Code comes in. You can read more about this concept here: https://docs.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code
Infrastructure as Code means that we should be able to define our services the same way we do our application logic – with source code. Often this code is written in JSON or YAML and there are different services to setup this infrastructure based on your code – both 3rd party and native to cloud computing services. Some examples are Terraform, which can provision services with many providers, and Cloudformation, which is AWS specific.
With infrastructure as code, your infrastructure is written and stored in your source control. There is a source of truth that you can reference to see all the services you might need. In order to change something, you would go through the same process you do with code changes. This ensures you have a record of your configurations and prevents crucial services from being accidentally changed.
The other part you need to think about with cloud infrastructure is how your code is deployed. With serverless functions for example, this is pretty important. With AWS Lambda Functions you can actually view and edit your code in the browser. But again the question becomes, how does this work with source control? Where is the source of truth for your application? Do you expect developers to copy and paste code into the console interface?
This is where you would need to setup additional deployment workflows. Ideally you setup a CI/CD pipeline with something like GitHub Actions or Buildkite and then you can use something like the AWS CLI to deploy your code or files. The AWS CLI has access to the different AWS service and could help you do anything from deploying your code to a function or uploading a file to file storage. This is how you would want to make sure your application gets updated.
Hopefully this provides a good overview of another area of cloud computing and some considerations you might need to take when deploying to the cloud.
