Tuesday, September 15, 2015

Three ways to create a micro-service on Google Cloud - Part 2: Compute Engine

This is part two of a three part blog post describing how I used three distinct Google Cloud technologies to run the same micro-service. I would read Part 1 before reading this.

Part 2: Compute Engine
Compute engine is Google's service for renting Virtual Machines. This is a lower-level service than Google App Engine. It is essentially like renting a computer that runs in the cloud. Except it's a virtual computer. But from the developer's perspective (or user's perspective) it's mostly indistinguishable from a physical computer. Google Compute Engine is roughly similar to Amazon's EC2.

A neat part of Compute Engine's is a related service called Launcher. It has a bunch of common configurations (software stacks) from which to create and launch your new VM. For example, I chose a package called Tomcat Stack (a stack with Tomcat and MySQL on Debian 7).

The general steps to deploy my micro-service were as follows:

  1. Go into Google Cloud's Admin Console and create a new project (we already had a project setup for GAE called cspService, so we just used that one).

  2. Goto the Launcher Tomcat Stack URL:


  3. Click on the "Launch on Google Cloud Platform" button:

  4. Choose a project to deploy into:

  5. Adjust settings and deploy.

    Note that I chose a CPU with 104 GB RAM. Our compile function requires a lot of memory for large input files.

  6. Now we wait for about 3 to 5 minutes. After our new Compute Engine instance is up and running, we are provided with some useful information:
    • The public ip address of our new new instance
    • The instance name (for use in the admin console - ours was tomcat1-tomcat-hjsn)
    • The zone (us-central1-f in our case)
    • Instructions on how to ssh into the machine and copy files up to the machine.

  7. Click on the public ip address to allow HTTP traffic to our new instance:

  8. Finally, I copied the exploded web app from my laptop up to my new Compute Engine instance:

    gcloud compute copy-files
        target/cspService \
        tomcat1-tomcat-hjsn:/var/lib/tomcat7/webapps \
        --zone us-central1-f

    The command line tools come part of the Google Cloud SDK for Java.

And that's it. My server is up and running. Anyone can now surf to my WebApp.

So, compared to the GAE deployment, what did I gain and what did I lose? 

  • There is no limit to the amount of time our servlet is allowed to spend handling a single request.
  • There is no limit on JVM heap size.
  • We can now call servlet methods specific to the Servlet 3.0 API (the Tomcat Stack we chose came with tomcat 7, which supports the Servlet API 3.0).
  • And in general, I now have a much greater level of flexibility.
  • Bigger pain in the butt in the initial set up and deployment.
  • No load balancer. If I want a load balancer I have to take extra steps to set this up.
  • No multiple instances. If I want multiple instances to handle load, I need to create them manually and deploy them. And then setup the load balancer to deal with those instances.
  • No more multiple concurrent versions
So here is what I would like:
  • The convenience of the GAE solution.
  • The super easy scalability and reliability of GAE solution. 
  • The flexibility of the Compute Engine solution. 
Here are two points to help set the stage for part three of our series:
  1. When talking about GAE's super easy scalability and reliability what we are really talking about are some magic technologies running behind the scenes. Things like:
    • Clusters that run multiple replicas of your app
    • Load balancers that sit in front of those replicas
    • Some type of management software to ensure that the replicas are alive and spin up new ones as needed.

  2. One of the hot technologies these days in the area of flexible yet convenient app deployment is Docker
In part three I will show you how we deployed this same app using Google Container Engine which combine the benefits of Docker with Google's open source clustering technology, kubernetes. 

No comments: