Time to “Hello, World”: VMs vs. containers vs. PaaS vs. FaaS
Dmytro Melnyk
Serverless Compute Team
Do you want to build applications on Google Cloud Platform (GCP) but have no idea where to start? That was me, just a few months ago, before I joined the Google Cloud compute team. To prepare for my interview, I watched a bunch of GCP Next 2017 talks, to get up to speed with application development on GCP.
And since there is no better way to learn than by doing, I also decided to build a “Hello, World” web application on each of GCP’s compute offerings—Google Compute Engine (VMs), Google Kubernetes Engine (containers), Google App Engine (PaaS), and Google Cloud Functions (FaaS). To make this exercise more fun (and to do it in a single weekend), I timed things and took notes, the results of which I recently wrote up in a lengthy Medium post—check it out if you’re interested in following along and taking the same journey.
So, where do I run my code?
At a high level, though, the question of which compute option to use is... it depends. Generally speaking, it boils down to thinking about the following three criteria:- Level of abstraction (what you want to think about)
- Technical requirements and constraints
- Where your team and organization are going
As a general rule, developers prefer to take advantage of the higher levels of compute abstraction ladder, as it allows us to focus on the application and the problem we are solving, while avoiding undifferentiated work such as server maintenance and capacity planning. With Cloud Functions, all you need to think about is code that runs in response to events (developer's paradise!). But depending on the details of the problem you are trying to solve, technical constraints can pull you down the stack. For example, if you need a very specific kernel, you might be down at the base layer (Compute Engine). (For a good resource on navigating these decision points, check out: Choosing the right compute option in GCP: a decision tree.)
What programming language should I use?
GCP broadly supports the following programming languages: Go, Java, .NET, Node.js, PHP, Python, and Ruby (details and specific runtimes may vary by the service). The best language is a function of many factors, including the task at hand as well as personal preference. Since I was coming at this with no real-world backend development experience, I chose Node.js.Quick aside for those of you who might be not familiar with Node.js: it’s an asynchronous JavaScript runtime designed for building scalable web application back-ends. Let’s unpack this last sentence:
- Asynchronous means first-class support for asynchronous operations (compared to many other server-side languages where you might have to think about async operations and threading—a totally different mindset). It’s an ideal fit for most cloud applications, where a lot of operations are asynchronous.
- Node.js also is the easiest way for a lot of people who are coming from the frontend world (where JavaScript is the de-facto language) to start writing backend code.
- And there is also npm, the world’s largest collection of free, reusable code. That means you can import a lot of useful functionality without having to write it yourself.
Node.js is pretty cool, huh? I, for one, am convinced!
On your mark… Ready, set, go!
For my interview prep, I started with Compute Engine and VMs first, and then moved up the levels of compute service-abstraction ladder, to Kubernetes Engine and containers, App Engine and apps, and finally Cloud Functions. The following table provides a quick summary along with links to my detailed journey and useful getting started resources.| Getting from point A to point B | Time check and getting started resources |
| Compute Engine Basic steps: Create & set up a VM instance Set up Node.js dev environment Code “Hello, World” Start Node server Expose the app to external traffic Understand how scaling works Details: building with virtual machines. | 4.5 hours: Creating a VM Instance Installing Node.js How to create an http server Running Bookshelf on GCE Node.js and GCP |
| Kubernetes Engine Basic steps: Code “Hello, World” Package the app into a container Push the image to Container Registry Create a Kubernetes cluster Expose the app to external traffic Understand how scaling works Details: building with Docker containers. | 6 hours: Dockerizing a Node.js web app Kubernetes Engine quickstart Working with Container Registry Hello Node codelab |
| App Engine Basic steps: Code “Hello, World” Configure an app.yaml project file Deploy the application Understand scaling options Details: building on top of app platform. | 1.5-2 hours: An overview of App Engine Configuring your App Design best practices |
| Cloud Functions Basic steps: Code “Hello, World” Deploy the application Details: building with code functions. | 15 minutes: cloud.google.com/functions/ Cloud Functions overview HTTP Functions |
Time-to-results comparison
Although this might be somewhat like comparing apples and oranges, here is a summary of my results. (As a reminder, this is just in the context of standing up a “Hello, World” web application from scratch, all concerns such as running the app in production aside.)
Your speed-to-results could be very different depending on multiple factors, including your level of expertise with a given technology. My goal was to grasp the fundamentals of every option in the GCP’s compute stack and assess the amount of work required to get from point A to point B… That said, if there is ever a cross-technology Top Gear fighter jet vs. car style contest on standing up a scalable HTTP microservice from scratch, I wouldn’t be afraid to take on a Kubernetes grandmaster like Kelsey Hightower with Cloud Functions!
To find out more about application development on GCP, check out Computing on Google Cloud Platform. Don’t forget—you get $300 in free credits when you sign up.
Happy building!
Further reading on Medium:
