Recomendados
Más contenido relacionado
Similar a How App Engine handles scaling, failures and upgrades for you
Similar a How App Engine handles scaling, failures and upgrades for you (20)
Más de sandeephegde
Más de sandeephegde (11)
Último
Último (20)
How App Engine handles scaling, failures and upgrades for you
- 2. Translate Cloud Datastore Google App Engine & Cloud Overview Prediction https://developers.google.com/groups www. SandeepHegde.me
- 3. Building a traditional web application What about hardware failure, traffic spikes? No or low on resources/funding? What about scaling? How about software patches & upgrades? Can you afford an architect, engineers, and system administrators to design, implement, and operate this complex thing? https://developers.google.com/groups www. SandeepHegde.me
- 4. Why does App Engine exist? https://developers.google.com/groups www. SandeepHegde.me
- 5. App Engine to the rescue!! Build and run your web apps on Google’s infrastructure •Easy to build •Easy to manage •Easy to scale • Enabling greater developer productivity! • Focus on building your app, not sys admin • Let us wear the pagers! • BUT don't confuse App Engine w/IaaS services! https://developers.google.com/groups www. SandeepHegde.me
- 6. • Approximate size of Google's search index? o (2012 - 100 million gigabytes) • How much video uploaded to YouTube every minute (in hours)? o (2013 – 100 hours per minute) • Speaking of YouTube... monthly uniques? o (2013 – one thousand million) • Google ever down? 500s? https://developers.google.com/groups www. SandeepHegde.me
- 7. Out-of-this-world Scaling and Security • • googleblog.blogspot.com/2012/10/googles-datacenters-inside-look.html goo.gl/maps/dWF8l https://developers.google.com/groups www. SandeepHegde.me
- 8. Cloud Industry & Service Levels Source: Gartner AADI Summit Dec 2009 https://developers.google.com/groups www. SandeepHegde.me
- 9. What is Google's Cloud? • Comprehensive, integrated platform • Extension of Google internal infrastructure • As improvements made to cloud for Google... • Use what Google uses: build your software & run your business in the same place they do o Compute, storage, application services o Serving all levels of cloud computing service o With access to other Google services & APIs o Users reap these benefits/upgrades o Without any effort on your part o With same scale, performance, security, and value they built for themselves https://developers.google.com/groups www. SandeepHegde.me
- 10. Python, Java, Go, PHP not enough for you? https://developers.google.com/groups www. SandeepHegde.me
- 11. Specialized APIs/Services for the Sandbox Memcache Datastore URL Fetch Mail XMPP Task Queue Images Cloud Storage User Service https://developers.google.com/groups www. SandeepHegde.me
- 12. How does it work? Hardware failure, traffic spikes, scaling, software patches and upgrades handled by Google... and yes, we’ll operate it for you! https://developers.google.com/groups www. SandeepHegde.me
- 14. App Engine - By the Numbers* • 300,000+ Active developers • 3,000,000+ Active applications • Half of world's Internet addresses touch an App Engine server (per week) * per month except as otherwise noted https://developers.google.com/groups
- 15. App Engine - Larger Numbers* 7,500,000,000+ Hits (per day) 4,500,000,000,000+ Datastore requests * per month except https://developers.google.com/groups as otherwise noted
- 16. Some App Engine users https://developers.google.com/groups
- 17. Long-term scaling... • 3.6MM DAUs on FB • 1.9MM DAUs on MS • Add Orkut, Bebo, Hi5, Friendster, Hyves, Ning… https://developers.google.com/groups
- 18. Not all apps have web UI • Need backend server processing? Want to build your own? • Go cloud with App Engine! • No UI needed for app to talk to App Engine, just need HTTP • Great place for user info e.g., high scores, contacts, levels/badges, etc. • Better UI: move user data off phone & make universally available https://developers.google.com/groups
- 19. App Engine as Mobile Backend • Pulse’s mobile app o o o Android iOS Kindle • Awards (2011) o Apple’s App Store Hall of Fame o Time Magazine’s Top 50 iOS apps • 30MM+ users, 10MM+ stories read/day • Thousands of QPS, 100M daily requests • Use of App Engine cost-effective more about Pulse • Readgoogleappengine.blogspot.com/2011/11/scalingo o with-kindle-fire.html cloud.google.com/files/Pulse.pdf • Get started building your mobile backend: o developers.google.com/cloud/samples/mbs https://developers.google.com/groups
- 20. Gaming... share data, mobile or web! https://developers.google.com/groups
- 22. Google Cloud Endpoints ● APIs for web and mobile backends made easy ● Watch the tutorial & get the code at cloud.google.com/mobilebackendtutorial https://developers.google.com/groups
- 23. Popular App Engine use cases • Mobile/Tablet o App backends o Cloud persistence • Social/Mobile Games o Speed, scale o API integrations o Personals/dating • Consumer Web Apps o Unpredictable traffic o Scale • Apps in Academia o Any course where students build web or mobile apps o Research projects o IT/Operational apps •Business Apps o Enterprise o Java runtime o Web or Mobile https://developers.google.com/groups
- 24. Getting Started What Where Product Info cloud.google.com/products Docs, downloads, etc. developers.google.com/appengine Create/manage your apps appengine.google.com Help from experts on anything technical, including App Engine stackoverflow.com Google Prediction API Cloud Blog Social • googlecloudplatform.blogspot.com google.com/+googlecloudplatform @GoogleCloud Google Storage The docs are great, but what about teaching materials? https://developers.google.com/groups
- 25. Cloud Playground •Try App Engine without any downloads! cloud-playground.appspot.com https://developers.google.com/groups
- 26. Connect to Google Cloud & other services Cloud Datastore Google App Engine Compute Engine Translate Cloud SQL BigQuery ??? Prediction Google Cloud Storage https://developers.google.com/groups www.SandeepHegde.me
- 27. Google Compute Engine • Need to go outside App Engine boundaries? • On-demand VMs (RHEL/CentOS, Debian) o 1-8 virtual cores o 1.8-6.5GB RAM/core o Private VM network storage types • o 3Local/scratch: 420GB o Persistent disk: 10TB o Cloud Storage: unlimited 3 interfaces •Command-line interface o o Web-based interface o Your code via REST API https://developers.google.com/groups www.SandeepHegde.me
- 28. Google Cloud Platform Google Cloud Storage •Large scale cloud storage (<5TB/obj) •US or EU data centers; Google worldwide network •Strong read-your-write consistency •99.9% SLA •ACLs at the object or bucket-level •Gateway to all Google cloud platform services •REST API, App Engine API, Web UI, command-line •developers.google.com/storage Google Cloud SQL • • • MySQL-compatible relational database in the cloud Access via App Engine API or externally via JDBC developers.google.com/cloud-sql https://developers.google.com/groups www.SandeepHegde.me
- 29. Google Cloud Platform Google Cloud Datastore •A NoSQL database at Google scale •Familiar native datastore for App Engine •Now accessible externally via HTTP/RPC •Built on scalable Google tech (MegaStore, BigTable, Colossus) •developers.google.com/datastore Cloud Datastore Google Translate • • • • • Build multilingual apps Translate text into other languages programmatically Translate Use a familiar RESTful interface Take advantage of Google's powerful translation algorithms developers.google.com/translate https://developers.google.com/groups www.SandeepHegde.me
- 30. Google Cloud Platform Google BigQuery •Large scale query and analysis cloud service •Query multi-terabyte datasets in seconds •SQL-like query language •Based on Google's internal Dremel project •Take a tour at cloud.google.com/bigquery-tour Google Prediction • • • • • Machine Learning service in the cloud Supervised learning Train models, get "predictions" "Magic?" Possibly. developers.google.com/prediction Prediction https://developers.google.com/groups www.SandeepHegde.me
- 32. Fusion Tables • • • • • • • • Think: Google Maps + Excel/Sheets on steroids Aggregate disparate data in spreadsheet & visualize google.com/fusiontables sites.google.com/site/fusiontablestalks tables.googlelabs.com support.google.com/fusiontables/answer/2571232 developers.google.com/fusiontables/ support.google.com/fusiontables/answer/184641 https://developers.google.com/groups www.SandeepHegde.me
- 33. • • • • • • • • • Google APIs Android o developer.android.com Chrome (Chrome extensions, HTML5, Dart, ChromeOS, ChromeBooks) o html5rocks.com Google+ o developers.google.com/+ Ads (AdSense, AdWords, AdMob) o google.com/ads Maps, Earth, KML o developers.google.com/maps Drive o developers.google.com/drive YouTube o developers.google.com/youtube Commerce (Wallet, Checkout, Shopping) o developers.google.com/commerce Google TV o developers.google.com/tv https://developers.google.com/groups www.SandeepHegde.me
- 34. Your chance to WIN $ Make it to 2nd Round & WIN All Female-Teams - $3000 All Student-Teams - $1000 https://developers.google.com/groups www.SandeepHegde.me
- 35. And everyone here today gets $ That’s ₹1,20,000 ! Promo Code - gcpdc-in www.google.co.in/events/gcdc2013/ https://developers.google.com/groups www.SandeepHegde.me
- 36. Google Developers Live! (developers.google.com/live) https://developers.google.com/groups www. SandeepHegde.me
- 37. (developers.google.com/academy) • • • Content developed by Googlers Set of online classes spanning across various Google developer technologies Aim is to have curriculum based learning, beyond traditional technical document https://developers.google.com/groups www. SandeepHegde.me
- 38. <Thank You!> Connect with us ! Google.com/+SandeepHegde Website » » www.GDGBelgaum.com Google+ » » Gplus.to/GDGBelgaum Google Group » » Groups.google.com/forum/#!forum/GDGBelgaum Facebook Page » » Facebook.com/GDGBelgaum Twitter » » Twitter.com/GDGBelgaum https://developers.google.com/groups www.GDGBelgaum.com
Notas del editor
- Let's review what it looks like to build a traditional web app. You need Apaches front-ended with proxies, and a bank of databases with one master in the backend. Let's say you're psychic, got the correct amount of hardware/VMs. Let's also say you have an architect who built your network and multi-tier service layers perfectly. What about the unforseen stuff listed at the bottom? Also have you noticed that your app doesn't even show up on this slide? *This is just the setup.*
- The problem is that building an app is more than just the code. Why did Google build App Engine? They noticed that it took too long from concept to a web app available globally. The burdens had little to do with the app! It's all the sysadmin stuff such as the OS, database, web server, etc., that developers of *all* apps have to worry about. What if Google could take this pain point away?
- Goal: take all those little brown boxes and stick them into one giant one so users only need to worry about their code. App Engine is a scalable hosting platform built on Google hardware & technology. Remember the scalability & uptime discussed earlier? Your apps can benefit from the same performance. Use familiar tools (Java, PHP, Python, Go) to make things easy-to-build. Admin tools make your app easy-to-manage. The best part is that if you code your app in a scalable way, you don't have to do *anything*: Google infrastructure takes care of it all. Again, focus on your app, and let Google take care of the rest. Just don't compare App Engine w/IaaS services!
- Tell audience that before we get started, think about Google & scale and consider these numbers: - Size of Google's search index (in bytes) - # of hours of video uploaded to YouTube per minute - # of people (well, IPs) watch at least 1 video per month - Total # of HTTP "hits" for all App Engine apps combined - (outside of DNS issues) Has google.com been down? Ever get 500s or internal server errors? Google has thousands of people whose job it is to keep us up, available, and responsive. Now to the numbers which are public (not confidential)...
- Yes, last slide was example of out-of-this-world scalability Google provides, but as you can see, there's also have out-of-this-world security too. Google datacenter in Iowa pictured on left; on right is from Google Maps Street View of datacenter in North Carolina (access via bottom link if desired). In all seriousness, security is taken as paramount priority. Believe it or not, unless job-related, full-time engineers at Google aren't allowed to go to datacenters.
- Good for explaining general landscape to higher level audience. Cloud services are divided up into 3 categories, according to the Gartner analyst firm. Describe each level and optionally discuss your experience with vendors at each level if desired. SaaS == apps requiring web browser to access, i.e., online apps, not installed locally. Note: no control over the code (vendor's responsibility). IaaS == lease of hardware & storage. Users outsource computing resources to 3rd-party vendors; get expected services such as power, networking, cooling, etc. Users responsible for all layers b/w hardware & their app, i.e., operating system, database, web server, etc. Both SaaS & IaaS most well-known service levels. PaaS sits in middle... application hosting; potentially most flexible & powerful of the 3. Unlike SaaS, users control code. Unlike IaaS, PaaS handles OS, database, web server, etc. (vendor's responsibility). Can use PaaS to create SaaS apps. Between each level: gray area, i.e., force.com: while a platform, primarily used to create & host apps that access Salesforce data. Products b/w PaaS & IaaS more than HW but less than a platform... most are "Database-as-a-Service." When comparing vendors/products, stay within same service level. Makes no sense comparing App Engine with (Amazon) EC2 (apples vs. oranges). Better to compare EC2 w/Compute Engine. (Note: Google has products serving at all levels.)
- Let's take a closer look at Google's cloud. What is it? Speaker: paraphrase each bullet point: "It is a comprehensive...." (Steven Levy was kind enough to write some nice words about Google's cloud last year in Wired magazine [2012].)
- Because there's a JVM, other languages are supported... Scala, Groovy, Ruby running on JRuby, JavaScript with Rhino, PHP with Quercus, or Python with Jython. Native PHP support has reduced Quercus use cases, but Jython is useful when you have existing Java classes and don't want to port/rewrite to make them work with Python. Jython allows Python objects to talk to Java objects & vv as it's all Java bytecode at the end of the day.
- If there's a downside to cloud: all resources shared... accessing others' code or data not good, thus all apps run inside a restricted environment. Within sandbox, apps can't: 1) create local files, 2) open up (inbound) socket connections, 3) make operating system calls, etc. Not being able to make network connections sounds bad; no useful app can come of it. But instead of low-level building blocks like sockets where everyone has to reinvent the wheel, Google provides higher-level APIs: 0) Rather than connecting to port 25 (SMTP) to send email, use the Mail API. Apps can send email but also receive & programmatically process mail. Similarly... 1) XMPP API - send & recv instant msgs 2) URLfetch - communicate w/other online apps 3) Datastore (can choose NoSQL or relational DB) 4) Memcache API - datastore slower than local server due to redundancy although Python's ndb & Java's Objectify libraries autocache datastore fetches 5) Images API - basic manipulations like rotate, resize, crop 6) Blobstore - used for media files (MP3s, videos, etc.); datastore objects have a 1MB size limit; use Blobstore instead; also a Files API -- connect to Google Cloud Storage 7) User service... there are many choices for auth: a) unauthenticated, b) Roll your own, c) require users sign-in w/Google acct, d) Federated login -- users can login w/any OpenID creds: Google, Yahoo!, WordPress, AOL, etc. One other restriction not mentioned yet: apps must respond within 60s else terminated -- hogging resources in shared environment not allowed. 60s == a long time; humans can notice 0.25s delays. Need more time? Spin work off to a task & respond back to user. Tasks get up to 600s/10m. One API not listed here: Channel API -- maintain connection to user's browser; can notify them when job's completed. These are 9 of the original APIs. Many others not listed here. Channel is one, Search (prospective, text, timestamp, GeoPoint), MapReduce, etc.
- Requests come into front-ends & sent to “app servers.” "app master" manages the execution of your app, can start/stop app servers that handle requests (based on usage/demand). App servers farm of work to backend services just described on previous slide. Again, all the heavylifting is taken care of.
- Give tour of admin console: - Screenshot of your app's dashboard (circa 2009) -- many more features now. This app's traffic -- seems to avg ~0.2qps or 1 req every 5s, peaking ~0.5qps/1 req every other sec -- not great but not dead. Other graphs accessible via pulldown. - Can see how close to end of free quota, how much you've budgeted for, how much it's cost you so far today (resets every 24hrs) - Cutoff at bottom, but see most common endpoints of your app as well as which generate the most errors. - Many knobs & dials to tune your app, set permissions, view your datastore, adjust budget, access logs, etc.
- So how many people are using App Engine? More than quarter MM/mo; they've created more than 3MM active apps/mo. "Active" doesn't included the dead "Hello World" you tried a few years ago. In fact, half of all IP addresses touch (at least) 1 App Engine server on a weekly basis. Means you may be using App Engine without knowing it. Back to the scalability numbers discussed at the beginning of the talk... how many (HTTP) "hits" does App Engine get across all its apps every day?
- That's right, 7.5BB *daily*. This includes page views, and any HTTP request (GET, POST, etc.) In any given month, the system processes more than 4.5TT datastore requests. These Googley numbers and adoption in market helped push Google to taking App Engine out of beta to become a formal product (Nov 2011).
- App Engine has many users, some you've heard of, many you haven't. While big names like Best Buy, MTV, etc., don't run their entire websites on App Engine, they do use it for specific campaigns or secondary sites. We'll go over specific use cases to give an idea of what App Engine is used for.
- An early App Engine app: appears on most global social networks; play w/avatar daily. Regardless of whether you're interested in app itself, many are: exploded in usage. As of 2011, >64MM registered users (from 62MM in 2010). Some don't care about overall users; concerned w/daily engagement: ~3.6MM daily active users (DAUs) on FB & ~1.9MM DAUs on MySpace -- the latter has declined while the former has grown, so guestimate about 6MM DAUs on FB today. Takeaway: they have more than 64MM objects in their datastore.
- So far, we've just discussed web apps, but there is another use case: non-user-facing apps. Building a backend makes you ask the same question: host it yourself or go cloud? App Engine makes a great backend for mobile and gaming apps. Cloud is a safe place to store high scores, contact info, levels/medals/badges, etc., so users can get back into experience if phone lost/destroyed. Option to create a web version of app or some web access to user data.
- One example of an App Engine backend is Pulse, very popular app in iTunes & Google Play stores, yet very few know that it's got a Python App Engine backend. Another example of users touching App Engine without realizing it. Read more in case study PDF via link.
- App Engine can backend your game, whether web or mobile. Example: the Chrome version of Angry Birds needs to be served to users. They use App Engine. Many others also use App Engine.
- Some of the hottest apps use App Engine. Snapchat is similar to "an Instagram w/a TTL" that runs on App Engine. Songpop is a modernized version of "Name that Tune," and along with Google Cloud Storage, serves >18TB/day. They have 80MM registered users where at least 1MM are active daily.
- This feature automates the creation of a mobile interface for your App Engine app. Write your code following a specific pattern, and API endpoints will be established for your app. Run the accompanying tool, and boilerplate code will be generated for iOS (Objective-C), Android (Java), and Javascript to further ease integration.
- Summarize types of apps seen over last 8 slides (web apps, backends for mobile apps, game backends, social apps, extreme scaling on-demand, great for enterprise apps too as well as for academia) but also include some cases here. This is the best place for you to discuss your App Engine experience here.
- Now you're interested in App Engine... where to get started? - Get product overview info from first link - Get the SDK, docs, downloads, etc. from 2nd link - Create & manage their apps at the 3rd link - Access issue tracker, wiki, other downloads at 4th link - Keep up-to-date with Google Cloud Platform at their blog as well as their social outlets on Google+ or Twitter - Free training materials?
- Need to "try before you buy?" Not ready to download App Engine SDK yet? Experience App Engine development with just a browser window. Go to cloud-playground.appspot.com and clone one of the simple projects at the top. Press the little green run button to see the app run in an iframed browser. Update the code in the editor window, run again, and see your changes take effect!
- App Engine serves as a gateway to other Google (and non-Google) Cloud services. We already discussed how to integrate with Google Apps, so let's look at some others here. We already mentioned you can choose NoSQL or a relational datastore for your App Engine app. Both are also available outside of App Engine. The NoSQL native datastore is the Cloud Datastore while the relational MySQL-compatible one is Google Cloud SQL. At the bottom is another gateway to Google's cloud... for your data. Store all your data in Google Cloud Storage and ingest it into any of the services you wish to operate on that data: Compute Engine (virtual machine infrastructure service), BigQuery (large dataset analysis), Prediction (machine learning cloud service), Translate (programmatic language translations), or even non-Google cloud services.
- With apps that cannot fit within App Engine's restricted environment, requiring VMs, try Compute Engine which supports RHEL/CentOS & Debian. Can create private networks and firewalls with VMs. 3 storage types: Google Cloud Storage, local/scratch/ephemeral (which come & go w/VMs), or persistent disk (durable storage immune to coming & going of VMs). 3 ways to access Compute Engine: via web interface, command-line, or programmatically w/REST API.
- As mentioned earlier, Cloud Storage is the gateway to getting your data to other Google cloud services. It's pay-per-use and users can have an unlimited amount of data they can store with the service with a 5TB max size/object. Can choose storage based in US or EU, access via cmd-line, web UI, App Engine Files API, or programmatically via REST API. Also an SLA. Cloud SQL is (again) Google's MySQL-compatible relational database in the cloud. Access via App Engine Datastore API, or Apps Script or external app via JDBC.
- Google Cloud Datastore massively scalable original NoSQL datastore for App Engine, now available to external programs via REST API. Google Translate's API provides programmatic access to language translation. Access via REST API.
- BigQuery allows users to issue SQL-like queries across multi-TB of data & get results back in seconds, not hours or days. Use to analyze your massive datasets. Ingest via Google Cloud Storage or directly. Access via REST API or query UI. Check out the tour at cloud.google.com/bigquery-tour. Prediction API: machine learning service in the cloud. Uses multiple ML algorithms, and API finds best algorithm based on data type. Currently supporting "supervised learning" if you're familiar with ML. How does it work?
- Example of how Prediction works. Pass in a string, ask Prediction, get output. Seems like magic if you're unfamiliar with machine learning, but to arrive at this point, you needed to have uploaded data along with appropriate metadata (creating a training "models"), then query against that model with a new piece of data. Many applications for this, some of the more popular being: sentiment analysis, spam detection, fraud detection, consumer pricing, etc.
- Fusion Tables is a combination of Google Maps and Sheets/Excel. Take spreadsheet data and visualize them on a map. Can merge one or more spreadsheets into one final dataset to visualize. Can be used to identify geographic points, plots, etc. Used in some of Google's disaster recovery apps such as after the Haiti Earthquake (mapped medical facilities, types of patients handled, types of medicines available, etc.) as well as Japan tsunami.
- App Engine & the rest of cloud merely provide the foundation for your app. From here, explore other Google APIs to help augment and enhance the functionality of your app(s).