peter s. magnusson: so ofcourse, we miserably failed this morning to make sure thatthe blimp looked like this, from which the jumpingwas done. but we'll see whatwe do next i/o. all right, good afternoon,everybody. thank you for joining us forthis app engine overview. it's a real treat to be here. we have some fun newsto share with you. so for those of you out thereon your livestream, don't
touch that dial. and for everybody, and inparticular those on livestream, here's a link forthe google moderator for getting questions. and our suggested hash is#io12 and #appengine. so we'll be reminding you ofthis link for questions throughout. and we'll try to stay onschedule as best as possible to give room forq&a at the end.
so if by any chance you have noidea what google app engine is, this is whatwe strive for. we strive for developmentplatform in the clouds that makes it easy to writeapplications, simple to scale them to a global audience,and trivial to manage running them over time. the genesis for app engine wasthe internal development stacks at google, and a desireby the founding team to package them into a form thatlots of developers the world
over can use. since we launched in 2008, westayed true to this philosophy and success has followed. adoption of app engine has beenremarkably strong despite a few limitations. app engine launchedwith [inaudible] surprisingly short list offeatures, with a different approach to writing moderncloud applications. but it was truly a child ofthe new era of computing,
creating an opinionatedframework with large benefits to early adapters. since the launch, we've beenhard at work in fleshing out the platform, continuing ourquest for the ultimate cloud platform service. over time, as we continue toramp our investments in cloud computing, we continue to buildout our cloud products. in addition app engine, and alsoover the last year and a half, announcing products likebigquery, google storage for
developers, and googlecloud sql. in fact, traction has beenquite remarkable. so i have a coupleof fun numbers to share with you today. if we look at the month in thelife of app engine, we see over one million hostedapplications. so we recently passedone million. not all of them were written byeverybody in the room here, but thank you, developers,for using app
engine to develop apps. this is pretty awesome. got to get you guysgoing, here. yeah, i'm not diving for ablimp, but this is still pretty cool stuff. the main storage system bymany of these apps is our multi-data center highreplication datastore. and as far as we can tell, it'sthe world's largest third party nosql system.
in a given month, it processesover two trillion operations. besides brand namesand [inaudible] [? startups, ?] app engine powers hundreds ofthousands of applications that you've never heard of. in fact, we recently estimatedthe overall reach of app engine applications. and it's pretty breathtaking. by our math, of all the internetactive addresses that
are active in any given week--so of all the internet ip addresses that we see beingactive in a week-- over half of them touch appengine in any given week. we can't track how many usersthat corresponds to, obviously, because there'shundreds of thousands of applications doing different. but it's a pretty sizablefootprint. obviously, we're curiousabout what's behind these usage numbers.
so we look for patterns ofusage to guide us to what features to prioritize. with over a millionapplications, the simplest answer to the question of whatruns on app engine is everything. but that's not reallyvery interesting. we have seen some prettyinteresting broad patterns. and they are quiteilluminating. and in some ways, in hindsight,
they're fairly obvious. i'm going to mention a coupleof areas of particular app engine traction. the first one is sometimesreferred to as enterprise edge. so that's applications developedby traditional enterprises, but where thetarget is mostly external to the company. it can be to reach tens ofthousands of partners, or
millions of customers. the second is a fairly obviousarea, that of high tech startups, which i suspect is abig representation of google i/o participants, in particularones that are social or mobile dimensions. there's quite a number ofsuccessful smartphone and tablet applications that hadparts or whole of their back-end infrastructurerunning on app engine. the third one isnot so obvious.
and that's productivitysoftware. i'm gonna talk about thata little more later. but first, i would like toinvite on stage robert fea from a company that isa household name. [rimshot sound] [applause] robert fea: thank you, peter. hi, everyone. my name is robert fea.
i'm part of the lowes.comit solutions team. i'm going to take the nextseveral minutes to talk about how we're using app engine toprovide a better online experience for our mylowescustomers. so of those of you whoaren't familiar with mylowes, what is mylowes? it's an initiative that welaunched last year to allow lowe's customers tomanage everything about their homes online.
so they can manage and tracktheir purchase history, as well as manage usefulcharacteristics about their home, such as measuring outtheir room dimensions, or recording how much it coststo mulch their yard. and as part of our mantra tonever stop improving, we're going to be introducing a newfile upload service using google app engine that willallow users to upload digital assets into their mylowesaccounts. so we're going to walk througha quick demonstration of how
that works. as my colleague here is settingup, let me just walk you through a quick use casehow this might be useful. so say you were remodelinga kitchen. and as part of that remodelingyou need to buy a new refrigerator. you saw a new samsungrefrigerator that you really liked at lowes.com anddecided to buy it. and for some reason or another,you've had bad
experiences in the pastwith refrigerators. so you decided to buy thewarranty along with it. now, a lot of times withwarranty purchases, you'll need to have the originalpurchase receipt, as well as the warranty receipt in orderto have any kind of service done on a product. and if you have trouble trackingreceipts, like myself, this new featurewill definitely take the pain out of it.
so as you can see here, mycolleague logged into his lowe's account. he's going to go intohis home profile. and from your home profile, youcan see you can enter in all sorts of differentinformation about their homes. but for this demonstration,we're going to look at the photos tab, and thedocuments tab. so you can see here, youhave the ability now to upload pictures.
so say you wanted to upload apicture of the fridge that you just bought. now, keep in mind, all thisupload feature is being done through the app engine. so you took a picture ofyour fridge when you first bought it. and now it shows up onyour mylowes account. if you click on thefridge itself, you can make useful notes.
and you can zoom, also, inand out in the picture. ok, you can also have theability to upload-- in our scenario-- the warranty information. so if we go to thedocuments tab-- so say i have the warrantysaved on my computer. i just wanted to upload it tomy account and forget about it, until i need it. this is a pretty big file.
so we're giving users up to 200megabytes of storage space with file sizes rangingup to 20 megabytes. so now you have thedocument uploaded. if you need to ever referto it again, you can simply click the link. and it should show up. download, right there. and there's our warrantyinformation. so like i said, what are wereally using app engine for?
well, app engine provides us auseful set of restful apis that we can use to upload files directly into cloud storage. what else does it provide? we're using the concept ofservice accounts, so mylowes customers only need to sign inonce to access any information in their cloud storage. and i don't know if you werepaying attention, but we also leveraged the app engine apiimage generation features.
so any time a user uploadspictures into their mylowes accounts, we generate them. they also have differentsizes that we use throughout the site. and we also do some mime-typechecking. so we prevent users fromuploading harmful files into their accounts. why did we decide togo with cloud and app engine in general?
well, as you may or maynot know, lowe's is not a software company. so in order to make this kindof feature work in our own environment, we were lookingat potentially millions of dollars in upfront hardwareinvestment. whereas, if we use app engine,we're looking, worst-case scenario, hundreds of thousandsof dollars. and because this is a newfeature, if it does take off, we know that app engine canhandle however many requests
users throw at it, and scalewithout a problem. that's pretty much it for mypart of the presentation. i'm going to hand itnow back to peter. peter s. magnusson: thankyou very much. peter s. magnusson: softwareupdates are available for your computer. thank you, firefox. ok. think we'll skip through onthe upgrade [inaudible].
the cloud is interruptingmy cloud talk. did i need to get-- there we go. all right. all right, thank youvery much, robert. so it's actually not a jokethat robert looked at me. i actually am remodeling mykitchen at this very day. i actually got a text for mygirlfriend on the fridge that got delivered today.
so i was going to put in a jokehere about software, and getting the kitchen sink,because we actually bought it at lowe's. but i'm going tospare you guys. the use case of lowe's is a veryinteresting one because it leverages the tightintegration between google cloud, google cloud storage,and google app engine. so there's a lot of use cases--in particular, in enterprise edge-- that reallyare storage-related problems,
that you need business logicand processing and identity and authentication, and soforth, around storage issues. and we already have quite agood set of integration features, and expect to see alot more because we think this is a really important use case,of basically building logic on top of storage. and it's also, of course,a very good use case for platform-as-a-servicein general. because even though i'm suremylowes is going to have 10
million customers using this,the adoption rates are always going to be difficultto predict. so the usage patternsare going to be difficult to predict. and they don't really have tocommit to any particular capex spending for this. so if you remember my slide fromjust before robert joined me, the second area of usagethat we found particular traction for app engine is instartups, in particular, with
social or mobile direction. and a most excellent exampleis my next guest speaker. welcome on stage, elliot. elliot kroo: so hi. i'm elliot kroo, founder andengineering director at getaround, where we'redisrupting the transportation industry by enabling peopleto share their cars with others nearby. so peter ask me here to talk alittle bit about getaround,
and how we've grownwith app engine. i'm going to tell you a littlebit about getaround, and then how we've grown with appengine as a platform. so right now, there are abillion cars in the world. each car sits idle about 92%of every single day. they're literallyassets sitting unused all of the time. getaround is here tosolve that problem. car owners make money froman idle car that
they're renting out. and car renters can get acar when they need it. this changes the transportationgame, fundamentally, from ownershipto access. getaround is a marketplace. so when you log in, you canbrowse through full car profiles that owners havebuilt for their car. when you find cars that youwant, you can send out a request to that ownerasking them to share
their car with you. the owner can approve or deny. if they choose to approve it,they can send a digital key to you to get into the car withouthaving to meet the owner and exchange the key. so getaround started as auniversity project, and made its debut at a hackathon in2009, about a year after app engine launched. in two days and about four hoursof sleep, we built a
mobile app and a back-endinfrastructure to connect owners and renters, and thencall out to a piece of hardware connected to thedoor locks of the car that's being rented. this is actually one of appengine's greatest strengths. the ability to go in and takean idea all the way to execution, and launch aproduction web application in hours or minutes is somethingthat app engine has been really good at since day one.
there's no reconfigurationrequired. google handles allthe boring stuff. and we can focus on execution. in 2011, everything seeminglyfell into place for us at techcrunch disrupt. so techcrunch disrupt is a majorstartup competition. it's a pretty big opportunityfor us. in our case, we actually wenton to win both the main vc-judged award, and theaudience choice award.
we were actually double-digitpercentage of all the twitter traffic during the main event. so that led to massivepublicity. a 30x increase in trafficover that one and a half hour period. and best of all for me, the hugeopportunity for downtime of our service right whenwe needed it most. ultimately, it is me who'sresponsible for keeping the website up.
and right then, i was busygetting drenched in champagne. so you can guess how fasti was paged with our site going down. it was literally never. app engine was great. it over-provisioneddefensively. and our latency during this timeof huge traffic went down rather than up. so app engine has actuallybeen pretty cool.
in the last year, we've maturedas an organization, both on the engineering sideand as a business. and we've grown a lot. right now, we actually have aninventory of thousands of cars, ranging from nissan leafsto tesla roadsters. and actually, we don't just haveone tesla roadster, we now have seven listed onthe site that you can rent out at any point. and as we've matured, app enginehas grown as well.
in 2009, app engine was reallygood to start on. on the other hand,it had a lot of things that were missing. it had no sla. it was missing the reliabilityof the high replication datastore when wefirst started. you couldn't even processrequests for longer than 30 seconds. there was just noway to do that.
over the last several years,the app engine team, one by one, has been solving everysingle one of these limitations. so now, with python 2.7 support,we can use a wide variety of external librarieson python. we use a mapreduce pipeline nowto power all of our weekly analytics and report generationover our now massive data site thatwe deal with. and recently, we've been able tomove search, which was our
last major component runningoutside of app engine, or in our infrastructure from anexternal third party index server, to our own customin-memory time series database, sitting on back-endsright next to our front-end instances in the samedata centers. so just fairly recently,actually-- it's pretty exciting-- we're now able to runour entire product, from end to end, from the web appand our mobile applications infrastructure, to being ableto call out to our hardware
that we've built, withoutcompromise. the whole system is nowrunning on app engine. this last 2 and 1/2 yearshas seen a remarkable transformation. we've seen a remarkabletransformation in the way app engine has run. it started as a young platform,great for launching new products, to a mature androbust platform that we're proud to run all of ourinfrastructure on top of.
and we've grown as well, froma hackathon project to a successful businesswith customers who love what we're doing. we're now 40 people strongand growing. so if you're passionate aboutengineering and changing the world, we're looking formore people to join us. so thanks so much, peter. peter s. magnusson: thankyou very much, elliot. all right, thankyou very much.
so i was tempted to insert ajoke about engines here. but i will resistthat as well. so what we've seen are two greatexamples of successful app engine used. the first time was enterprise,customer-facing application. and the second one was a mobilestartup created in the intensity of hackathons, andthen growing smoothly to be a successful company. and that's extremely exciting.
the third area that i wanted tohighlight today is a little subtle, which is enterpriseproductivity. we have customers developinghundreds of internal applications on a per-companybasis on app engine. and in some cases-- including google ourselves-- thousands of applications. it turns out that much of thework that we've spent to make app engine applications verysimple to own and manage--
we strive to make it trivialto be actually running it-- in effect, translates into avery low product lifecycle management cost. and this is very attractive tocompanies that want to be able to build and run lotsof applications. so our next speaker is mani,who is from orangescape-- come up on stage-- who willtell us a little bit about their workflow technology. mani doraisamy: thanks, peter.
so my name is mani doraisamy. i'm the co-founder andcto of orangescape. i'm here to talk abouta new workflow product called kissflow. now, what's this new product? let's step back a little bit andunderstand why kissflow. now, most of us in thisroom already use google apps, right? it's not just us.
four million businesses arealready using google apps. so google apps is collaborationat its best. if you look at mail, docs,calendars, all of them allows you to do collaborationon cloud very easy. you can even put togethervery simple data capture applications on top of googleapps and spreadsheets, especially the spreadsheets and[inaudible] part of it. but beyond that, when the userswant to implement a slightly more sophisticatedenterprise application, let's
say a workflow applicationlike a recruitment application, or for example,a travel reimbursement application, then we expectthem to be superheroes. we want them to learn python,java, understand the data store concepts like bigtable ontop of google app engine. now, we thought, how will itbe if you can leverage the power of google app engine andmake the workflow product as simple as using google apps? that's basically thisnew product.
today, we're excited to announcethe availability of kissflow, a simple and smartway of building workflow applications for google apps. it's the first workflow product exclusively for google apps. and it leverages the full powerof google cloud, which means it runs on top of googleapp engine and cloud sql. and it integrates with googledocs, and also google contacts for collaborating.
and all of them come withinyour workflow. that's the beauty of it. let's take a quick look at howworkflow can be built on top of kissflow. ok, so i think we are up on the screen, on both the screens. so this is how the workflowlooks like, building process looks like. so let's say, for example,this company, dark knight
enterprises, wants to clean uptheir travel claim workflow. it asks for bruce wayne, who'sthe head of the department, to create a workflow for automatingthis process. so kissflow gives you a verysimple, five-step process to create a wizard. first, you start off withnaming the process. and then you go into creatingthe fields in the process. like, for example, in the caseof a travel claim form, you have the purpose of travel,which is what you capture to
claim the amount. and then you havethe description. and you also have fields, likefor example, amount, the date on which the amount wasspent, and so on. once we complete creating thisform, for example, you can add amount, which is basicallya number field. and i can also make thisa required field. and you can save this field andthat completes how expense claim forms will look like.
so once i complete that, i cango and define a process, a workflow process. a workflow process for atravel claim would be, typically, a two-stepapproval process. like, for example, first, youmight want to send it to the department head for approval. so let's add department headapproval, which we will assign it to two users. one is, obviously, brucewayne himself.
and then we will assignit to another user. like, for example, in this case,we will assign it first to harvey dent. and then we will assignit to bruce wayne. so you can see that we are nottrying to integrate anything with google apps. all of the users getsynchronized directly from google apps into kissflow. similarly, we will add thesecond step, which is for
finance approval, becausefinance team would want to do the approval themselves. so in this case, we will assignthis to a google group. so anybody in this group canapprove this request. again, you can see you cancentrally manage all the user management and group managementwithout having to define roles, and manageall of those things. so once i am done with theprocess creation and the form creation, i can publishthis process.
and this is how itlooks [inaudible] in the run time. so you have a very similargmail-like look and feel. and i can initiate therequest where i can see the expense claim. and i can initiate the expenseclaim request. so this is exactly how yousaw in the form design [inaudible]. so i can enter theprocess purpose.
for example, i have broken mycar, and then i can specify its official expense. i don't know how many peoplewill claim breaking a car into an official expense. we'll put some amountas 4,000. and i can also attach a documentdirectly from here. for example, i can attach atravel document, so that the next set of approvalscan look at this document and do the approval.
so once we are done, ican submit this item. so this item, from theinitiator, will move into the next step. in this case, we defineddepartment head approval as the next step. so i can go into approvalrequest. and then i can see the progressof my entire process. for example, i have initiatedfrom bruce wayne. and it's waiting for departmentapproval.
so bruce and harvey are thepeople who can approve it. so i can click on approve. so if i click on approve, itgoes into the next stage. this way, i have completed myautomation of the process. and i can also track to theprogress of the process, without having to doany coding at all. that's the purposeof this product. now, it's not just abouttracking of the workflow. you can also do reportingon top of this workflow.
for example, if i go to areporting tab, i can look at the items as to how thesethings can be filtered and reported. so with that, let me go intothe summary of kissflow. kissflow is a very simple andsmart way of building workflows, no technologyknowledge required. but it also seamlesslyintegrates with google apps. so you get all of thegoodies of google docs, mail, and contacts.
but it leverages thepower of google app engine and cloud sql. so when you log in, you havea separate google database, which is a cloud sqlallocated to you. so you don't have a problemof sharing. it's standardized for all of theenterprises, because most of the enterprise use rdbms. so you get the power of googlecloud, as well as the power of cloud sql.
so thanks for your time. we are at sandbox. you can always visit us formore demo because there is quite cool stuff that'saround there. and you can also try it outat www.kissflow.com. thank you. peter s. magnusson: ineed the clicker. and now the moment you'veall been waiting for. we have a couple of improvementsto announce to
app engine today. so for that i'd like towelcome on stage, greg d'alesandre, the lead productmanager of google app engine. take it away, greg. let's hear it. greg d'alesandre: thankyou, peter. greg d'alesandre: so i knowwe're running out of time. so i'll try to get throughthis quickly. we've made a lot of improvementsto app engine.
but i wanted to give you alittle bit of insight of what's been going on with appengine since we came out of preview in novemberof last year. we've continued our rapid paceof innovation, continuing to produce approximately onerelease per month, including such things as python 7, backupand restore, traffic splitting threads, but a numberof improvements that have happened over the courseof the last six months. today, though, we wantto talk about 1.7.0.
in 1.7.0, we have a number ofthings coming into general availability that people havebeen requesting for, in some cases, a very long time, as wellas some new surprises. the first i'd like to talkabout is ssl for custom domains is finallygoing into gae. greg d'alesandre: thereare two flavors of it. there is sni, which supportsthe majority of browsers. but for some people, some oftheir applications, it doesn't support it.
so we also supporta vip option. sni's a little cheaper. because vips, we actually needto give you a dedicated ip address, which, if you canbelieve it, is expensive. single vips and sni can actuallysupport multiple applications by use of wildcardor multi-domain certificates. all right, i'm going to starttalking fast to make sure we get all the informationout there.
cloud sql, again, one of themost requested features for app engine, today is goinginto open sign up. so now, anyone canuse cloud sql. cloud sql's a mysql database inthe cloud, easy management, so zero admin configuration,synchronous, geo-replication. it's already being very heavilyused by a lot of our customers, includingorangescape, as you just saw. and there is zero admin fromconfigurations backup. next, the search api.
so we released our experimentalsearch api approximately a month ago. i just wanted to highlight thatexperimental search api is out there. and as of 1.7.0, we've actually added in geopoint support. so you can make location-awaresearches. this is one of the biggestrequests we had for search. and we just added itin this release.
the search api itself allowsfor the indexes are schemaless, giving youscalability and flexibility in your search indexes. you can do things likecustom scoring and snippets, et cetera. next, google app engineeuropean data centers. so google app engine isnow being hosted-- greg d'alesandre: google appengine is now being hosted out of both the us and theeuropean union.
so this is for customers whoare interested in running their applications out of theeuropean union, either for performance reasons, for theircustomers in other parts of the world, or for compliancereasons. when you run out of the eu, yourapplication instances run out of the eu. but all of your end-userdata is stored at rest in the eu as well. this is launching today forpremiere customers.
simultaneously, we also havelocal contracts available for premier customers in europe, aswell as local currencies, such as british pounds, euros,yen, and australian dollars. greg d'alesandre: [laugh] there's some internationalpeople out there that are very excited about that. next, pagespeed servicefor app engine. let me show you a littlebit of a demo on this. this is actually the blog for anapp engine customer, pulse.
what you will see here isthe before and after. so you'll notice-- if i can pause it-- after about1.8 seconds, everything had rendered on theirblog, initially, of what they needed. and then full rendering wasdone in 8.2 seconds, as opposed to the 11 secondsthat it used to take. what pagespeed service does,it's a service we launched a little while ago atgoogle in general.
but we've now made it availableto app engine that you can enable witha single click. it automatically optimizesperformance, such as image optimization, deferringjavascript loading, inlining css in javascript, rewritingcache headers. it does all of the stuff youneed to do to increase performance. and let me move on from that,because who knows what's going to be on that youtube?
yeah, there we go. the next thing i wanted to talk about was cloud endpoints. this is the last thingi wanted to bring up. but it's, frankly, one of thethings i'm most excited about. it's really in the spiritof app engine. what we brought you with cloudendpoints is a really easy way to make mobile backends, andbackends for web-based applications using app engine.
so it exposes a rest apifor android ios and web applications. there's a javascript clientlibrary, strongly typed client libraries in java andobjective-c, as well as we take care of all thatoof2 that no one wants to learn about. the whole goal is really tomake it so that if you're building a mobile applicationand you want a backend on your mobile application, it's reallyeasy to use app engine
to get that done withouthaving to learn all the details and do any ofthe heavy lifting. in many ways, it's thepromise we've always wanted with app engine. all right, that's 1.7.0in a nutshell. and i don't think i've evertalked that fast before. but that's 1.7.0in a nutshell. we wanted to save a little bitof time for questions. and i know there are probablya couple out there.
so the last thing i want todo, as we're answering questions, is please come visitour partner sandbox. there's a number of customersthat are using app engine and partner sandbox. you can talk to app enginedevelopers in the sandbox. we also have crazy plushiesover there that you can probably sweet talk your wayinto, t-shirts, custom chocolate bars, and gel skins. it's a lot of swag this year.
so i think we have acouple minutes, if people have any questions. i see someone getting up now. although, he might be leaving. peter s. magnusson: dowe have a microphone? greg d'alesandre: there we go. audience: hi, i hada question-- peter s. magnusson: start withan audience question. go ahead.
audience: i had a questionabout the control over synchronization acrosscontinents. do you have the ability to,for example, block an app engine from being replicatedover to the eu? greg d'alesandre: is yourquestion, if you currently have an app engine in the usand you want to move your application over to the eu,how do you do that? audience: well, we wantto restrict it to a particular continent.
greg d'alesandre: to both? so as of today, the way it worksis you choose, when you create your application, if youwant it in the eu, or if you want it in the us. so we don't currently have a waythat your application can be shared across both places. although, you could build yourown structure for essentially storing data and routingtraffic into the appropriate location.
peter s. magnusson: and to beclear, that's a feature. so that's very intentional. in fact, we had to doengineering to not have data going back and forth. because we want to be ableto-- for all european customers-- to be clear that, unless theysay very specifically otherwise, the application anduser data resides in the eu. audience: i'm a federalgovernment customer, which is
why i was asking. because if we wanted to createapp engine applications for enterprise, we wanted to makesure that it remains within the continental us. greg d'alesandre: i'm sorry,i don't think i got that. audience: we wanted to makesure that the application remains in continental us. greg d'alesandre: ah, yes. oh, yes, absolutely.
sorry, that's the feature thatpeter was referring to. we make it very clear, youchoose either us or the eu. we don't automatically shareyour application anywhere. you're making an explicit choicewhere you want to host your application. audience: ok, thank you. peter s. magnusson: so we havesome moderator questions. so i'll read them. first one, "where do you thinkgae pricing is heading?
as developers leverage theplatforms more and more, pricing certainly becomes oneof the main selling points." and stay tuned. we are working on some news onthat that did not make press line for google i/o. butwe're very aware of it. greg d'alesandre: let's beclear, good news on that. peter s. magnusson: good news. yeah, let's be very clearon that, yes. greg d'alesandre: i was onstage last year with some
other news. peter s. magnusson: yes. yeah, yeah, yeah. so no, we're notraising prices. we're looking at various formsand more control for customers, and more options. so it basically, toallow as your application becomes bigger-- what we found is that whenyou're a startup, and you're
early, you're building smallapplications, you're not very sensitive to inefficienciesof your design. but as you scale up, app engineprovides all these wonderful ways of shootingyourself in the foot because it's very easy to use. it's very easy to start usinga lot of resources. so we find that largercustomers with larger footprints need to have moreoptions to trade off between features and capabilitiesand price.
so stay tuned on that. we hope to have updates onthat no later than q3. greg d'alesandre: should we takeanother live question? peter s. magnusson:let's do two, one. greg d'alesandre: oh, sure. peter s. magnusson: becausethis is all the livestream folks as well. so second one is, "app enginejust released or queries in the new sdk.
are these true or queries or domultiple queries then merge the results? if so, how does the billingwork on these?" so let's do an audiencequestion. [laughing] greg d'alesandre: i tried,man, i tried. i'm looking down to the appengine team in the audience. actually, that's a detaili don't know off the top of my head.
peter s. magnusson: everyone islooking at somebody else. we'll get back on this. greg d'alesandre: as they'retexting the people who do know the answer to that question. audience: so you're not goingto get away from answering cost information that fast. actually, my question has todo with how should large companies deal with deploymentsof app engine applications, in terms of cost,because they're unknown.
basically, there is theapp premier, or the app engine premier. there is a bunch of costsassociated with anything you do. and at the end of the day, budgeting-wise, it's a nightmare. how do you even know what thisapplication is going to cost? and should you have done it inhouse, versus send it out? are there any tools, forexample, if you use django
inside to be able to instrumentthese things, and be able to at least get abaseline, or an idea of what this thing's going to cost? greg d'alesandre: so in general,the best way to understand how much ourapplications are going to cost is by running it andload-testing it to get an understanding of whether it'sthe number of users you have, or the number of calls, orwhatever is the metric you're looking to scale to understandhow many that you can handle
with an individual instance. the way app engine pricing worksis, either you're paying for api call, which are veryset, or you're paying for instances, which are acombination of cpu and memory. and it's how we've runyour application. because the instances of a codeyou write, the only way you can really know how manyinstances you're going to need are by load-testing it andseeing how your application does behave under load.
so the way to understand andpredict how much app engine will cost is by, essentially,running your application there, and testing it, andseeing what it uses. it's part of the reason we givea free quota, so that people can test applications outthere to see what it would take to run. peter s. magnusson:so i'd like to add two things to that. so we see these things in theenterprise space falling down
in two broad areas. one is the load-testing, wherewe're looking at ways to make it easier for you to buildload tests and cost estimators, and so forth. we're looking at those things. and the other area is around ofcontrol of costs, which as your developer team-- especiallyin enterprise case-- starts growing up,you need to have-- you know, in app engine, if youcreate a premier account,
basically you havevery coarse-grain controls in the budgets. and you need to have morefine-grain ones, so that some arbitrary contractor that youbring in doesn't change a set of indexes. and before you know it, you'reburning through 100k more a month than was necessarybecause it wasn't being caught, and things like that. so those are the two areas thatwe're looking at, that
we're working on bringingyou things. one is to make it simpler. you can do it today, doall the benchmarking and measuring yourself. but there are lots of thingswe can do to make that simpler for you. and the other one is to providemore fine-grain controls around budgeting. audience: all right, thanks.
peter s. magnusson: want todo another audience one? because i'm scared now ofthe online questions. greg d'alesandre: well,any news on using ssl with custom domain? yes, there is news. it's now gae. i love answering theeasy questions. peter s. magnusson: yes,we now have it. [inaudible] " because oflimitation of google app
engine, many useful pythonlibraries couldn't be used on the google app engineplatform. is app engine team planning someway to solve the problem to prevent developers keeprebuilding the wheel?" yes. peter s. magnusson: questionfrom the audience. audience: i'm looking for acouchdb type replacement. so regarding the enterpriseedge, i'm really interested in the enterprise synchronizationacross europe and the us. but i'd also be able to liketo synchronize into a
disconnected device whenit's disconnected. so if there's a pilot flyingaround in a 747, is carrying an android, when it landssomewhere, i'd like to be able to synchronize. and of course, when it's up inthe air, you can't do that for different reasons. same for precisionagriculture. the same for, actually,military logistics. peter s. magnusson: all right,so those are sort of two
different areas. synchronization between the euand the us, we are for now not looking at any particularfeatures. you need to codethat yourself. and the reason for thatis very intentional. it's that you own the legal,and whatever consequences there are of those algorithms. so we don't want to be in asituation where a corporation in europe, who isjurisdictionally required to
keep end-user data locallybecause of some setting in some dialogue box somewheresuddenly got synced over to us supreme court jurisdiction. so this is actually a featurethat we explicitly want to make the developer problems, sothe developer can decide on the policy. so that google canjust say, no, the developer's decided for. and it's the developer'sresponsibility.
the other one is synchronizationbetween app engine and mobile devices. was that the other part of it? audience: yeah, and really,how would i synchronize [inaudible] from app engine to adisconnected android device? peter s. magnusson: right. so for us, that's higherup in the stack. so there are lots of other cooltalks at google i/o about how to do mono-webapplications.
i would direct you to the talkthat dan is doing on dart, and using it. so we have various web stacktechnology stuff going on to make that simpler. from the app engine pointof view, that is the application layer. audience: ok, thanks. greg d'alesandre: and speakingof talks, i would highlight, check out all the sessionsaround cloud platform.
there's a session tomorrowmorning around cloud endpoints to go into a lot more detailabout how to use them, and how to build them. i did mention i wasexcited about it. so i'm going to mention thattalk over and over again. there's also a talk on fridayabout optimizing your app engine application. so there's a number of talksover the course of i/o around using app engine.
i think there's a python 2.7talk tomorrow as well. peter s. magnusson: want totake an audience question? greg d'alesandre: sure. peter s. magnusson: oh, we'regoing to alternate. audience: i run a datacenter in asia. do you have any plan? greg d'alesandre: do we haveplans for asian data centers? audience: yes. greg d'alesandre: wasthat the question?
peter s. magnusson: we havenothing to announce today. so one of the things i wantedto emphasize is that app engine runs on manydata centers. so we don't have asingle point of failure on a data center. so as opposed to some cloudproducts, we can't say we're in a region just because there'sone data center there. we have to have several. and so we have to have apretty large footprint.
so we currently have sortedthat out in europe. and we've said before with hrd,we copy, we make, we can handle more than one datacenter failure. so we're running at a set ofdata centers that are spread apart over multiple countries. and we've been doing usfor several years. in q4 last year, we went out ofpreview and became a fully supported commercial product. and this year, we'reannouncing europe.
so you can extrapolate fromthat curve on what we're likely to be doing. one thing we have said is thatjapan is app engine's second-largest customer,which is awesome. so asia is very big. so we'll take an online onehere. "could you please provide the roadmap to improvethe datastore backup and restore functionalities, inparticular the restore by namespace?" we are workingon this as well.
greg d'alesandre:we are indeed. peter s. magnusson: nothingspecific to announce today. greg d'alesandre: and i didn'tmention it as part of 1.7.0. but as part of 1.7.0, thereactually was an improvement to backup and restore in order toallow you to restore to a different app id afteryou've done a backup. that came out in 1.7.0. i just gave the highlights. but you should definitelycheck out the
release notes for 1.7.0. there's a ton of newstuff in there. but the specific question aroundbackup and restore for namespace, we've definitelyheard before and we are looking at. peter s. magnusson: "does appengine plan on integrating with any version controlsystem such as github, project, or subversion?"we have looked at this in the past.
we've talked to some of theseplayers in the past. we're probably going to havea second look at that. it's something that makesa lot of sense. so i think the short answer is,yes, we plan on developing integrations, or facilitatingfor integrating with version control systems. we want to take [inaudible]? audience: any plansfor support of node.js, or other languages?
peter s. magnusson: yes,more language supports. yes, we want to add morelanguages to app engine. and we're working on it. we have nothing more toannounce at this i/o, unfortunately. another online. "app enginecontinues to be compared to traditional relationaldatabases. do you see google makingit even more easier for developers to transition byadding features to app engine,
documentation, use cases,et cetera?" yes, i think we're doingquite a lot. so the usability of thedatastore, of the google nosql solution, i think, over time hasbeen adding features and reducing the restrictions thatare fundamental, that have been viewed as beingfundamental between sql and nosql. i think we're going to continuedown the path if we take the 30,000-foot view ofcloud-based sql system
becoming faster and morescalable, while at same time, cloud-based nosql systems slowlystart shedding the historical limitations of whatsort of queries and processing that you can officiallydo against them. and then, in the not too distantfuture, i think, actually, we're going to endup having not much of a difference between them. so one of things that we'retrying to do with app engine, with the addition of googlecloud sql, is not
just sql, per se. but it's to provide mysqlinterface that has a lot of aspects that people arevery familiar with. so we're trying to create anenvironment in app engine, where if you want the veryscalable in terms of lots of queries, of the types thatweb applications do, we can scale great. whereas, if you have thisaccount data, or internal application data that requiressql reporting, or things like
that, you can put thosein google cloud sql. so i think what you cananticipate us doing in cloud in general, is to continueto improve datastore's capabilities, and working onreducing or minimizing the restrictions that nosql havehistorically done, while at the same time improving theintegration with sql. but for a long time, i thinkthe best way of building applications is to think about,what data naturally resides in memcache, whatnaturally resides in a nosql
part, and what naturally residesin the sql part. want to take a-- greg d'alesandre: yeah, let'stake a live question. audience: every app enginedeveloper in the enterprise eventually has a conversation,usually with boss of the boss of the boss of his boss, wherethe assistant executive vice president says, but mydata is precious. it's mine. how can i trust that google willnot take it, and do what
we're doing, but better? so what is the answer? what are the guarantees? greg d'alesandre: well, a coupleof the guarantees we make are illegal ones. if you read our terms ofservice, it does say what we can and can't do to the data. i know that there are a lot ofpeople have asked a similar question of, like, are you goingto take my data and put
it into a search index and makesearch all that better? first of all, i think we'd havea hard time understanding your data to try to put itinto a search index. but secondly, contractually,we can't. we basically say that we can'ttake your data and then re-share it. we essentially can use yourdata for the purpose of providing you your application,not for essentially anything we want.
but this is one of thetransitions that's going on in the world right now, is as datais moving into the cloud, some people get anxiousabout it. and the best that wecan do is show that we've never done that. we've never implied we'regoing to do that. we've never hinted we'regoing to do that. and we have contracts sayingwe can't do it. beyond that, other than me goingand talking to them and
saying, no, seriously,seriously, we're not going to do it. you know, it's hard to makemore guarantees than that. peter s. magnusson: over thelast year, i've been on a number of panels and discussionsaround the world where variations of thistopic comes up. and i've been on stage invarious combinations with pretty much all the other largepublic cloud providers, all the names you'veall heard of.
and there's a pretty strongconsensus in the industry-- of at least us vendors-- that we're seeing all of ourenterprise customers adjusting to the absolute oppositepoint of view. which is that the enterprisesstart trusting the public cloud provider to manage theirdata more than their own capabilities of doing it,simply because we live and die by this. i mean, google fundamentally,from the start, has had a huge
element of handling privacyimplications, legal implications,cross-jurisdictional issues about all the data that's ingmail, all the data that's in docs, all the data that we'recrawling everywhere, all the various challenges we've hadwith things like street view, and so forth. so google's dna, from the groundup, is totally even over-sensitized tothese issues. so actually, one of thereasons we've had--
maybe i even shouldn't saythis-- but one of the reasons we've been challenged withadding more languages to app engine, is precisely because ofinternal security concerns. so we have so many layers ofapprovals and review and audits and design commentary,and so forth. and it's very difficultfor us. we can't just start buildingshit and running it on our data centers. it's not allowed.
it's a public fact that googlehas over 300 full-time engineers that all theydo is security. so whenever you read about thevarious security breaches that happen to companies, you neversee it happening with the large public cloud providers,because that is our bread and butter. but that said, as anybody whoactually knows things about security, there's no such thingas the 100% guarantee. but this pervades allof our activities
and building services. and one of things i would sayto your boss's boss's boss's boss is that almost 50% of thefortune 100 companies' sec filings are now doneon web filings, which runs on app engine. so i've been on numerousconference calls with cios of fortune 100, and a couple ofcios from fortune 10 companies and walked them throughthese issues. and what tends to happen isthat there's push back.
and they don't quiteunderstand it. then they realize, ok, thepublic cloud is, if anything, safer than runningit yourself. it's very, very difficult tohave high security yourself. it's a little bit likedriving versus flying commercial airlines. you think that you're saferbecause you're in control. the reality is, that thatpilot's probably a better educated flyer than you are.
should we cut it right there? greg d'alesandre: yeah,we could do one more. peter s. magnusson: one more? let's look which one itis before we do it. "logs of the app engine areclose to impossible to use. are there plans to supportbetter search and browsing capabilities?" oh my god, yes! greg d'alesandre:yes, exactly. absolutely, without question.
peter s. magnusson: actually,when i joined google, this was one of the first things. i think after six weeks i said,can we please add better logs processing systems? so yes, we are workingon a lot of stuff. and in fact, i think you'regoing to see us leapfrog from one extreme of havinga pretty-- yeah, i'm not going to usederogatory words about our own product-- but challengingenvironment for managing and
searching and analyzing largelogs, to the other extreme, where we plan to have the bestlogs management support system on the planet. you should expect googlebigquery to be a big part of that. thank you very much,everybody. greg d'alesandre: oh, yeah. code lab, when's code lab? there's a video of a code labshowing how to get your app
engine logs into bigquery, todo analytics on your logs. that was a code lab thathappened earlier today.