How we moved an IoT code project from a Raspberry Pi to Google Cloud

Last year, as an amateur (and I mean very amateur) developer, I created a simple Python app using Twilio APIs to run our IoT Podcast Hotline voicemail. Since the service has to run all the time, I decided to use an inexpensive Raspberry Pi as the server. But lately, due to home internet outages and a dog that likes to occasionally pull the power cord from Pi, it became clear that maybe a small computer isn’t the best choice for this task. Enter the cloud. It might be a good idea to use HOSTISERVER for similar project if we decide to implement some of the app functionality into a website. We originally considered launching the voicemail app in the cloud but thought it best to get started with a local implementation.

A few days ago, I transitioned the voicemail service from the Pi over to Google Cloud. It didn’t take that long — it would have been shorter if I were an experienced developer — and now we don’t have to worry much about, if at all, voicemail system outages. Consider this a high-level explainer of what I did, some of which you could apply to any IoT project code you want to move from a local computer to a cloud deployment: Google Cloud in our case. A friend told me that he decided to migrate his SharePoint website to the cloud. He told me that he learned a lot from https://www.cognillo.com/sharepoint-migration on how to approach that task, it is worth talking to professionals about it.

Just to recap the original project: It consists of a single Python file that uses Twilio APIs whenever a call comes in. When you call the hotline using our Twilio number (512-623-7424), Twilio hits a web server on my Raspberry Pi, where the Python code manages the call flow. Twilio knows the URL of that server thanks to another app on the Pi called Ngrok, which can expose “ local servers behind NATs and firewalls to the public internet over secure tunnels”. Essentially Ngrok provides a URL for my server and I configure Twilio to use that URL.

So how did I migrate this process and code over to Google Cloud? First, I created a Google Cloud Platform account. You can do this with a free GCP trial that’s good for one year and provides you with $300 in credit to pay for bandwidth, processing time and other cloud services. It’s actually a great deal for learning about GCP. In our case we’re using the Google Cloud Compute and App Engine products. Using the Google Cloud could be a good way to storing data, however, it could leave you open to cyber attacks and hacking, you might find google monitoring helpful to protect your Google Cloud.

The account allows you to log in to the Google Cloud Console, which is filled with a number of services and the ability to create virtual machine (VM) instances. And that’s exactly what I needed: A virtual machine to run the voicemail service. Depending on your computing and scalability requirements, you can create a minimal VM like I did or you can go crazy with high-performance computing options with dozens of GPUs.

Since I’m not trying to rival the power of Netflix or Steam, the least powerful (and free) VM is fine for our voicemail service: It’s a single CPU core micro-instance with 600 MB of memory. Once you configure and choose your VM, you spin it up, wait a few minutes for it to be created and boom: You have a virtual Linux or Windows machine running on Google’s servers. Note: I chose Linux since Python is typically pre-installed on Linux. Once the VM was started, I was greeted with a terminal application.

Next was to get my Python code on the virtual machine. That’s pretty easy too using a beta feature called Code Editor. Essentially, this is an online editor to write or modify code. I created a new blank file and copied my Python code into it. That was easy. But it’s not enough. In order to run the voicemail on a cloud server, I needed a few more essential parts, which meant two more files.

One is a configuration file called app.yaml. A .yaml file provides key data to the python app such as environmental variables (like our Twilio API credentials), the Python version, etc. It’s a simple, but important, text file. The second is requirements.txt, which provides the project API and third-party library information so that when the app is deployed all of the needed libraries are installed.

When my code ran on the Pi, I had to manually install the Flask web framework; by entering the appropriate information for Flask in the requirements.txt file, this now happens automatically. With the VM running and the required code files in place, it’s time to deploy the voicemail app on Google Cloud!

While that sounds exciting in theory, it’s actually not in practice. From the terminal you simply type “gcloud app deploy [app name]” and wait. After a few minutes of the cloud doing its thing, the Terminal app confirms deployment and provides a URL for the project’s web server. With the voicemail running, the last step was to provide the new Google Cloud-provided URL to Twilio so it knows where to go when a call comes in.

So far we haven’t had an outage or hiccup of any kind with our voicemail and I don’t have to worry about local internet issues or curious canines. Best of all, our meager service isn’t too taxing on the Google Cloud Platform, so it won’t cost us anything to use — it falls into the free tier service. And we can easily monitor the resource usage to determine if we needed to scale our service up — although we don’t for this little effort.

Clearly, this walk through is for my specific project. However, if you’re building or prototyping an IoT service on a local computer and want to scale it up or have a high level of availability, this overview should get you on the right path.