Let’s go back a couple of years…..
The mobile development scenario was promising but challenging. Developers had to handle the app design and UX, write the actual code and build backend integration. In the highly competitive mobile app market, success or failure often hinged on those few extra hours spent on getting the UX right. But front end design often takes a backseat as almost 80% of developer time is spent on building the backend. The dilemma that developers often faced when building their mobile app backend was:
Whether to use a service that ‘had it all’
Keep the ability to ‘mix-and-match’ different services from different vendors.
Choosing the first meant vendor lock-in, and
Choosing the latter meant dealing with integration and maintenance headaches
One question aired often was, whether to use a PaaS like App Engine or write a platform and vendor independent program. Several developers chose to write their application in Node.js and run it on AWS instances using MongoDB as the data host. This approach allowed flexibility and meant no vendor lock-in. Remember, this was a time when App Engine was limited in many ways:
It did not support node.js; you could only use cloud datastore with Java (app engine supported language) and not MongoDB.
More restrictions like the use of only predefined app engine libraries and specific configurations meant the App Engine was a difficult choice for developers.
But the cloud platform as a whole has been evolving, and not long ago Google launched its own MbaaS. Google Cloud Endpoints is a MbaaS that makes building backend APIs incredibly easy. Google Cloud has now emerged as an attractive platform for developers. This is because it offers end-to-end mobile application development services. How? The App Engine made building code quick and effortless. Plus, using the App Engine lets you take advantage of other vertically integrated services available on Google Cloud. This meant you did not need third-party providers for database, search and storage needs.
With the advent of PaaS and MbaaS, it looked like the dilemma developers faced was resolved.
But sadly, the App Engine continues to remain a difficult choice for developers who prefer flexibility. The constraints are in the form of the limited number of supported languages and runtimes. In contrast, building a platform independent backend would take longer to get up and running and require more maintenance but came with greater portability. The dilemma remained.
Fast Forward to Now…
Introduction of custom runtimes has made these questions redundant. Let’s find out how.
Cloud computing or utility computing lowers the cost and time of development. Cloud service providers are making the task of building and launching new products easier by the day. They have moved beyond renting of computing space to provision of management services. Management services provided in PaaS abstract away most of the maintenance tasks from developers. Product developers will normally need to sacrifice control over their runtime environment if they happen to use a PaaS. They choose PaaS as it saves them the hassle of running VMs and lets the focus be on adding features and designing better UX. With launch of custom runtimes, Google brings flexibility to fully-managed services like App Engine. It resolves the flexibility vs automation dilemma for developers.
Before we explore how custom runtimes work and the advantages they offer to developers, let’s take a brief look at what other options App Engine has:
There are 2 different runtime environments in app engine: Standard and flexible. Custom runtimes were introduced as a part of the flexible environment framework.
Custom Runtimes: What and for Who?
Custom runtime has 2 main advantages:
- It is language agnostic. Users can go beyond Java, python, Node.js, Go and Ruby. They can deploy applications written in any programming language.
- The serving stack is customizable
Both these advantages are available without compromising on the provision of scaling, monitoring and load balancing services that are still managed by the provider.
Custom runtimes are immensely beneficial for those looking at cloud adoption or migration. Take for instance Parse migrants, they can run their Parse server applications on App Engine custom runtime environments. The process is simple, they can use the migration guides released by Facebook to migrate the parse data to MongoDB installed on Compute Engine VMs and run the parse serve built on Node.js on App Engine Managed VMs (using the custom runtime option).
Running Parse-server on Google Cloud Platform
The following diagram shows the process of deploying the app on Cloud Platform.
The app engine flexible environment runs your application in containers that can automatically scale to handle your application’s load. Behind the scenes, this architecture contains both compute engine and docker.
How u can specify custom runtimes in GAE
When it first launched Google App Engine console supported a handful of languages. For those looking to migrate to App Engine, they had to rework their code from the language it was written in, to App engine supported languages. In the past if one was not keen on rewriting the code, one had to forgo the fully-managed PaaS. But compute engine VMs not only allow you to work in any language they also let you customize the runtime environment to suit your application.
Google however has always expressed the desire to make its services language agnostic. Google introduced custom runtimes under its flexible environment configuration to ease these constraints. In custom runtime, you specify the code, take care of dependencies like language translation and application servers, and provide a configuration file. The App engine uses these to deploy and run your app. Custom runtime is actually a docker container, for which you supply a Dockerfile with a base image of your choice, and add other docker commands as needed to build the desired runtime environment. This docker container runs on fully managed App Engine VMs. When you use a custom runtime, you must write the application code to handle certain flexible environment life-cycle and health checking requests.
So, the introduction of app engine means you can design a runtime customized to your app requirement. Once you deploy the App on the SDK, everything is taken care of by the App Engine. It builds the docker images, creates and manages the containers and virtual machines based on your specifications. Custom runtime apps are fully scalable just like apps run on standard or flexible environments.
Custom runtimes take the flexibility in flexible runtime environment a little further. Here are the differences between plain flexible runtimes and custom runtimes:
|Dockerfile||Default file supplied automatically by the SDK||Hand-written by the developer|
|Dockerfile modifications permitted||Yes||Yes|
|Languages||Python, Java, Node.js, and Go||Any software that can service HTTP requests|
|Start/Stop request||Requests are handled automatically by default. Optionally, you can write your own handlers.||Your app will receive these requests but does not need to respond to them. Optionally, you can write your own handlers.|
|Health checking||Requests are handled automatically by default. Optionally, you can write your own handlers.||You must write your own handlers or disable health checks.|
|App Engine standard environment APIs||Some API support is available by default. Read the Python, Java, or Gopage for each runtime.||You must use the publicly available REST APIs for cloud services or Google API Client Libraries.|
Custom runtimes bring the advantages of self-managed services to Fully-managed services.
A comparison of compute engine and App engine custom runtimes will show you how.
Flexible environment in App Engine versus Compute Engine
The basic difference is that custom runtimes are still a managed service. The maintenance of VMs is still being done by Google, co-location of VM instances also happens automatically. If you were using self-managed VMs of compute engine you would have to configure and maintain the runtime environment yourself.
Let’s consider the ways in which both services differ:
- When flexible environment instances restart Google applies the necessary OS and security updates.
- Root access to Compute Engine VMs is disabled in flexible environments but can be enabled by the developer if required.
- In flexible environment, VM instances for a project are co-located by Google’s management services for optimal performance.
Google has innovated custom runtimes to help strike a balance between flexibility and abstraction without compromising on benefits like auto-scaling. The feature brings greater ease and flexibility to developers looking to build their products on App Engine Platform.