[MUSIC PLAYING]
KIRUPA CHINNATHAMBI: Hi, everybody.
My name is Kirupa.
I'm a product manager at Firebase on Google.
And in the vein of today's talk, which is really
about scaling products, I'll just
talk to you about reaching a billion users with Firebase.
And so if you don't know what Firebase is,
it is Google's app development platform.
Many developers-- small, large, medium-sized--
tend to build a variety of apps using Firebase.
We have 3 million in-market apps over the past 28 days.
Some of the names you might see here
are probably very familiar to you.
They span games.
They span mobile apps, web apps.
The whole range of applications you might think,
Firebase plays a pretty critical role.
And the typical apps you might see fall into phone, desktops,
laptops, also larger screen devices,
like TVs, or really small screens, like your phones,
and new, emerging technologies, like augmented reality, mixed
reality, virtual reality.
All these areas that you might be building your apps in,
Firebase plays a pretty crucial role
in helping make development possible because our mission is
this.
We want to help developers succeed by making it
easy to build and operate apps.
And we really want to overemphasize the word easy
because many of you have a billion things you're
doing as part of running your startups,
running your businesses.
And app development should be one
that is as least complicated as possible for you.
And so if we take a step back and look
at the architecture, how a typical app is built,
there's a part that runs on your device,
on your phone, your tablet, or any of the other forms
that we looked at, that you interact with and see.
And then the capabilities of your app
oftentimes rely on a server, something running remotely.
You might have something like authentication.
Or you might have some complicated activity that
requires a lot of computation.
They don't want to do locally, so you
delegate that to some machine somewhere else.
And so Firebase plays a pretty crucial role
across all stages of your application,
whether it's running on the local device,
or whether it's relying on something
running remotely on a computer hundreds of thousands of miles
away.
But for today, I want to focus on this part.
I want to focus on the server side,
because it's often an underappreciated part of what
it takes to scale an application that gets a lot of users very,
very quickly.
Now, when we think about servers,
we've had them for a very long time.
This whole idea of a remote computer on the internet
doing something on our behalf or on our app's behalf,
it's been around for a very, very long time.
For example, here's an example of an early server
or a server setup from almost 70 years ago,
where you have machines that are doing some computation
and you have the consumption of it being somewhere else.
We're not quite there today.
Today, we've gone much further.
We have more specialized activities
that rely on servers on a regular basis.
And here are a handful of examples.
If you browse the internet, if you
use the web to go from page to page,
a web server is playing a role.
Or if you send an email, there's an email server or an app
server.
If you're storing any data, like,
let's say you take a photo on your phone,
and then that photo is synced somewhere for everyone
to access.
There's a storage device and really
massive computational storage bucket
that handles all the data, or you have databases.
Or if you're logging in, authentication,
all of these things rely on servers
in some form or fashion.
Now, when we think about servers,
there are really two approaches that we typically work in.
One is managed servers.
And this is where we handle all things related to it.
And then there's a world of serverless,
where we don't worry about servers
at all, where we just write code,
and then everything is taken care of for us.
I want to briefly talk about both of these areas
because many of you might be in one of these two buckets,
and it's worth looking into where the pros and cons are.
So when we talk about managed servers, it's really this.
This is the more traditional view of servers.
It's the most popular way that all of your application
tends to communicate with a backend service.
And you basically pay a server provider a monthly fee,
and you get access to your very own computer with your own name
on it that runs 24/7, and we're responsible
for its entire operation.
And when we think of a managed server,
you might think of visuals of really complicated labs
with a lot of wires and very complicated activities
that a human being has to perform to keep everything up
and running.
That is true.
There's a part of it there.
But luckily, we've gotten to the point
where everything is pretty much nicely abstracted away.
So you can essentially-- if you want a server,
you get to specify how it's going to look,
what capabilities it's going to have, and what kind of software
it's going to be running on top of it.
And then the way you manage it is not by walking over
to a data center, but by having a nice dashboard where you can
point and click and configure the various things
your server does.
But because the server is your own,
you do have the ability to almost virtually connect
a keyboard to the physical device
and own all aspects of it.
You may have a terminal.
You have full access to everything
that is going on in your server.
So you do have that capability as well.
Now, when it comes to managed servers,
though, there are some rough edges,
some things that if we had to start over today,
we may do differently in how we build them.
The first one is pricing.
With a managed server, you pay a flat fee.
And this covers time that your server is actually
doing things.
But it also covers probably a long period of time where
it's not always doing things.
If we look at a typical usage of a server,
there's going to be spikes in activity.
There will be times when people are waking up,
they're using your app a lot.
Or when they're about to call it a day,
they're using your app a lot.
But there's a large period of time
where there isn't a whole lot of activity going on.
But as with how pricing works, you're
going to be paying for times that are really not
worth paying for because the server isn't doing anything.
The second one is scalability, because your server has a fixed
amount of resources, and you specify
upfront how much hard drive space, how much memory,
how many CPUs is going to be involved.
So if your server gets a lot of requests,
the first handful that are within capacity will work.
But then if you have users who are using it
that go beyond what the server can handle,
you'll get a very pleasant message.
The server will suddenly tell you that, sorry, it
can't really help out.
You might have seen this error directly,
a 429 error, where it says a server is telling you
that please try again.
Or your application might interpret this and give you
a nice message instead.
And the other part of managed servers
is that they're often single region.
Your audience might be worldwide,
but your server might geographically
be in a single location.
And typically, the closer you are to the server,
the faster your access will be.
So in this case, users who are very close to where
your server is will have a much better user experience
when compared to users who are geographically really far away.
They will just have some difficulties.
And of course, when we talk about managed servers,
the key word is manage.
We're managing it.
We're making sure everything works.
And if something doesn't work, it
falls on us to allocate some time and fix it.
Here's an example of me running into an issue where
I caused a database outage.
And basically, it falls on me as well
to go through and make sure that this
gets fixed-- so not exactly the best use of time, especially
if you have other things to do.
Now, to contrast this world where
we take care of the servers, you have the world
of serverless, where we don't really
worry about servers at all.
Now, the word serverless is kind of an odd choice
because it doesn't mean there's no server involved.
There's still a physical server, and there's still
all the work involved that needs to take place.
But the difference is that it's not
you or I that's going to be dealing with that.
We bypass this whole set of activities
around provisioning and configuring servers
and jump straight to work in application, writing code,
enabling service, the things that are really
the ones that we want to focus on because we have
many things that we need to do.
There are a bunch of serverless providers
that you might be familiar with.
Google Cloud is a very popular one.
You have Azure.
You have AWS.
You have Cloudflare, and of course, Firebase,
which is the one we're going to talk about more later.
But the idea behind serverless is that you
spend more time doing this.
You spend more time building your app, writing your code,
doing the things that you really want to do.
And then deployment is also handled automatically for you.
You just say, I'm done with my code, do it, and ship it.
And then the capabilities behind the scenes
takes care of all the complexities typically involved
with getting something to work in your browser,
getting an API and so on.
And so let's talk about the various aspects of serverless
and how that might benefit us if we're thinking about scaling.
So we'll start with pricing because computing resources,
in a serverless world, they're both online and as-needed
basis.
There's no dedicated server running
24/7 that needs to be there.
So we typically pay for usage, not necessarily just time
a server has been going.
So earlier, we saw about how we're
paying for a day's worth of usage,
even though the server was only doing work in certain spikes.
In the service world, the payment
is typically on a per-use basis.
So here you can see an example where
I'm paying for exactly the amount of time my server is
doing specific work.
So it's not really time, but it's more activity.
Second, scalability-- because a server
needs to be available to process requests,
in the serverless world, that processing,
that provisioning is handled automatically for you.
So the number of requests you have
determines how many servers are brought online
to make this work.
And this is all done automatically,
without us having to do anything.
So if you have a very moderate set of requests,
you might just see your server handling it really well.
But then if you have a lot of requests, the number of servers
grows in accordance with the number of requests
automatically.
So more servers are brought in.
Users are happy.
No need for you and I to do any kind of configuring.
Second part is closer to devices.
Because serverless doesn't mean that you
have a physical server, your server
can be brought online anywhere geographically your users are,
which means that just before when we had a server that
was great for people close by, not so great for people
further away.
In a serverless world, you can bring up a server
very quickly in real time to where the users are,
which means that they get a really good user experience,
which is always good.
So really, if I had to summarize the world of serverless
in a sentence, it's really focused on code and services
and scale from a handful of users
to a billion times that number of users
without any extra effort on your end.
Serverless takes care of all of that for you.
And Firebase plays a critical role here
because our entire solution is really based on serverless
and simplifying all the various tasks involved here.
Not to get into too much detail here,
but you can imagine, if you have an application
with an architecture that requires-- let's say,
in this case, text recognition-- all the various pieces that you
think about in terms of building your app
and making sure the services to handle all this really
effectively are handled, Firebase provides you
with something that does this really well.
And we have a lot of case studies.
But I'll talk about my favorite one,
which is Sworkit, which is really--
you have three developers.
They have a complicated problem of making a video streaming
platform.
And it needs to scale, as video is pretty super intensive.
And Firebase gives you all the various things needed,
where three developers were able to scale
to serve 10 million users by just using
the various components and a great documentation needed
to make this work.
So you're probably wondering, how do we get started?
Well, Firebase gives you everything
from the easily to the build step, to the deploy step,
to the test step for mobile and web apps.
So go to firebase.google.com to learn more about how
it can help you out.
And with that, if you have any questions,
I'm always up for discussing any aspect of this.
You can email me.
You can find me on Twitter.
Or you can contact me on my blog.
Thank you.
[MUSIC PLAYING]