Chapter 11. App Engine: fully managed applications
What is App Engine, and when is it a good fit?
Building an application using the Standard and Flex versions
Managing how your applications scale up and down
Using App Engine Standard’s managed services
Computing platforms, representing a large variety in terms of complexity, flexibility, and performance.
Compute Engine is an example of low-level infrastructure (a VM).
App Engine is a fully managed cloud computing environment.
Consolidate all of the work needed when deploying and running your applications.
Two separate environments that have some important differences. One environment is built using open source tools like Docker containers.
Proprietary technology that allows Google to do interesting things when automatically scaling your app.
Fully managed computing environment complete with storage, caching, computing, scheduling.
Limited to a few programming languages.
App Engine handles sudden spikes of traffic sent to your application gracefully, and periods when your application is inactive don’t cost you any money.
App Engine Flexible Environment (often called App Engine Flex) provides a fully managed environment with fewer restrictions.
11.1. Concepts
The API layer has a few more organizational concepts that you’ll need to understand to use App Engine
App Engine keeps track of the versions of those components.
11.1.1. Applications
Host your work is the top-level application.
Each of your projects is limited to one application, with the idea that each project should have one purpose.
The application acts as a container for your code.
App Engine section in the left-side navigation of the Cloud Console.
Choose a language (for example, Python);
Choose the location of your application
11.1.2. Services
Services on App Engine provide a way to split your application into smaller, more manageable pieces.
Similar to microservices, App Engine services act as independent components of computing.
Can access the same shared cron API from any of the various services you might have as part of your application.
Building a web application that tracks your to-do list.
Add a feature that sends email reminders to finish something on your list.
Rather than trying to add the email reminder feature to the main application, you might define it as a separate service inside your application.
The service itself consists of your source code files and extra configuration, such as which runtime to use (for App Engine Standard).
You can create (deploy) as well as delete services.
Services also act as another container for revisions of your application.
Deploy new versions of your reminder service to your application without having to touch the web application service.
Isolate changes between related systems can be useful, particularly with large applications built by large teams.
11.1.3. Versions
Point-in-time snapshots of a service.
Version of your service corresponds to the code in that directory at the exact time that you decided to deploy it to App Engine.
Code that you deploy in that first service becomes the default version of that service.
11.1.4. Instances
App Engine uses the concept of an instance to mean a chunk of computing capacity for your application.
Instances represent an abstract chunk of CPU and memory available to run your application inside a special sandbox.
Scale up and down automatically based on how many requests are being sent to your application.
Scale from zero to thousands of instances quickly.
App Engine Flex is built on top of Compute Engine and Docker containers, it uses Compute Engine instances to run your code.
Flex applications must always have at least a single VM instance running. As a result, Flex applications end up costing money around the clock.
App Engine instances are specific to a single version of your service.
11.2. Interacting with App Engine
Understanding of the underlying organizational concepts that App Engine uses (such as services or versions).
Create a simple “Hello, world!” application for App Engine, deploy it, and verify that it works.
11.2.1. Building an application in App Engine Standard
App Engine Standard is a fully managed environment where your code runs inside a special sandbox rather than a full virtual machine.
Build your “Hello, world!” application using one of the approved languages.
Make sure you have the right tools installed.
Python seems a good choice (it’s powerful and easy to read).
Installing Python extensions
Need to install the Python extensions for App Engine
from the shell.
gcloud components install app-engine-python
john_iacovacci1@cloudshell:~ (uconn-engr)$ gcloud components install app-engine-python
All components are up to date.
john_iacovacci1@cloudshell:~ (uconn-engr)$
Creating an application
Focusing on nothing more than a “Hello, world!”
You’ll start your Python app by using the webapp2 framework, which is compatible with App Engine.
webapp2 application that defines a single request handler and connects it to the root URL (/). In this case, whenever you send a GET HTTP request to this handler, it sends back “Hello from App Engine!”
Note: We will use flask for this class
import webapp2
classHelloWorld(webapp2.RequestHandler):
defget(self):
self.response.write('Hello from App Engine!');
app = webapp2.WSGIApplication([
('/', HelloWorld),
])
Put this code into a file called main.py
A way you tell App Engine how to configure an application is with an app.yaml file.
YAML (Yet Another Markup Language)
Easily readable syntax for some structured data that looks a lot like Markdown.
app.yaml name is a special file that App Engine looks for when you deploy your application.
see the app.yaml file that you’ll use runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /.*
script: main.app
It’s time to try running it locally and making sure it works as you want.
Deploying another service
New service as a new chunk of code, and you need to make sure you have a safe place to put this code.
Make two new directories called default and service2, and copy the app.yaml and main.py files into each directory.
11.2.2. On App Engine Flex
App Engine Standard is limited to some of the popular programming languages and runs inside a sandbox environment,
App Engine Flex is based on Docker containers.
You can use any programming language you want.
Creating an application
11.3. Scaling your application
Scaling and instance configuration, App Engine Standard and App Engine Flex have a few differences.
11.3.1. Scaling on App Engine Standard
App Engine Standard has quite a few scaling options that you can fine-tune so they fit your needs.
Automatic scaling
Default scaling option is automatic.
App Engine will decide when to turn on new instances.
Number of concurrent requests.
Longest a given request should wait around in a queue.
Number of instances that can be idle at any given time.
Idle instances
App Engine Standard instances are only chunks of CPU and memory rather than a full virtual machine.
Standard provides a way for you to decide the minimum and maximum number of instances that can sit idle waiting for requests before being turned off.
How many buffer instances to keep around that aren’t actively in use.
Set the minimum and maximum idle instances both to 1, then App Engine will turn off instances until there’s exactly one sitting idle waiting for requests.
YAML file
runtime: python27
api_version: 1
service: default
automatic_scaling:
min_idle_instances: 2
max_idle_instances: 3
Pending latency
Request to App Engine, Google’s frontend servers handle the request and ultimately route it to a specific instance running your service.
Queue of requests in case some of them aren’t ready to be handled yet.
No instance is available.
Sit in a queue for a bit until an instance becomes available.
Lots of people making requests to the service.
App Engine immediately queues up requests to be processed.
How long a request sits in that queue.
App Engine can turn on more instances.
App Engine lets you choose the minimum and/or maximum amount of time that any given request should spend sitting in this queue, which is called pending latency.
Spending more than the maximum pending latency in the queue, you should turn on more instances.
Minimum pending latency is the way you set a lower bound when telling App Engine when it’s OK to turn on more instances.
runtime: python27
api_version: 1
service: default
automatic_scaling:
min_pending_latency: 5s
max_pending_latency: 10s
Concurrent requests
Instances can handle more than one request at a time.
Number of requests happening at once (level of concurrency) is another metric to use when autoscaling.
Set a concurrency level as a way to trigger turning more instances on or off.
Set a target for how many requests an instance can handle at the same time.
By default, App Engine will aim to handle eight requests concurrently on your instances, and although you can crank this all the way up to 80.
Basic scaling
Slimmed-down version of automatic scaling.
Maximum number of instances and how long to keep an idle instance around before turning it off.
Specify how long those instances should sit idle before App Engine turns them off.
Manual scaling
You tell App Engine exactly how many instances you want running at a given time.
This type of scaling should be for situations where you have a strict budget and don’t care much whether your application is always available to your customers.
All requests are routed to this pool of machines, which may become overwhelmed to the point where requests time out.
11.3.2. Scaling on App Engine Flex
App Engine Flex is based on Docker containers and Compute Engine VMs, the scaling configurations should feel similar to the way we looked at autoscaling Compute Engine instances with instance groups and instance templates.
Automatic scaling
App Engine Flex is capable of scaling your services up and down like you did previously when we looked at automatic scaling of Compute Engine instances.
Control the number of VM instances that can be running at any given time. As you’ve learned, at least one instance must be running at all times
Set a maximum number of instances to avoid your application scaling out of control.
Manual scaling
App Engine Flex has an option to decide up front exactly how many VM instances to run for your service
11.3.3. Choosing instance configurations
Number of instances and how to scale them, and I’ve asked you to think of instances as chunks of CPU and memory.
Choose instance configurations that suit your application, starting with App Engine Standard.
App Engine Standard instance classes
App Engine Standard involves running your code in a special sandbox environment.
Use a setting called instance_class in your app.yaml file.
By default, automatically scaled services use F1 instances.
App Engine Flex instances
Because App Engine Flex is based on Docker containers and Compute Engine instances, you get quite a bit more freedom when choosing virtual hardware.
App Engine Flex sticks to the idea of declaring the resources you need and allowing App Engine itself to provision machines that match those needs.
I need at least two CPUs and at least 4 GB of RAM.” App Engine takes that and provisions a VM for your service that has at least those resources.
runtime: nodejs
env: flex
service: default
resources:
cpu: 2
memory_gb: 4.0
11.4.1. Storing data with Cloud Datastore
storing data using many methods, and Google Cloud Platform has many services available
Access these services from inside App Engine.
Connect to the services from inside your App Engine application.
Cloud Datastore is a nonrelational storage system that stores documents and provides ways to query them.
Prebaked into App Engine with APIs built into the runtime.
Python, App Engine Standard provides a Datastore API package called ndb, which acts as an ORM (object-relational mapping) tool.
11.4.2. Caching ephemeral data
Applications commonly will want to store data temporarily.
Query might be particularly complex and put quite a bit of strain on the database.
A cache is typically a great answer.
App Engine Standard provides a hosted Memcached service that you can use with no extra setup at all.
Access these services from inside App Engine.
Connect to the services from inside your App Engine application.
Cloud Datastore is a nonrelational storage system that stores documents and provides ways to query them.
Prebaked into App Engine with APIs built into the runtime.
Python, App Engine Standard provides a Datastore API package called ndb, which acts as an ORM (object-relational mapping) tool.
11.4.3. Deferring tasks
Your code has some work to do that doesn’t need to be done right away but instead could be delayed.
Sending an email or recalculating some difficult result.
Something that takes a while and can be done in the background.
App Engine comes with a system built-in that makes it easy to push work off until later, called Task Queues.
Want to schedule the work to be done, and once it was confirmed as “scheduled,” you could send a response telling the user that they should get an email soon.
11.4.4. Splitting traffic
Trigger a deployment without making the new version live yet.
Run multiple versions side by side and then do hot switch-overs between versions.
Slowly test out new versions, shifting traffic from one version to another over the course of the day?
Traffic splitting, you can control what percentage of traffic goes to which version.
11.5. Understanding pricing
How the computational aspects of App Engine are priced and look at costs for a few of the services that I discussed in this chapter, starting with computing costs.
App Engine Flex is built on top of Compute Engine instances, the costs are identical to Compute Engine,
11.6. When should I use App Engine?
App Engine’s environments are almost like entirely separate computing platforms, it seems worthwhile to have a separate scorecard for the different options
.
11.6.1. Flexibility
App Engine Flex offers levels of flexibility (what code you can run) similar to those of Compute Engine or Kubernetes Engine, App Engine Standard is far more limited.
11.6.2. Complexity
App Engine Standard, you have a lot to learn, specifically with regard to the runtime environments and the limitations that come with them.
App Engine Flex, on the other hand, is similar in overall complexity to something like Compute Engine, though slightly scaled down because you don’t need to understand all of the scaling details like instance group.
11.6.3. Performance
App Engine Flex relies on Compute Engine VMs, the overall performance of your services should be about as good as you’ll get on a cloud computing platform.
11.6.4. Cost
App Engine Flex has pricing that’s almost identical to the pricing for Compute Engine.
App Engine (by default) controls the scaling. As a result, you may overprovision, which would lead to a higher overall cost.
Summary
App Engine is a fully managed cloud computing environment that simplifies the overhead needed for all applications (
App Engine has two different environments: Standard, which is the more restricted environment, and Flex, which is less restrictive and container-based.
App Engine Standard supports a specific set of language runtimes, whereas App Engine Flex supports anything that can be expressed in a Docker container.
The fundamental concept of App Engine is the application, which can contain lots of services. Each service can then contain several versions that may run concurrently.
Underneath each running version of an application’s services are virtualized computing resources.
The main draw of App Engine is automatic scalability, which you can configure to meet the needs of most modern applications.
App Engine Standard comes with a specific set of managed services, which are accessed via client libraries provided to the runtime directly (for example, the google.appengine.api.memcache API for Python).
App Engine pricing is based on the hourly consumption of the underlying compute resources. In the case of App Engine Flex, the prices are identical to Compute Engine instance pricing.
git clone https://github.com/GoogleCloudPlatform/python-docs-samples
https://codelabs.developers.google.com/codelabs/cloud-app-engine-python3/#0
No comments:
Post a Comment