Use these scripts to get rapidly familiarized with nine GCP & AWS services.
Google Cloud Platform and Amazon Web Services provide many different infrastructures for running a web app. However, it can be intimidating to give new services a try. When getting familiar with a new service, initially you might want to spin up a minimal instance from the command line.
In this post, you’ll see how to get rapidly acquainted with nine Google Cloud and AWS services using “Quickstarts” I’ve created. A Quickstart in this case is a low-level script that gets you to the “Hello World!” stage for the service it corresponds to, while also helping you understand the underlying processes that got you to that point.
These Quickstarts make it easy to get past the first, intimidating stage, where you may understand little or nothing of the technology, and on to the comfortable milestone where you can say, “It works!” After that, you can incrementally add more functionalities that you want to explore.
Quickstart design principles
Every Quickstart is built with the same principles in mind. They’re all automated, minimal, and complete.
The GUI is good for an initial poke-around, but scripts are better for the “Hello, World!” stage, so you can repeatedly deploy the same service while you tweak and add features.
“Hello, World!” scripts are minimal: The least code needed for getting the HTTP response.
GCP uses the term “Quickstart” for a tutorial on the fastest path to getting a specific technology to run. My repository simplifies it by focusing on the executable scripts, which are generally even simpler than what we find in such articles.
In AWS, a Quick Start is a CloudFormation template to get a specific technology running. That’s useful, but I created shell scripts as this helps in understanding the lower-level commands, which is important as one later goes on to build a full system.
I like to think of this as a quicker Quickstart.
The scripts deploy everything needed including IAM roles, clusters, etc. The only prerequisites are command-line tools and authentication to a cloud account. With that in place, the goal is to launch everything that is needed. Then, if something goes wrong, you can start from scratch without figuring how to get each component into a stable state.
Preferably, the scripts are re-runnable, allowing you to deploy new code on top of a previous deployment. Some of the scripts here are, but some aren’t, where adding that capability would add too much code. For these, the old instance before re-deploying; or launch each new version with a new name. (But watch out for costs! Delete the old instances as soon as possible.)
The README for each directory describes the prerequisites. These include
gcloud, authenticated (with
- The AWS CLI tool with credentials.
- A plugin to the AWS CLI tool for Lightsail
- The Elastic Beanstalk
ecs-clitool for ECS, but the script installs that for you.
- For processing command output, some require
envsubst(install it with the
The supported infrastructures
Here are the scripts that I created for:
- AWS Elastic Beanstalk
- AWS Lambda
- Amazon Elastic Container Service
- Amazon Lightsail
- Google App Engine Standard Environment
- Google App Engine Flexible Environment
- GCP Cloud Functions
- GCP Cloud Run
- Google Kubernetes Engine
The git repository has
deploy.sh scripts for each infrastructure technology, in the subdirectories. If you are feeling adventurous, you can run them all from
run_all.sh in the root directory.
If you find this useful and want to see more, please submit a pull request with your script, or an issue asking for your favorite.
Elastic Kubernetes Service would be a good next step, and then EC2 and Google Compute Engine and other cloud providers’ offerings.
Differences in simplicity
Infrastructure technologies differ in simplicity and flexibility.
In the App Engine Standard Environment and Cloud Functions, the script is just a single
deploycommand, followed by access to a known URL. For others, there is more complexity. For example, Cloud Run and ECS require building and pushing a container, while Lambda needs an IAM role as well.
Once these differences are not significant. Once “Hello, World!” is running, these scripts help automate away the complexity.
For an explanation of the steps to “Hello, World!” see the Quickstart or “Getting Started” articles linked in each README.