BRETT SLATKIN: And now, I'm going to give it back to Kevin
to tell you more about it.
[APPLAUSE]
KEVIN GIBBS: Thanks, Brett.
That was great.
Woo, brisk night.
All right, well, now I'm going to go back
into the five components I talked
to you about a little bit earlier,
the five big components in the App Engine stack.
I'm going to dive down to some more technical detail now
to get into some more details of the product.
So the first of our five components
is they're scalable serving infrastructure.
We took this photo earlier this morning,
where the team was backing up before the launch.
Our scalable web service infrastructure
is a big part of App Engine.
It's a distributed, low-overhead system for running your code.
When you submit your code to us, as you saw Brett do,
it's pushed to a number of fault-tolerant servers
running within our data centers.
We handle all the work of connecting the request down
from the user to a running instance of your code
within the data center.
Now, when I say that the system is fault-tolerant,
what I mean is that, across our servers that we put
your code on, any one of them could
fail at any moment in time.
And we will still connect your request to one of our servers
and still be able to serve it.
It's part of how Google does infrastructure.
And so another aspect, which sort of follows
from that, about the way that we serve your web apps
is that it's fluid.
We don't ask you to reserve resources upfront.
You don't have to tell us how many CPUs you want,
how many machines you need, or anything like that.
Instead, we scale and move your application in response
to demand, in response to load.
So that's the scalable web serving infrastructure.
Again, a big part of the goal of App Engine
is to make everything easy.
So that's one thing we just take out of the equation
for you to make easier.
Now, our second big component is our Python runtime.
As I mentioned, Python is the first supported language
with App Engine.
However, I say the word runtime, because our language support
in App Engine is actually modular.
All the same infrastructure that you're seeing here--
the set of APIs and the main console-- all of the tools
that we're providing for you are generic,
and they apply to multiple languages.
So we can drop new languages in later.
Now, the Python that we use with App Engine
is the same Python that you've grown to know and love.
There are a wealth of third-party modules
and libraries that you can use with them.
And in short, we want you to be able to use any code that you'd
like with App Engine.
We don't want to restrict you to any specific thing.
In fact, we don't want to restrict you
to any specific type of HTML, or CSF, or JavaScript,
or content type, or anything.
We want you to be able to create any sort of web app
that you can think of on App Engine.
So the next big component that we've got is our SDK.
This is the environment that you use to develop an app locally.
It's what you saw Brett use just now in the demo.
We're releasing it today for Linux, Mac, and Windows,
but it's written in pure Python.
So anywhere that you can get a Python interpreter running,
you can likely get the SDK running.
Now, the big benefit of the SDK, why I really like it,
is how it cuts down the code-compile-test cycle
for you.
We don't require you to deploy your code to our servers
each time you want to test it out.
Instead, you just run it locally,
using the editors you're used to, the tools you're used to.
And your changes show up instantly as you're coding.
I think this brings a lot of the fun back to programming.
So our fourth component is the admin console.
Right here is a screenshot of it.
This web-based admin console is a big part
of the simpler alternative we're providing for you.
In essence, we're actually providing you
a simpler alternative to the whole LAMP stack.
And the admin console is what ties that together and provides
you all the tools you're used to using.
It allows you to see the status of your application.
It allows you to control who can administer the application,
add other users as admin so that they can upload new versions.
It allows you to control which version of your app,
if you have multiple versions, receives most of the traffic.
But it also provides a number of additional tools
that you may be used to using in different forms.
That includes tools for looking at your request logs
and your application logs, a Data Explorer,
which is our alternative for a SQL administration tool.
It allows you to look into your data
and check on the properties, add new entities, and so forth.
It provides an administration interface
for hooking up a domain to your application.
You don't need to run just on the default app spot domain
that you saw.
And it also provides some stats, which
are collected in near real time, which tell you
how much traffic you're receiving,
what errors you're receiving, and what URLs you're receiving
them on, and so forth.
So our fifth big component is the datastore,
which is our persistence layer.
The datastore, it's a schema-less object store that
supports millions of entities.
Under the covers, though, what's interesting
about the datastore is it's not implemented with a clustered
SQL database, which is how you would usually provide
a large data storage layer.
Instead, it uses Bigtable, which is
a piece of scalable infrastructure
that we use here at Google.
Now, you can read some papers online about Bigtable
if you want.
They're fascinating.
But the short of it is that Bigtable
is a horizontally-distributed scalable system that, again,
is fault-tolerant and spans thousands of machines and tens
and thousands of disks.
It automatically reacts to hotspots,
moving your data around as load changes.
So the fact that we're using Bigtable here, though, and not
SQL is a big difference.
It's a big departure from what people are used to.
And we know that getting used to this new way of doing things
and this new methodology is going to take
a little getting used to.
There's some new tools that you have to use.
There's some new ways you have to program similar to the ones
that you saw Brett use.
Eventually, however, we think that this will pay off.
We think that you may actually come to like the system
a little bit better.
One big advantage of using our system in the datastore
is that it's schema-less.
If you want to introduce a new entity type,
or you want to add a new properties to your entity,
like you saw Brett do, there's nothing to it.
You don't have to go and update your schema,
or deploy something new, or break out.
It's just code.
So again, it gets back to making the whole thing really easy
to do and allowing you to just write your code.
So now, actually, I'm going to dive in a little bit more
on a model class, which is the way that we
expose the datastore primarily.
You saw Brett use it a little bit ago.
And this right here is defining a model class
for a story, which is something like a typical news
story you might see, a story on a news site.
This is just a normal Python class.
There's nothing special about it.
It's just an interface that we're using
to get down to the datastore.
I define three properties here.
One is a title, which I said is a type string.
That means it's indexed, and you can query on it.
And we also have a body property,
which I've said, alternatively, is a type text.
By saying it's a type text, I mean
that it is not indexed, but instead,
can hold much more information.
Because it's not efficient to index a really large string.
We've also added an author property.
Now, this is a type user.
What this means is it stores a rich object.
We use your account object to be a login
user, which I can supply when I'm creating this object.
So we don't just support primitive types.
We also support more advanced types with the datastore.
Now, I can go ahead and start using this model
in my application.
Use it, write some code, store some entities.
And then I can come back and add more properties.
So here, I've gone and added two more properties.
I added the date-time property with the creation timestamp.
It's pretty straightforward.
But I've also added a rating property.
Now, a rating property, you might think, well, what's that?
That's a little unusual.
Well, this is one of the Gdata types
that we support with Gdata, another system from Google.
And it's actually a semantic type.
With the datastore, we also support richer semantic types,
which are very interesting.
Because then they allow you to store an entity,
and get it back, and work with it
in a generic way using an XML namespace for each type
of the semantic type.
So that gives you a taste of how you actually
go ahead and store data and what you can do with our models.
Now, even though we are a departure
from SQL with the datastore, we provide a very powerful query
interface that is sufficient for building real applications.
Some of the things that we support with our querying
capabilities include queries on a single property
or multiple properties, sort orders--
again, on a single property or multiple properties
as [INAUDIBLE] sending--
transactions, so that you can write a group of entities
together with consistency guarantees.
We also support things like batch operations,
and user settable primary keys, and a few other parts
of the system.
Now, to demonstrate some of these to you,
I'm actually going to show you a query.
I'm going to use GQL, which is something
that you saw in the demo.
And GQL is a simplified, SQL-like query language
that we provide.
It's similar to, in spirit, things like jQuery
or FBQL, which, although they're not SQL,
make it easy to interact with other data sources.
[INAUDIBLE] showed that to you.
Here, with GQL, I've done a pretty simple query, again,
off that same story class that I just showed you.
Here, I said, I'd like to select from stories,
where the title is App Engine Launch, which
is happening right now.
And the author, I've said, I want
that to be the current user.
That's in a keyword argument that I passed
in when constructing the query.
That's a pretty simple query.
You can actually do considerably more advanced queries.
So many other things that you can show,
that you can do or ask for in the same query--
object with the rating over 10 for rating property.
And I can also request that the results be sorted by rating
and also to create a timestamp, even
though it wasn't in the query.
So that gives you an idea of the sort
of queries that we can support.
Now, I should also mention that since we're not SQL,
there's another big feature of SQL that we don't support,
and that's joins.
We don't provide joins for you with the datastore.
And the reason that we don't provide
joins is that joins tend to only work well
in databases that are within a single machine's memory.
When you go outside the memory of a single machine,
and you run into multiple machines,
it's hard to do efficient algorithms
for implementing joins.
So that's why we don't provide them.
But to actually underscore something
that's a little bit exciting about App Engine--
is that although we don't provide it,
it's because the system we're providing to you
allows your applications to scale.
Because the datastore is built on a horizontally-scalable,
fault-tolerance system, and your data can span many hard disks
and machines and already does, it means that if you create
your application carefully-- you think it through a little bit
when you're writing it, about how it might scale--
and you design your queries a little bit of foresight,
your application can easily scale
to millions of users and millions of entities.
Those are the five big components
in the App Engine stack.
Now, I did also want to mention a couple other features
and APIs that we provide.
The first off is our email-sending API.
That's another API that we provide.
We allow you to create and send emails.
But again, in the spirit of App Engine, making things easy,
we don't require you to set up an SNTP server
or do anything like that.
You just create a mail object, and you can send it.
We also provide the ability for you
to make outgoing HTTP requests to the internet with our URL
fetch API.
This API is neat, because it allows
you to integrate with existing other services and web
services.
Another thing that we provide is authentication
with Google Accounts.
Again, it's the same sort of story.
You don't have to maintain user objects and passwords
and do any of that.
We'll handle that for you.
When you create your app, you already have a bed of users
that you can call from.
And finally, another big feature is that we support frameworks.
Now, in the demo, you saw us use a really simple
little framework that we provide just to help you get started.
Well, we support much larger frameworks,
like the whole Django framework.
Those are really helpful when you
move from writing a small web app to a much larger web that
has hundreds or thousands of pages on it.
All right, well, those are the big components
of the App Engine system.
I hope that now, after giving you guys a quick talk,
you're able to see how we're trying to provide a simpler
alternative for creating and running web applications.