You’ve written your app and you’re ready to deploy. Now, it’s time to open up Google Cloud and compare your options for hosting and running the app. Some prudent feature comparison leads you to find that Google Compute Engine (GCE), though still relatively new to the market, is a more competitive choice than Amazon’s EC2 due to its intuitive pricing structure, ease of use and customizability. As far as IaaS goes, you’re ready to get started – right? Not so fast. Google App Engine, a PaaS built on top of GCE, might not only ease your deployment but also save you time and money in the process.
Deciding Between PaaS and IaaS
App Engine supports applications written in Ruby, Python, Java, Go, PHP and Node.js. Google advertises App Engine to be developer friendly: simply upload code and deploy. Unlike Google Compute Engine, you do not need to meticulously control your application’s underlying infrastructure. When it comes to choosing an application hosting environment, there are essentially four options to consider in Google Cloud:
- Compute Engine
- Container Engine
- App Engine (flexible environment)
- App Engine (standard environment)
Google App Engine Standard Environment: Lean and Powerful
While the standard environment is the most basic of Google’s offerings, it’s surprisingly robust. It boasts automatic scaling and load balancing to eliminate concerns of increasing volume and growth. It also integrates with a growing number of Google Cloud Platform’s other services.
In fact, App Engine was Google’s first cloud offering back in 2008. It was so ahead of its time and cloud-forward that Google had to backtrack and build new offerings as stepping stones into the cloud for enterprises with existing applications in familiar, on premise environments. These stepping stone offerings eventually became the Google Cloud Platform. Ok, cloud history lesson over.
Because App Engine comes with a Software Development Kit (SDK) for your local environment, it’s best to know that you’re writing your application for App Engine before you get started. This will allow for a smooth transition from the sandbox environment to Google Cloud Platform Console. It’s also worth noting that while the standard environment may be right for most applications, it comes with some basic limitations. First off, apps written in Node, Ruby or .NET will only be compatible with the flexible environment. You cannot modify the runtime in the standard environment, debug through SSH, or bring in third party libraries that written in an unsupported language by App Engine (such as C).
Despite these limitations, the standard environment is perfect for quick, no hassle deployment. It’s developer friendly – allowing you to use just the Google Cloud Platform Console interface to configure a variety of machine types and simple settings (you can also use a CLI). An instance can be started in milliseconds rather than minutes in the flexible environment.
One other important note: it’s critical to understand the differences between standard and flexible before committing to the standard environment. The process of migrating from standard to flexible down the road can be cumbersome and time intensive. This is something that SADA Systems is able to help you with, as well as other services. If you are looking to “move and improve,” our cloud experts have years of experience helping organizations move to the cloud.
Next Step Up: Google Compute, Container or App Engine Flexible Environment?
If your application exceeds the limitations of the standard environment, or if you require greater control over container scale and orchestration, your choices are down to: App Engine flexible environment, Google Compute Engine (GCE) and Google Container Engine (GKE). The GCE and App Engine Flexible environments have even more in common from a deployment perspective than the Flexible and Standard environments do. The main difference between these two comes down to level of ongoing maintenance and cost.
In the flexible environment, Google does most of the basic machine maintenance tasks for you. The VMs are restarted on a weekly basis to undergo updates to security and operating systems. In Google Compute Engine, these tasks fall on the administrator – very similar to your typical setup for on premise environments.
If your app will sustain consistent, predictable traffic, Committed Use Discounts are a fantastic way to save money on Google Cloud Platform. When these matched up to Amazon’s Reserved Instances, Google’s discounts are not only more intuitive to forecast but also result in more money saved over time. Google infers Sustained Use Discounts automatically from machine types of the same family not covered by committed use, saving even more money! We like saving money.
Ultimately, while these discounts mostly impact apps that receive consistent, predictable traffic they can also cater to apps that receive spikes in traffic when you at least commit to a baseline of usage. On the other hand, the App Engine Standard Environment will often end up being cheaper for apps that receive little to no traffic (they can scale down to zero!. So, a sad app that few people use will at least be cheaper to run. There’s a silver lining in everything, right?
One other cost consideration available on Google Compute Engine is the use of preemptible VMs for short lived, fault tolerant jobs such as batch processing. Think of using preemptible VMs as sneaking into someone’s stadium seats when they get up to go to the bathroom or buy concessions. You can use the VMs when available at a huge discount, but other higher priority Compute Engine tasks can preempt yours at any time. In other words, you have to leave the seats when the real baseball fans get back from their hot dog run.
Need Control Over Container Scale and Orchestration? Consider GKE
Beyond the cost and maintenance considerations, the last consideration (which is covered perfectly in depth here) is your containerization and microservices architecture. For a larger app with many moving parts (you know, when three time zones are working on three different services), GKE best supports a modular structure. In GKE (powered by Kubernetes), the operating system is fully abstracted, allowing for light, single-service pods that can be continuously deployed independently. Services can also be managed independently by scale, maintenance and feature set. For those of us looking to avoid the all too common “we touched one thing and everything broke” problem with our teams, GKE may be a better fit than App Engine Flex and Standard.
GKE falls in between GCE and GAE in the spectrum between IaaS (GCE) and PaaS (GAE). While GCE offers more customization and is fully managed, GKE has a master node that is managed by Google and automatically updated to be current. For a full rundown on Google’s evolving Kubernetes offering, check out the documentation here.
Ultimately, many apps will be able to run on any environment that Google offers. Before jumping straight into one, make sure you consider the limitations and cost-saving opportunities, as well as the modular architecture of your application. Happy deployment!
And for more information on deploying apps in your Google Cloud Platform environment, click here for a free cloud assessment today!
