10 Reasons Why You Should Consider Google App Engine (GAE) for Your Next Project
•Transferir como PPTX, PDF•
0 gostou•208 visualizações
A fun little presentation on why you should consider using Google App Engine for your next project (instead of serverless or managing your own microservices)! This was presented during a talk with Google Cloud in December 2018.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 10 Reasons Why You Should Consider Google App Engine (GAE) for Your Next Project
Semelhante a 10 Reasons Why You Should Consider Google App Engine (GAE) for Your Next Project (20)
Último
Último (20)
10 Reasons Why You Should Consider Google App Engine (GAE) for Your Next Project
- 1. 10 Reasons Why You Should Consider Google App Engine for Your Next Project Google Cloud Relay Dec 2018 Presented by Abeer Rahman
- 2. Quick Poll: What are some of your common challenges you regularly face when deploying software?
- 3. Hi, I’m Abeer Abeer Rahman Tech Lead Agile / DevOps / Site Reliability Engineering
- 4. A flexible, zero ops platform for building highly available apps An app-centric view of the world ● Focus on writing code and never touch a server, cluster, or infrastructure ● Building quickly and time to market are highly valued ● Have high availability without a complex architecture A quick intro to Google App Engine
- 5. Google Infrastructure event driven functions web apps & APIs orchestrate containers infrastructure
- 7. Reason #10 You want to be serverless, but Cloud Functions might be too limiting
- 8. Cloud Functions Mobile backend Lightweight APIs Webhooks IoT Triggering Data processing / ETL jobs App Engine Mobile backend(s) SaaS applications REST-based API Server IoT frontend and/or backend workloads Full websites using popular frameworks
- 9. Arbitrary VM images or Docker containers Financial data analytics Media rendering Stateful storage Genomics Not-so-ideal workloads
- 10. Reason #9 You get multiple languages supported out-of-the-box
- 12. Reason #8 You get even more runtime options using App Engine Flexible environment if the Standard environment is too constrained And you still get the most of the benefits!
- 13. App Engine Standard Application instances run in a sandbox, using the runtime environment of a pre-selected supported language App Engine Flexible Application instances run within Docker containers on Google Compute Engine VMs
- 14. Standard Environment Flexible Environment Specific versions of: Python 2.7, Python 3.7 (beta) Java 8, Java 7 Node.js 8 (beta) PHP 5.5, PHP 7.2 (beta) Go 1.6, 1.8, 1.9, and Go 1.11 (beta) Any versions of: Python, Java, Node.js, Go, Ruby, PHP, or .NET And… runs in a Docker container that includes a custom runtime or source code written in other programming languages. Does not allow background process Allows background process Can scale down to 0 instances Needs at least 1 instance Startup time in seconds Startup time in minutes Can’t SSH Can SSH Can’t write to disk Can write to disk
- 15. Reason #7 You get infrastructure-related security features enabled out of the box
- 16. Security features for Google App Engine: App Engine Firewall rules + DDoS Protection App Security Scanner
- 17. Reason #6 You can design your applications like microservices: modular & self-contained
- 18. Using App Engine for Microservices (in the same project) Code Isolation for each service Multiple versions of each service Log isolation per service Reduced performance overhead for service-to-service call Simplified request tracing
- 19. Structure within a project
- 20. Reason #5 You can run experiments or validate ideas using out-of-the-box A/B testing capabilities with very minimal effort
- 21. Existing App Experimental Version Version 1 Version 2 1 2 90% of traffic 10% of traffic
- 22. App Engine allows different versions with traffic splitting: IP address splitting Cookie splitting
- 23. Migrate traffic to new version gradually after validation (or rollback)
- 24. Reason #4 You can simplify your deployment process. No more heroics required to get your code into production!
- 25. Do the DevOps thing without a “DevOps team” Deploy immediately and receive 100% of traffic: gcloud app deploy Deploy immediately without automatically routing all traffic to a new version: gcloud app deploy --version NEW_VERSION --no-promote
- 26. But wait, there’s more! Deploying multiple services simultaneously: gcloud app deploy service1/app.yaml service2/app.yaml … Useful in a microservices landscape
- 27. Reason #3 You get logging, debugging capabilities built within the integrated environments of Google Cloud
- 28. Coupled with StackDriver Logging, you can get insights into: • Request logs • App logs • 3rd Party Package logs
- 29. App Engine with StackDriver Trace provides insights into: • End-to-end latency data for requests URIs • Round-trip RPC calls to services like Datastore, URL Fetch, Memcache
- 30. Reason #2 Pay for what your app uses. And don’t pay for anything when you have no traffic
- 31. Flexible billing Per second billing (1 minute minimum) App Engine applications operate on the notion of quotas & limits: • Free (!) quotas • Spending limits • Safety limits
- 32. Reason #1 You don’t need to manage infrastructure (servers, network, etc) #LessOps
- 33. For deploying even the most simplest app, traditional infrastructure would require you to: ● Provision server and infrastructure ● Install web and database servers ● Stitch it all together ● Duplicate for dev, test, and prod And then, you have to manage & maintain it... ● Deploy it ● Scale it ● Monitor it
- 34. That 5-minute “Hello World” app is now… Hello Pain
- 35. A flexible, zero ops platform for building highly available apps App Engine Powerful built-in services Designed for scale Focus on your code Popular languages & frameworks Familiar development tools Multiple storage options
- 36. Focus on code, not managing infrastructure. Automation Availability Scale Security
- 37. (10) Not as constrained as pure serverless products (9) Support for multiple languages (8) More flexibility with App Engine Flexible environment (7) Security features enabled out of the box (6) Microservices-oriented capabilities (5) Traffic splitting that allows for A/B testing (4) Simplified your deployment process (3) Integrated environment with logging, debugging capabilities (2) Pay for what you use (1) LessOps: focus on code, not the infrastructure! 10 Reasons Why You Should Consider Google App Engine for Your Next Project Thank you! Abeer Rahman Tech Lead Agile / DevOps / Site Reliability Engineering @abeer486
Notas do Editor
- Google App Engine’s ready-to-scale capabilities has helped lots of customers deploy & scale their product in little time - allowing them to focus solely on writing software & providing value to customers while leaving scaling and operations work Google. Why isn’t my cloud more flexible? We should pay only for what we need with no over-provisioning We want predictable savings we can budget, but with no penalty for optimizing This talk has just one caveat – we’re focusing more on App Engine Standard, but most of them can be applied to app engine Flexible
- Let’s quickly go-over Google’s Compute infrastructure products
- In true David Letterman style
- Transition question: how many of you have thought of using functions? How many use functions in production How many of you thought of using functions, and they you went, yikes – I can’t use functions for most of my current workloads? Yeaah, good for some stuff, but very limited But I’ll tell you, there’s another server less product out there
- Start note: - But instead of focuing on limitations, I’m going to focus on use cases, starting with a product like Google’s Cloud Functions (similar context can be applied to AWS Lamba) Cloud Functions: Lightweight APIs - Compose applications from lightweight, loosely coupled bits of logic that are quick to build and that scale instantly. Your functions can be event-driven or invoked directly over HTTP/S. Webhooks - Via a simple HTTP trigger, respond to events originating from 3rd party systems like GitHub, Slack, Stripe, or from anywhere that can send HTTP requests. Mobile backend - Use Google’s mobile platform for app developers, Firebase, and write your mobile backend in Cloud Functions. Listen and respond to events from Firebase Analytics, Realtime Database, Authentication, and Storage. IoT - Imagine tens or hundreds of thousands of devices streaming data into Cloud Pub/Sub, thereby launching Cloud Functions to process, transform and store data. Cloud Functions lets you do it in a way that’s completely serverless. Data processing / ETL - Listen and respond to Cloud Storage events such as when a file is created, changed, or removed. Process images, perform video transcoding, validate and transform data, and invoke any service on the internet from your Cloud Functions. In either case: removes the work of managing servers, configuring software, updating frameworks, and patching operating systems.
- Key note: In these cases, lower-level infrastructure is a better bet here (like Kubernetes, Compute Engine, or even other Google Cloud Products) And remember – it’s not just about the product, it’s also about the pros & cons of the architecture you want to drive
- Key notes: Out of the box, you get a runtime that allows you write applications in these languages There are specific version for each of the language: Node.js, Ruby, Go, .NET, Java, Python, PHP, All you do is write the code, and the infrastructure is taken care of
- Transition question: So what exact is App Engine Standard an App Engine Flexible?
- A quick definition of each
- Transition note: You can migrate from Standard Environment to Flexible Environment References: https://cloud.google.com/appengine/docs/the-appengine-environments List of differences: https://cloud.google.com/appengine/docs/flexible/python/migrating https://cloud.google.com/appengine/docs/flexible/python/migrating
- Notes: App Engine Firewall rules: enables you to control access to your App Engine app through a set of rules that can either allow or deny requests from the specified ranges of IP addresses DDoS Protection: it’s the same one used by Google Security Scanner: discovers vulnerabilities by crawling your App Engine app, following all that links within the scope of your starting URLs, and attempting to exercise as many user inputs and event handlers as possible
- Starting note: Google App Engine has a number of features that are well-suited for a microservices-based application. Here are some of the concepts that can be used design when deploying your application as a microservices-based application on Google App Engine. Code Isolation for each Service Deployed code is completely independent between services and versions. Isolated modules/services interaction through HTTP Can deploy multiple microservices as separate services, previously known as modules in App Engine. These services have full isolation of code; the only way to execute code in these services is through an HTTP invocation, such as a user request or a RESTful API call. Code in one service can't directly call code in another service. Code can be deployed to services independently, and different services can be written in different languages, such as Python, Java, Go, and PHP. Autoscaling, load balancing, and machine instance types are all managed independently for services. Multiple versions of each service Along with rollbacks Furthermore, each service can have multiple versions deployed simultaneously. For each service, one of these versions is the default serving version, though it is possible to directly access any deployed version of a service as each version of each service has its own address. This structure opens up myriad possibilities, including smoke testing a new version, A/B testing between different versions, and simplified roll-forward and rollback operations. The App Engine framework provides mechanisms to assist with most of these items. We'll cover these mechanisms in more detail in upcoming sections. Log Isolation Each service (and version) has independent logs, though they can be viewed together. Reduced performance overhead Services of the same project are deployed in the same datacenter, so the latency in calling one service from another by using HTTP is very low. Simplified request tracing Using Google Cloud Trace, you can view a request and the resulting microservice requests for services in the same project as a single composed trace. This feature can help make performance tuning easier. References: https://cloud.google.com/appengine/docs/standard/python/microservices-on-app-engine
- References: https://cloud.google.com/appengine/docs/standard/python/an-overview-of-app-engine Key notes: Each service is isolated and can have multiple version, and each version can have multiple instance Optionally, you can deploy update or newer versions services simultaneous
- Key notes: IP Splitting It hashes the IP address to a value between 0–999, and uses that number to route the request. So, not necessarily geo-specific Reasonably sticky, not permanent (e.g., user on a cell phone) Cookie Splitting The app looks for a HTTP request header for a cookie named GOOGAPPUID and assigns a value, Which contains a value between 0–999: If the cookie exists, the value is used to route the request. If there is no such cookie, the request is routed randomly. Easier to accurately assign users to versions. The precision for traffic routing can reach as close as 0.1% to the target split. Preferred way is: It's easier to set up an IP address split, but a cookie split is more precise References: https://cloud.google.com/appengine/docs/standard/java/splitting-traffic
- Key notes: Traffic migration switches the request routing between the versions within a service of your application, moving traffic from one or more versions to a single new version. Once you’re happy, you can gradually migrate traffic
- Key notes: With just a set of simple statements we can promote our code to live If we want to immediately deploy and receive all traffic, we use the gcloud app deploy statement If we want to immediately but without automatically routing all the traffic to the new version This allows us to do dark launches References: https://cloud.google.com/appengine/docs/standard/java/tools/uploadinganapp
- Key notes: In a microservices world, we can use same deployment commands for deploying and updating the multiple services of our applications And if we mix & match the commands we can get a lot of flexibility
- Integration with StackDirver's Logging & Trace APIs provide tools to search wide or deep across the stack
- Poll: Raise of hands: How many of you manage microservices? Or even some distributed applications in production? You now know the pain of tracing through the services to see if the Key notes: App Engine has built in StackDirver monitoring covering both instance-level & request level metrics All within the Google Cloud platform - you don’t have to jump around References: https://cloud.google.com/appengine/articles/logging#stackdriver_name_logging_name_short_and_the_standard_environment
- Key notes: Sackdriver Trace collects end-to-end latency data for requests URIs round-trip RPC calls to services like Datastore, URL Fetch, Memcache. As micro-services become more popular, the cross-application tracing provided by Stackdriver Trace becomes essential in pinpointing the root cause of latency issues.
- Key notes: Instances within the standard environment have access to a daily limit of resource usage that is provided at no charge defined by a set of quotas. Free quotas: Every application gets an amount of each resource for free. Free quotas can only be exceeded by paid applications, up to the application's spending limit or the safety limit, whichever applies first. When free applications reach their quota for a resource, they cannot use that resource until the quota is replenished. Paid apps can exceed the free quota until their spending limit is exhausted. Spending limits: you can set the spending limit to manage application costs in the Google Cloud Platform Console in the App Engine Settings. Spending limits might be exceeded slightly as the application is disabled. Safety limits: Safety limits are set by Google to protect the integrity of the App Engine system. These quotas ensure that no single app can over-consume resources to the detriment of other apps. If you go above these limits you'll get an error whether you are paid or free. References: https://cloud.google.com/appengine/quotas https://cloud.google.com/appengine/pricing Free quotas: Every application gets an amount of each resource for free. Free quotas can only be exceeded by paid applications, up to the application's spending limit or the safety limit, whichever applies first. Spending limits: If you are the project owner and the billing administrator, you can set the spending limit to manage application costs in the Google Cloud Platform Console in the App Engine Settings. Spending limits might be exceeded slightly as the application is disabled. Safety limits: Safety limits are set by Google to protect the integrity of the App Engine system. These quotas ensure that no single app can over-consume resources to the detriment of other apps. If you go above these limits you'll get an error whether you are paid or free.
- You don’t pay for server for the app at 2am when no one is using it
- Provision server and infrastructure environments Install web and database servers Stitch it all together (db connection strings) Duplicate for dev, test, and prod Key notes: So your “hello world” app becomes “Hello Pain”
- Read per transition: Focus on your code - Let Google worry about database administration, server configuration, sharding & load balancing. Designed for scale - A scalable system which will automatically add more capacity as workloads increase. Powerful built-in services - Managed services, such as Task Queues, Memcache and the Users API, let you build any application. Familiar development tools - Use the tools you know, including Eclipse, IntellIJ, Maven, Git, Jenkins, PyCharm & more. Popular languages & frameworks - Write applications in some of the most popular programming languages, use existing frameworks and integrate with other familiar technologies. Multiple storage options - Choose the storage option you need: a traditional MySQL database using Cloud SQL, a schemaless NoSQL datastore, or object storage using Cloud Storage.
- Automation Infrastructure allocation, provisioning, and configuration Availability Automatic x-zone deployments and failovers + built-in monitoring Scale Focus on building your business, we’ll handle your load Security Apps take advantage of secure defaults Google auto-patches runtimes Scan for security vulnerabilities Focus on writing code and never touch a server, cluster, or infrastructure Build apps & services quickly and reduce time to market Achieve high availability without a complex architecture Sleep at night in peace and not worry about a pager going off, or 5xx errors :)