Applications in the cloud

App Engine

Two GCP products provide compute infrastructure for applications:

  • Compute Engine (based on VMs)
  • Google Kubernetes Engine (based on containers)

What they have in common is that you choose the infrastructure in which your app runs. If you don’t want to focus on infrastructure at all and focus only in your code, that’s what App Engine is for.

PaaS. App Engine manages your hardware and network infrastructure. To deploy an app, you just give App Engine your code and the service takes care of the rest. It provides you with built-in services that many web apps need such as NoSQL databases, in-memory caching, load balancing, health checks, logging, authentication.

App Engine will automatically scale your app, so you just pay for the services you use. App Engine is especially suited for applications where the workload is highly variable or unpredictable like web apps and Mobile BE.

It offers two environments: standard and flexible.

Standard Environment

This is the simpler as it offers a simpler deployment experience and fine-grained auto-scale.

  • Easily deploy apps
  • autoscale workloads
  • free daily quota (for the use of some services), pay per instance class, automatic shutdown
  • usage based pricing

Low utilization apps might be able to run at no charge.

Google privdes App Engine SDKs in several languages so that you can test your app locally. They provide simple commands for deployment.
You use a Runtime provided by Google for specific versions of:

  • Java
  • Python
  • PHP
  • Go

It also includes libraries that support App Engine APIs. It also includes rules for your code, by making it run in a sandbox. This sandbox is one of the reasons why it can scale and manage your apps in a very fine-grained way but it imposes some constraints as for example:

  • your app can’t write to the local file system
  • all requests your app receives, have a 60 second timeout
  • you can’t install arbitrary third party software

If you want to code in another language or this contraints don’t work for you, Standard Environment is not for you.

Workflow:

  • develop & test the web app locally
  • use the SDK to deploy to App Engine
  • it automatically scales, load balances and serves your web app

Each App Engine app runs in a GCP Project.

Flexible Environment

Use this is Standard Environment’s constrictions doesn’t work for you. Comparison against Standard Environment

  • It lets you specify the container your App Engine runs in. Your app runs inside Docker containers on VMs.
  • It starts way slower than SE. (ms vs minutes)
  • SSH access (not by default)
  • Able to write to local disk
  • 3rd-party binaries
  • Network access
  • Pay for resource allocation per hour; no automatic shutdown

App Engine vs Kubernetes Engine

  • App Engine (PaaS model) is for people who want the service to take maximum control of their app’s deployment and scaling.
  • GKE (Hybrid service model) gives the owner the full flexibility of Kubernetes.
  • App Engine Flexible Env is somewhere in between.

The primary use for GKE is container-based workloads meanwhile for App Engine is web and mobile applications, and container-based workloads for the Flexible Env

Google Cloud Endpoints and Apigee Edge

what’s an API? it’s a clean, well-defined interface which abstracts away needless details so that other pieces of software don’t need to know internal details of a component. It’s common to version them to be able to deprecate calls.

Cloud Endpoints

It’s for a GCP backend. It exposes the API, making sure it’s only consumed by other developers whom you trust. It also provides an easy way to monitor and log its use, being able to know which end user is making the call.

It’s available for

  • App Engine Flexible Env
  • Kubernetes Engine
  • Compute Engine

Apigee Edge

Is a platform for developing and managing API proxies. It helps you secure and monetize APIs.
It has a focus on business problems like rate limiting, quotas and analytics. Many of its users provide a service to other companies.

Engineers often use it when they’re taking apart a legacy application, peeling of the services of a monolithic application one by one, standing up microservices to implement each in turn.

The BE services for Apigee Edge need not be in GCP.