[MUSIC PLAYING]
PRESTON HOLMES: My
name's Preston Holmes.
I'm a Solution Architect
on Google Cloud Platform
and I work on projects
with connected devices,
otherwise known as the
Internet of Things, or IoT.
And I want to start with
answering definitively
a question that often comes up.
And that is, do we have a
consensus as to what is IoT?
And definitively, I'll
say, no, we do not
have any consensus about
what exactly IoT means.
And so I'm going to give
you my working definition
that I find useful for this.
And that is that IoT is
really a period of transition
and transformation.
And that we have everyday
objects, things in our lives,
and they serve some
primary function.
And that at some point, we
begin to connect a few of these
in this sort of awkward
phase where some of them are
connected to the
network and many aren't.
And this is really IoT, the
sort of awkward transition.
And then eventually,
as all of these devices
become connected by default,
they're no longer really IoT.
They just become the things that
we have in our everyday lives.
And so it's this transition
and more and more
of these things in
our lives becoming
connected by default that
defines what is IoT devices.
Now if that's one working
definition of what is IoT,
then why are we wanting to
connect all these devices?
What is that what's
the point of it all?
And it's really
about getting access
to information that wasn't
previously available.
So there's information
in the environment
all the time, all around us, but
it's not really available to us
as data.
So this information
might be something
like the speed of the delivery
vehicle, the utilization
of parking in a city setting.
Might be more information
about the yield
in defect rate of
manufactured products.
No matter which vertical
or industry you're in,
there's probably information
that's valuable to you,
but you're not getting
any access to today.
And so this is one goal
for the Internet of Things.
To go from information
to insight.
Now, most of the
data that we deal
with today in a big
data context, is born
is digital data.
Clicks on a website,
application downloads,
online commerce transactions.
All are born as
digital information.
But the kind of
information we're
interested in the Internet
of Things is analog.
And we need a way to capture
that analog information.
And then locate it to
the places where we
can work on a big data tools.
So really the Internet of Things
becomes the set of technologies
that are the means to this end.
And this is really
what I mean here
when I talk about an end-to-end
solution around the IoT.
Now you've likely been hearing
about the Internet of Things
for some time and the
question comes up,
why hasn't it been
more fully realized?
And there's a number of reasons
why people have been held back.
But first and foremost, I
think is really the complexity
of the domain that's involved.
You've got to
determine and choose
some sort of hardware
device platform.
Got to pick whether
or not to run
an operating system and which
operating system to run.
The networking in the
Internet of Things
is a lot more
varied and diverse.
Some of these networks
are much more spotty,
much more expensive.
There's whole new classes
of networks being built,
specifically for
IoT applications.
You have mobile and cloud
application development.
Each of which are their own
sort of complex domains.
And all of these devices
have the potential
to generate a lot
of data at scale
that might challenge
traditional data infrastructure.
And then finally, we
all recognize that this
has to be done securely.
All eyes are on the
security of IoT.
And the good news is by
paying attention to it early,
we have the chance to
design security in upfront,
rather than act reactively,
which is a lot of what
happened with the web.
So the technology and
to solve this sort
of end-to-end solution,
I'd like to break down sort
of an architecture for IoT.
And fundamentally
we can recognize
three primary components.
The device, which is
the physical object
out located in the real world.
There's often a
gateway, which is
responsible for collecting data
from devices and relaying it.
And then Cloud Platform,
which is increasingly
sort of the nervous system of
your business or application.
Where this IoT data
can be combined
with other non-IoT
data to sort of then
render useful insight
into your applications.
Now if we look at sort of
other pieces of this technology
stack the data
touches throughout,
going from sort
of bottom to top,
you'll recognize a bunch of
sort of familiar Cloud Platform
technology pieces, in terms of
pipeline, storage, analytics,
et cetera.
And across these
things that touch data,
we recognize a couple
cross-cutting sort
of concerns in the areas of
device management and security.
And so it's often unclear how
our Cloud pieces necessarily
fit into this end-to-end stack.
So a lot of what we'll
be talking about today
is some of the devices
and gateway pieces.
So what this map or
framework, we can break down
some of the technical
considerations
and we'll kind of use
this throughout the talk.
Starting with devices.
So as I said, devices
are sort of the thing
of the Internet of Things.
It's thing out in the world.
But a thing might be
as small and simple
as a tiny sensor located
inside the door hinge.
Or a thing might be as
gigantic as an entire oil rig.
And these devices might
be compound and mapped
in sort of a hierarchy,
where you might have a ship
and on that ship is a
pump and both of those
are related to each
other, both are things.
And how those are graphed
is going to really depend
on your specific domain model.
Your domain specialties.
But at the end of
the day, a device
is a physical thing out
in the physical world.
And now, a device is really
just a tiny computer,
so it's both
familiar and foreign.
You can recognize all
the familiar components
of a computer inside
any IoT device.
Fundamentally, it's composed
of hardware and software.
And it is different
than the computers
of our everyday lives.
Fundamentally, the
inputs and outputs
are going to be very different
and a lot more sort of exotic
than the familiar
mouse and keyboard
and monitor that you
have on your computer.
For sensor inputs, there's
a wide variety of sensors
available for gases,
infrared, et cetera.
But an input might be as humble
and simple as a button located
in just the right place at just
the right time for somebody
to signal some
event has occurred.
Now not all devices are
going to have outputs.
But outputs can range, as well.
So you may have something
as simple as a buzzer.
Simply let somebody know
something's happening.
An output can be a
gigantic hydraulic lift
that can lift several tons.
So again, these things
are what really define
IoT devices as different.
Now communications, or
CALMS, is really technically
just another form
of input and output.
I do call it out separately
because the diversity of radios
and radio types
in communications
available for IoT
of devices, makes
communication somewhat
of a special case
for Internet of Things.
Now obviously, on
top of this you
run bootloaders, which run
and load an operating system,
potentially.
And then all of your libraries
and application software
then runs on this device.
Now like I said, there's this
real diversity and explosion
of hardware platforms.
It seems like almost
every week, there's
new types of boards coming
out, new technology.
But really at the end of the
day, as a software developer
you probably think of the device
in terms of the information
which it provides.
How do I model and
manage information
this device is working with?
And we can recognize sort
of the four primary kinds
of information.
The first is metadata.
So this is really
information about the device.
This is things like
a device identifier.
It might include a firmware
version, location date,
installation location
and date, et cetera.
Second is state.
This is sort of information
about the condition
of the device.
Not necessarily the
condition of the environment,
but it's a current
condition of the device.
Might be read only,
or read-write.
It is going to be
something that is along
the lines of like the set
point for a thermostat,
or some sample
rate for frequency.
And so this is not
something you're
going to be changing
and resetting
at very high frequencies.
Commands are type
of information which
indicate some action to
be taken by a device.
So this is usually done
is some sort of a handler
or remote procedure call
that's running on the device.
And these actions are
often not idempotent,
which means that if you send
the same command multiple times,
you might not be getting simply
the same outcome every time.
And you can imagine if
you have a command that
says Run Self Cleaning
Cycle, and you do
that once and now you're clean.
If you keep running
it multiple times,
it's not necessarily
going change the result
the same way it changed at
the first time, unlike state.
And then finally, telemetry.
Now telemetry is really
the eyes and ears
of the Internet of Things.
It's sort of the
source a lot of what we
have as the environmental data.
And this telemetry
can take advantage
of that diversity of sensor
types I mentioned earlier.
Now, if you're going to bother
to sort of define the device,
pick hardware platforms, and
model the information they
produce or consume,
the odds are you're
going to have more than
one device out there.
And as soon as you have
more than one device,
you need to consider how you're
going to do device management.
And device management
broadly addresses the tasks
required to make these
devices functional and useful
in your project.
And this involves
pieces of functionality,
but run both on the device
as well as in the cloud.
Now at Cloud
Platform, we're pretty
versatile in terms of
how we work with you
to do device management.
We have integrations
with Brillo and Weave,
which you'll be hearing
more about later,
that handles device management.
We work with a number of device
management platform partners
who take care of all
the Edge communications
and set up of provisioning.
And there are number
of open-source and sort
of do-it-yourself solutions.
But no matter which solution you
choose for device management,
we can recognize kind of the
key functions that are achieved.
First is, you need to provision
a device on to the network.
It needs to be able to connect
to the local networking
environment where
that device sits.
You need to register this
device in some sort of registry
so you can keep track
of which devices you
have under management.
You need to authorize a device.
You need to make sure that
you're only speaking to devices
that are part of your fleet.
And you need to make
sure the devices can only
reach the backend systems
they're supposed to.
You need to monitor and
perform operational management
across the fleet or
groups of devices
so that you know that
collectively and aggregate
your entire fleet is
performing as you expect it to.
And finally, you need to be
able to ensure that devices
are being up-to-date.
Now this is not only
important for making
sure the device is gaining
new functions over time
and new features,
but it's critically
important for security.
That it's always being
maintained with the latest
security updates.
So let's talk about a
couple of customer examples.
I want to tell
you about how Nest
has been able to
simplify the deployment
of connected cameras, as part
of their ongoing migration
from another cloud platform.
So today, in the completely
regionalized deployment,
cameras first must contacted
a dispatcher in one region
before connecting to a home
server in another region.
And then that data is
stored, per region.
And when it's stored
in a single region,
it gets copied to other
regions for durability
and availability.
Now, in contrast,
the cameras that
are now connecting to
Google Cloud Platform,
use our Global Load Balancing
service to immediately reached
the regional server that they
ultimately stay connected to.
And the data from
that server is stored
in services with
global storage scope,
so they avoid the complexity
of needing to synchronize data
across regions.
And get that sort of
global availability.
Making objects easy and pleasant
to use and easy to orchestrate
is something Philips Lighting
has done successfully
with the HUE color
changing light bulb.
It's one or more familiar
and sort of widely
deployed IoT devices
out in the world.
Many of you may have one.
Now Philips, with the help
of one of our partners, Q42,
was able to build and
scale the infrastructure
to support the HUE application
and API on Cloud Platform.
This low latency
and reliable API
is part of the HUE experience.
Philips and HUE,
Philips and Q42,
were able to take advantage
of some features in Container
Engine to allow the
backend to this system
to be steadily improved
and steadily released
by taking advantage
of the features
such as rolling updates
on Container Engine.
They're also able to
launch new and interesting
small experiments
very, very quickly
on their existing
Container Engine cluster
and at almost no cost,
no additional cost,
to run those experiments
side by side.
And all of that Container
Engine infrastructure
is then able to
connect to our data
and analytics and
monitoring platforms
elsewhere on Cloud Platform.
So the light bulb is a great
example of a device which
by itself cannot
reach Cloud Platform.
And I'd mentioned
gateways in the beginning.
And all HUE light bulb shift
with sort of a gateway or hub.
And I said this is often a key
component in IoT architectures.
And I want to explain a little
bit more about why that's so.
And it comes down to there's
a whole class of devices
out there that are not able
to reach the Cloud for one
reason or another.
This might be that they do not
have any radical connectivity
to the internet.
For example, Bluetooth is not
directly routable to TCP/IP.
It might be that they don't
have the processing capability
to perform the secured
HTTPS transport
protocol that all of our
Cloud Platform APIs require.
It also might be that they don't
have the power budget in order
to support the networking.
They may be very low power.
And finally, there are
perspectives in a setting that
require a device to look at
multiple devices in that area
and do some pre-computing.
So any one device isn't going
to give you that local aggregate
and pre-processing setting.
And that's part of
what a gateway can do.
So we have a demo outside
running with Intel.
One of our partners in the
gateway space is Intel.
They make an industrial
IoT gateway platform.
And we've worked with them on an
integration with Cloud Pub/Sub.
And the scenario we
worked on is this idea
of tracking the
environmental conditions
and locations of pallet goods.
So this starts with an
Eddystone Bluetooth Beacon.
Now, Eddystone is an open source
Bluetooth spec from Google
to find a couple data types that
are broadcast over Bluetooth,
including an ID, as well as
telemetry frames for things
like temperature or humidity.
And the gateway collects these
from the Bluetooth Beacon
and then sends the
information up to Pub/Sub.
On the gateway is also
a developer experience,
a sort of a developer
UI, that you can easily
connect various sensors
directly to the gateway.
And then these automatically
gain from this integration
to Cloud Pub/Sub.
The gateway also runs a
set of libraries for doing
runtime Edge processing.
And this is useful when
you have networking
where you want to be
somewhat miserly about what
you're actually transmitting
on the network to the cloud.
So if you can do some
degree of Edge processing,
you can really send up the
right quantity and kind
of condensed version
of information.
And so this idea of connectivity
being a specific challenge
in IoT solutions comes
up because the location
where this information
you're interested in
is going to be
potentially in who
knows what kind of environment.
And the world is not
blanketed with Wi-Fi.
Wi-Fi is limited to
sort of the places
where people are today,
for the most part.
And so one of the
ways we're looking
at helping extend
connectivity to Cloud
Platform through partners,
is with a project
we're doing with Particle
I/O. Now Particle
is one of the more widely used
Internet of Things platforms.
They've got over 60,000
developers on their platform
already.
And most recently, they
released the Electron.
The Electron is a
small powerful IoT
device with built in
cellular connectivity.
And so this gives
you the ability
to have this device
connect to the Cloud
in over 100 countries.
And we've partnered
with Particle
to make it easier
than ever to pipe
data from any connected
Particle device
directly into Google
Cloud Pub/Sub.
Now anyone who's
visited Google may
have seen these colorful bikes
that we have all around campus
called G Bikes.
And as Google's
campus has grown,
the G Bike has become
the sort of key way
that people get from building
to building throughout the day.
But the team that operates
G Bikes for Google
has very little visibility
into where these bikes tend
to go during the day, and
how they tend to clump,
and where they are.
So working with
Particle, we've sort
of attach some of these
Particle Electrons to bikes.
And we're able to collect
the locations of how
they move throughout
campus during the day.
We stream this through
Pub/Sub into BigQuery
and then we can run
queries that allow
us to plot their locations with
heat map APIs in Google Maps.
This is really invaluable
for that G Bike team
to understand what the usage
is and where these bikes are
throughout the day.
So connectivity involves
things like networks,
but it also involves
things like protocols.
Yesterday we announced support--
Alpha support-- for gRPC
for Pub/Sub.
And gRPC is an open-source
binary protocol
that we'll be supporting
across many of our products.
But in IoT, there
are other protocols
that are very commonly found.
And one of those is MQDT.
So a partner of
ours, Agosto, has
been working on building an
MQTT solution on Compute Engine.
MQTT, as a protocol,
is well-suited for IoT.
It has a very low footprint,
both in terms of network usage,
but also is available
as libraries
for many small
microcontroller devices today.
And so what Agosto has done,
is build a custom MQTT broker
that is based on RabbitMQ.
And it allows us to focus the
protocol translation from MQTT
to Pub/Sub and lets Pub/Sub,
as a managed service,
handle all the
durability and managed
scale of storage of events.
So the Compute
Engine, we can focus
on using the networking
performance and CPU
performance, but not
necessarily worry
about storing all of the events.
And this solution
allows you to scale
this out from pilot
to production,
very cost effectively.
Now what I've been
talking about today
is how things get solved today.
This domain of complexity
is all solvable,
but it can get
definitely better.
And at Google, we're
working on making it better
across the experience.
And it's been part of our DNA to
work with devices from Android
phones, to Chromecast,
and Chromebooks.
So I invite Jeff Chen, the
Product Manager from Brillo
and Weave to tell you more
about the Brillo and Weave
project at Brillo and how we're
looking to improve devices.
JEFF CHEN: Thank you, Preston.
[APPLAUSE]
Good afternoon.
So my name is Jeff Chen.
I'm one of the product managers
on the Google Brillo and Weave
teams, so I'm a device
guy, the hardware guy.
And so I wanted to
first introduce to you
what Brillo and Weave are.
This is Google's offering,
specifically in the IoT space.
Well when we sought out to
build out Brillo and Weave,
we wanted to address
three major objectives.
The first one is that
we wanted to help
device makers a build for IoT.
So at Google, we have been
building connected devices.
Android, Chromebooks,
Chromecast, and so on.
And we realized
that these solutions
could be benefited from third
party device manufacturers
because they struggle
with trying to figure out
how to make devices
cost effectively,
or be able to build
with security.
So we wanted to help device
makers prototype their device
applications quickly and
then, more importantly,
port that over to the
production hardware
without requiring major surgery.
And it doesn't end there.
With connected devices,
it's really important
to be in a position
where you can actually
monitor the devices
that are in the field
and be able to push
out updates to them
to resolve any security
concerns or to update
new features to continue to
improve the user experience.
Secondly, we wanted to
create an open ecosystem.
As we observe the growth
of these IoT ecosystems,
we saw that there were
subnets of siloed ecosystems
that were causing more
and more fragmentation.
And while there were some
very good reasons for vendors
to lock down the
connectivity of these devices
with proprietary
protocols, it keeps us
from getting to this truly
open Internet of Things.
And so the only
way that we can get
into this Internet of
Things is by embracing
open and standardized
communication protocols.
Which leads us to the third and
final objective that we had.
And that is that we can
create an ecosystem of devices
with open protocols
so that we can create
a rich ecosystem of
apps and services
that could be transformative.
So think about the web.
Think about mobile Android.
Now, the intelligence and
the smarts of these devices
will not come from a single
vendor, nor from Google.
It comes from you.
Developers.
Developers that want to build
applications and services that
can communicate across
devices, from different brands.
And that can build rich
analytics around these devices
to help make these
devices better
and more useful to the user.
So that's why we built
Brillo and Weave.
Because ultimately
we see that the magic
comes from a distributed
world of devices.
And we think that the
power of this new internet,
will require the ecosystem to
build devices cost effectively
and at scale.
These devices will have to
communicate with each other
through open protocols.
Where the smarts
are in the device,
on clients, or in the Cloud.
So let me tell you
about what Brillo is.
Well, Brillo is an
operating system
that's maintained by Google.
It is a version of Android.
And it is supported by a
variety of silicon vendors.
And it has proven scale to
reach over one billion Android
devices, right?
So we recognize that deploying
a full-blown stack of Android
is a little bit overkill
for connected devices.
So we built a
stripped-down version
that was targeted specifically
for connected devices.
So device manufacturers
can leverage
all of the benefits of the
Android hardware ecosystem.
So if a chip vendor
supports Android,
it can essentially
support Brillo.
Now the second aspect of
Brillo is about security.
And Brillo enables
devices to be secure.
Because fundamentally,
we believe
that security has to be
built into the device for IoT
technology.
We believe that, not only do
you need to have it built in,
but you also need a way to be
able to fix issues that are
in the field as they come up.
So we've built a number
of security features
into Brillo that will
address these problems.
Including verified
boot, which means
that the device
will run code that
is trusted from
the manufacturer.
We also make sure that access
to the device and all the data
that's produced
through these devices
is controlled by the user.
And that any data that is
actually stored on the device
or transmitted across the
communication pathways
are all encrypted and secure.
And then lastly with Brillo,
it comes with services
like analytics and updates.
So for example,
device manufacturers
can get a readout
of all the features
and the usage of their device
population in aggregate,
and figure out how the users
are using their devices.
But also, we provide an
infrastructure to push updates.
So that as security
threats come up
or you see new features
that you want to deploy,
that you can have a
pathway to be able to push
those updates to those devices.
Now, for Weave.
What is Weave?
Weave is our open
communications platform.
It consists of three components.
A device library, client
API, and a web server--
Cloud server.
If you build Weave
into your device,
it's easy for third party
application developers
to access your Weave devices
from their phone, or a cloud
service through Weave
mobile and Cloud APIs.
We believe in
interoperability so much
that we built out device schemas
for a specific set of device
categories.
So that third party
app developers
could use these schemas to
build apps to monitor the device
state, to control them, and
to build analytics and richer
experiences across
all of these devices.
And in addition to
offering third party APIs,
we also offer a
seamless integration
into Google services, such as
the Google Voice assistance.
So with Brillo
and Weave devices,
this platform enables
an ease of use and ease
of building devices and creating
a standardized device data.
And we expect these
devices to generate data.
And a lot of it.
So Google Cloud
Platform for IoT data
offers a proven
end-to-end solution
to make sense of
large amounts of data
and produce meaningful insights.
These insights can help
manufacturers determine
what features to add or
remove on their product,
help app makers develop novel
new experiences and services,
and help enterprises manage
their fleet of devices
for optimal performance
and security.
So that gives you a little
bit of an overview what Google
is doing in the device
ecosystem to enable an operating
system, Brillo, and a
communications platform called
Weave.
So our team looks forward to all
the amazing and awesome things
that you guys are going to
be doing on the Cloud side
to take advantage of these
smart and connected devices.
Thank you all.
I'll hand it back to Preston.
[APPLAUSE]
PRESTON HOLMES: Thanks, Jeff.
So as I said earlier, much of
what we've talked about today
has been about the technology
of the Internet of Things
that runs outside of the
context of Cloud Platform.
Now this is important
because, unless you clearly
understand how the
on-ramps for IoT data work
and how to solve
for them, you can't
take advantage of all
the great big data
tools we have on Cloud Platform.
So it's important to
understand how to get
the data on to the Cloud.
But without a doubt,
data and analytics
is our strong suit
on Cloud Platform.
And the key here
is that we provide
a comprehensive platform
for working with IoT data.
And what's interesting
is, as we follow
this data through the
journey from the Edge
to the application,
it begins, perhaps,
as highly specific
data that might
be coming from a machine
specific industrial protocol
or health care device.
But as it moves and is
ingested into the platform,
and processed, and
normalized, and standardized
into the structured data that's
well suited for our big data
tool chain, it begins to lose
some of it's IoT specificity.
Temperatures just
become integers.
And cycle times on machines
become just timestamps.
And so as our general
purpose dictated
tool chain processes and sort
of munches this IoT data,
it then becomes a
bit more generic.
And as it moves out
into the application
is where really regains
this domain specificity.
Because, at the end of the day,
the insights in and sort of
queries that you
run against the data
are what turn this
volume of data
into the useful sort of
actionable level insights
that you need to then present
back to processes or users
through applications.
And this is really why
application sort of
called out here separately.
And I want to tell you one
such application that we've
incubated at Google
for Work, and launched
in a multi-store pilot
with retail customer,
is the solution which provides
digital inventory, visibility,
and accuracy.
This works by putting RFID tags
on every item in the store.
Readers then on the
ceiling can scan the store
and basically generate
a live inventory
feed of what is both in
the front of the store
and the back of the store.
This application then
generates the sort
of steady stream of the real
time view of the inventory
up to Cloud Platform, where
it's processed and analyzed
and then made available
as an application
to store associates.
Now store associates can
take this information
and it boosts their
visibility into the accuracy
of their inventory in-store
upwards of 95% compared
to the 60% to 70%
typically gained
through a standard
point of sale system.
And this allows them to track
inventory in the back room
to the front of
the store to make
sure the product
is always present
where customers need it.
The corporate office, this also
gives all sorts of visibility
about changing and adapting
marketing campaigns,
adapting store HR
hours, et cetera.
And once infrastructure
such as this is in place,
it begins subsequent ideas
for other applications
they can bring, sort of what
were once considered far
off, future ideas sort
of virtual changing rooms
and try on stores, touchless
payment checkout systems,
et cetera.
So this is going to bring
us back to security now.
And security like
Device Management
is something that needs to touch
the entire data handling stack
end-to-end.
And you all were in
the keynote earlier.
Hopefully you've heard
how much attention we pay
to security and Cloud Platform.
It's something that Google
takes very seriously
in Cloud Platform, builds
into the fabric of all
of our products and services.
Now for IoT, it's important
that we offer both secure APIs
and methods for bringing
the data onto the platform
securely, as well as sort
of the security controls
and foundations to
make sure that you're
able to keep that data secure,
once it's on the Cloud.
On the device side, you've
heard about Brillo and Weave.
Device security
needs to be built
into the fundamental systems and
technologies you're choosing.
So Sandboxing allows
the protection
of one process from another.
Over-the-air updates
and verified boot
makes sure that you're
running secure code
and always able to push out
the latest secure versions.
Keeping user data secure on
the device and in transit
to the Cloud is very important
for consumer applications,
as well as commercial
applications.
And finally, using
secure Linux technology,
such as mandatory
access, controls
limits the power of any
exploit from doing more damage
in taking control of the device.
But it's not enough for us to
just do what we can at Google.
To really secure the
Internet of Things
requires collaboration across
a broad ecosystem of partners.
So one of the challenges
in IoT application
is maintaining this end-to-end
integrity and secure ownership
of the device.
I want to tell you about
this collaboration we're
working on with Intel in
the technology they're
calling Marshal Point.
The idea is that by
taking a hardware
proof of authentication
in this technology
that Intel calls EPIC, which
they've already licensed
to Atmel and Microchip, that
a new owner of a device,
a new service of a device, can
meet at a virtual rendezvous
point, the manufacturer, the
previous owner of that device,
and visually sort through
some cryptographic signatures,
take new ownership
of that device
and securely provision it
with application or Cloud
credentials.
So this is an
example but I think
it takes to really secure
the IoT end-to-end.
Because if you have
any gap in that chain,
that becomes sort of an
unacceptable point of surface
to breach your system overall.
So in conclusion,
why do you want
to get started building IoT now?
Well it is a fantastic
time with the hardware.
The proliferation
in the diversity
of sensors, and
platforms, and hardware,
it's never been easier to get
started with hardware today.
Second, Google is bringing
it expertise and experience
working with both devices and
data across the entire spectrum
of IT problem space.
And third, we do so within
the utmost focus on security
throughout, as
you've been hearing.
So I encourage you all to think
about the analog information
that's relevant to you it
out there in the world today.
And to go start
building solutions
to capture and process
that information on Cloud.
Thank you very much.
We'll let you get
cut for your lunch.
If anyone has questions, Jeff
and I will be down up front.
[APPLAUSE]
