Cloud APIs and App Engine interview with Ludo Champenois at Devoxx 2013

Cloud APIs and App Engine interview with Ludo Champenois at Devoxx 2013


[SPEAKING GERMAN] MALE SPEAKER: Hi, we’re
back here at Devoxx 2013. I’m here with Ludo Champenois
from the cloud team at Google. Welcome. So Ludo, you have two
sessions here at Devoxx. One is on building REST APIs. We’ll get to that in a moment. And the other one is about
what’s new in App Engine. And there’s quite a few
things that are new, actually, this year. So we’ll get to
that part as well. But first, APIs. Obviously, Google knows a
thing or two about APIs. We publish a lot of them. Some are very obvious to people,
like maybe the Maps API– everybody’s built at least
one app with the Maps API. But we have a
whole slew of them. And we all base this on
one common framework, which we actually make
available to developers. So do you want to
tell us more about how we would go about using that? LUDO CHAMPENOIS: So we have
been adding APIs to our products forever. It’s a typical
problem at Google. Google’s scale, I mean,
designing one API, it’s easy. Two, it’s easy. But once you have 1,000 of
them, you want to version them, it’s complicated. MALE SPEAKER: Security. LUDO CHAMPENOIS: You want
to add security, et cetera. So maybe I’ve been
using those APIs. I mean, access to Maps,
access to your Calendar, access to Gmail, G+, Google+,
et cetera, et cetera. So we’re pretty
good at delivering those APIs on whatever
client you have, whether it’s PHP, Python,
Java, JavaScript, Objective C, you can have access to
those APIs and make use of them in your client application. So what we have done
with cloud endpoints is allow you, as a developer,
to expose your business logic using the same technology
and the same techniques to generate clients
for your business logic and access via
RESTful web services. MALE SPEAKER: So a few
things that come to mind. The first one is how do
you describe the API? Is there a way to
discover, maybe, the API? LUDO CHAMPENOIS: Yes. So in Java, it’s
based on the notation. So it’s not really
JAX-RS because, I mean, JAX-RS was only limited
to the Java platform. But the Cloud
Endpoints technology can be also implemented in
Python, on [INAUDIBLE] PHP, or [INAUDIBLE]. So for Java, you have to do to
use very simple annotations. And from that, we generate what
we call a discovery document that describes the method
of what your service is. And this discovery
document can be used on the frontend from
the client JavaScript, client to introspect what’s going on,
or to generalize those client libraries. MALE SPEAKER: Right. So this is something that
people may be familiar with, a discovery tool, if they’ve
been using Google APIs. So we’re using the
same environment. LUDO CHAMPENOIS: So
we are using the same. So if you go, those APIs are
documented automatically. And you have an API Explorer
tool for Google APIs as well as for your own
API that you want to push. MALE SPEAKER: So the
other part is security. So how do you deal with that? LUDO CHAMPENOIS:
I mean, security is also a big deal at Google. MALE SPEAKER: I think it is. LUDO CHAMPENOIS: It’s
complicated to fill up a client library to use security
using OAuth, but we do it. And if you know how to do
it for anybody accessing your calendar, your
Google APIs for Calendar, you are using the
same mechanism that we provide for your
application as well. So obviously, your business
logic can be fully secure. You can restrict for
client ids, for example. So maybe not
everybody in the world can access your API because
you want to restrict, maybe, only for your
Android application. MALE SPEAKER: Right. LUDO CHAMPENOIS: So we
have all those layers– it’s really an environment
where your API is fully managed. MALE SPEAKER: And
scales, of course. LUDO CHAMPENOIS: And scales
because it runs on Google. MALE SPEAKER: Maybe
an interesting use of that API and the
Endpoints technology is something called a Mobile
Backend Starter, which is something that’s
built on top of that and provides a full
backend solution for mobile applications? LUDO CHAMPENOIS: So it might
be a bit confusing, but yes. I mean, the mobile
starter is an example of how you can do a backend
and expose it to clients. The value of it is
it’s a generic backend that you can plug to
your phone application. And your phone
application can store data in the cloud using
the data store, which is the Non-SQL data
store for Google. So this cloud– it
gives you a framework that you can use in
your Android application to access, generically,
resources in the cloud. MALE SPEAKER: So it actually
works with iOS as well. It provides notifications. It’s actually much
more than just a demo. But it certainly exposes
the API as an Endpoint API, and as a RESTful set of
resources to manipulate. LUDO CHAMPENOIS:
So you can view it both as a sample, an example,
of how you could write your APIs or use it as is. MALE SPEAKER: Great. So lots of good stuff
here in Endpoints. Let’s talk step
back a minute here and talk about another offering
in the Cloud Platform, which is the Compute Engine side of
things, which is where we’re back to, as opposed to
the platform fully managed environment platform. So here we’re back
to infrastructure, dealing with VMs. So you’ve written on a VM. And then you spawn those VMs. There’s an API for that. Tell us a little bit more
about what Compute Engine is. LUDO CHAMPENOIS:
So Compute Engine is basically the [INAUDIBLE]
frame from Google. So we allow you to boot
VMs in our data centers, whether it’s the one VM or
10,000 VMs, very simple. You select which
zone, and which zone, and geography you want to– MALE SPEAKER: What, the image,
the machines type, and off you go. LUDO CHAMPENOIS: Yeah, so
we have a bunch of images. And you can even add
your own and store it in cloud storage
and boot from it. So APIs, again, REST-based APIs. So we provide a web UI to create
those VMs, or a REST access, or a command line
to create those VMs. MALE SPEAKER: Right, and then
so you pay by the minute. And you have an API. So you can spawn a
huge number of VMs, and shut them down, and
only pay for what you use. LUDO CHAMPENOIS: Exactly. And the pay per
minute is very nice because instead of paying– if
your compute processing takes, let’s say, 15
minutes, you would pay 15 minutes for Google,
and not an hour. So if you pay only
15 minutes, it means that you could even shard
your business processing using four VMs and be done in
less than 15 minutes, and pay only what you have used. MALE SPEAKER: Yeah, and so, of
course, this is infrastructure. So you are at a fairly low
level where you basically SSH into the instance, and
then it’s like good luck. You are on your own. You have to install. LUDO CHAMPENOIS: Get Apache too. MALE SPEAKER: You have the
power of all this network as well, not just VMs. I think there’s great
value in the network. Of course, load balancing– LUDO CHAMPENOIS: We have VM. We have persistent disk, so you
can store permanently your data on disk. We have [INAUDIBLE]
networking capability so that those VMs can
communicate securely, sometimes privately, between them. And we just recently introduced
also, a load balancer, so you can share traffic
across multiple VMs there. But it’s still– You are in
charge of booting those VMs and managing them. So alternating them if you
want to patch them for example. MALE SPEAKER: Right. But then you can run
anything you want and not just– so any native
code, any code you have, any of that, you could run. So what if I have an application
that runs on App Engine, and I love the auto
scaling, I love all of the fully managed
aspects of App Engine, but I have this little
piece of native code which I inherited from,
which is highly optimized, I don’t want to
rewrite, it doesn’t fit into the App Engine model. Can I have the best
of both worlds? LUDO CHAMPENOIS: Yeah, so we
have a solution for that now. So App Engine is a platform
of the service offering from Google. I mean, it has been there
forever, at least since 2008. And it was running
your web application in the Google data center. So we had to have security
rules because we did not want you to look around what was
going on on our data centers. But with the VM-based
backend technology we’re introducing, you
can run an App Engine application inside a VM,
running on Compute Engine. And what it means
is, first of all, it’s a fully managed
application in App Engine. But it’s running in a VM
where you could assess it. You could install
whatever native code you want to augment
your business logic. MALE SPEAKER: Any Java
code, to start with. LUDO CHAMPENOIS: And the Java
process running on those VMs is not restricted
because we don’t care. MALE SPEAKER: Security
is not at that level. LUDO CHAMPENOIS: If you
system.exit et cetera shutdown, the machine will shut down. You could not do
that in App Engine. MALE SPEAKER: Luckily. So of course,
that’s interesting. And actually, that is based
on one of the new features in App Engine, which is modules. So we used to have
frontend, backends, and that is kind of being– LUDO CHAMPENOIS: Yes. So in order to enable
App Engine apps running in the VM-based
runtimes, we introduced the notion of an application
is a collection of modules. So before, you could
create frontend, backend, but now it’s much easier. And those modules
are versionable. So you have one single app
sharing the same data store– MALE SPEAKER: All
the same services. LUDO CHAMPENOIS: Same
security services, et cetera. But you can cut your
business logic into modules. And those modules will
run in different VMs. MALE SPEAKER: Like
the web frontend, the accounting,
the email server– LUDO CHAMPENOIS:
So you could still have one or n modules running
in the traditional App Engine world in a very fast startup
and a highly scalable, and some modules running
in Compute Engine. MALE SPEAKER: So modules
have this property of being more or less scalable,
or more of a frontend thing that scales up and down
based on traffic, or more of a backend thing. LUDO CHAMPENOIS:
Yeah, so you just say, oh, my module will be more
or less a backend module, so I will put 10 of them. And they will always
be up and running. MALE SPEAKER: Right. LUDO CHAMPENOIS: Or my
module is a frontend and I will let
App Engine scale– MALE SPEAKER: The typical way. LUDO CHAMPENOIS: To
10,000 of those– MALE SPEAKER: Yeah, if
that’s what’s required. LUDO CHAMPENOIS: If my
customer demand is that high. MALE SPEAKER: OK, so modules. And one of those
modules, and this is what you were describing,
can be actually running on Compute Engine. And that’s the VM
runtime side of things. So you can have native code, not
just Java outside of sandbox. You can have– LUDO CHAMPENOIS: I mean, I have
a demo using PDF generation, using Java WT library that you
cannot use in the traditional App Engine model. MALE SPEAKER: And you get
access to maybe faster machines, and more beefier
machines as well? LUDO CHAMPENOIS: Exactly,
so if you look at the VMs, I mean, the processes we
were using for App Engine, it’s F1, F2, F4, but
very small configuration, as opposed to a VM runtime
where you can have 16 cores– MALE SPEAKER: Yeah,
lots of memory. Cool. LUDO CHAMPENOIS: So
yeah, beefy server. MALE SPEAKER: So in
the time we have left, I want to touch on
developer experience. There’s been a lot of work going
on into improving the tooling. And the tooling,
that’s, of course, IDs, but that’s also
things like Maven. A lot of people talk
about Gradle as well. Do you want to walk us
through a few improvements? LUDO CHAMPENOIS:
Yeah, first of all, with the introduction of
modules in App Engine, we had to help the developer
creating multiple modules. Again, in java.lan the
mapping was easy to use here. Enterprise archive. MALE SPEAKER: Your files. LUDO CHAMPENOIS: Your files. So one module would be a WAR. And then your entire application
can be packaged as a new file. We enabled tooling
for that in Maven. In the Eclipse idea as
well, where we rewrote, entirely, the Eclipse
plug-in for App Engine. And now we are
using WTP so that we could rely on all of the
web application development and enterprise
archive development capabilities in Eclipse
to support our modules. And recently, we are also
involved in the Gradle plug-in for App Engine because we see
more and more customers asking for Gradle. And if you remember,
the Android ecosystem moved to Gradle as a build
system using the Android Studio. So having end to end– MALE SPEAKER: Story
actually makes sense. LUDO CHAMPENOIS:
Story for building– MALE SPEAKER: So
could I actually be using Android Studio
to build my Android app and actually, in the same
IDE, build a backend as well? LUDO CHAMPENOIS:
Yeah, this is scary. But you can build App Engine
apps with Android Studio. MALE SPEAKER: That’s not scary. LUDO CHAMPENOIS: Either you use
Maven or you use Gradle now. And we are adding a few
hooks for Endpoints. MALE SPEAKER: Endpoints is
supported there as well. LUDO CHAMPENOIS: You will see
in Android Studio Endpoints menu items in the tools menu to
help you generate those client libraries that you can consume
in your Android application. MALE SPEAKER: Last thing,
I hear you can actually run App Engine on
non-Google data centers. What’s the deal there? LUDO CHAMPENOIS: Yeah, so we’ve
been working with Red Hat. MALE SPEAKER: OK. The makers of JBoss, I think. LUDO CHAMPENOIS: Yeah, Red Hat,
if you see Red Hat, I mean, they are the leader
of in JavaEE platform. They are the guys
innovating in JavaEE space. And what is interesting
is they wanted to add on top of the JavaEE
platform the App Engine APIs. So basically, they wanted to
take an App Engine application, as is, and run it without
modification on their JBoss application center. MALE SPEAKER: And they did that. LUDO CHAMPENOIS: And
then Wi-Fi, whatever. And they did that. But as Google, we
wanted to make sure that their solution
is compatible. So we worked together on the
TCK, Technology Compatibility Kit, like everybody
knows in java.lan. MALE SPEAKER: Available
to just JBoss? LUDO CHAMPENOIS: So we have now
a joint project between Google and Red Hat working on this TCK. So what it means is many of
our key engineers from Google are moving hundred of tests
that we had internally at Google testing App Engine, we
are moving them on Github. And the JBoss guys
are also contributing a lot of those tests. And it’s a Github project. It’s called App Engine TCK. MALE SPEAKER: So
it’s open source. The TCK is open source. LUDO CHAMPENOIS: Apache license. And in fact, I would encourage
you to contribute to it. If you see a bug in App Engine,
and you can reproduce it, you submit a unit
test showing the bug. And because we run
those tests every day, we’ll see that it’s failing. MALE SPEAKER: Great. So lots of new stuff in
App Engine, the ability to run your App Engine
apps on top of Cave Dwarf, is the project name? LUDO CHAMPENOIS: The name of
the project is Cave Dwarf. MALE SPEAKER: On top of
JBoss and integration with Compute Engine. Then the sky becomes the limit. LUDO CHAMPENOIS: Yeah,
so many, many new things. MALE SPEAKER: Yeah, so
lots of great things. Great, looking forward to
seeing your sessions on Parlays. And I’ll speak to
you soon, Ludo. Thank you very much. LUDO CHAMPENOIS: Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *