[MUSIC PLAYING]
RACHEL TSAO: Agility is a competitive advantage
for enduring startups and technology companies.
And in today's fast-paced landscape,
you not only want to build the right product,
but you want to be smart about where your engineering
team is spending their time.
My name is Rachel Tsao, and I'm part of the product management
team at Google Cloud.
I'll be joined by Leon Sasson, who
is the CTO and cofounder of a fast-growing startup called
Rise Science.
In today's session, I hope to showcase
how you can go to market quickly with our serverless
and developer products that let you rapidly build applications
based on cloud-native best practices.
First, I'll cover Cloud Run with Firebase Hosting.
Then I'll cover BigQuery.
And finally, we'll jump into a customer panel with Leon.
Build versus buy is always the question.
And for this reason, it is important to think serverless
if you want to get your product in the hands of customers
quickly.
Serverless at Cloud Run eliminates your need
to manage underlying infrastructure.
So you don't need to hire for DevOps,
and developers can focus on building services.
Serverless with BigQuery lets you focus on your data
and running your analysis.
Best of all, serverless follows a usage-based pricing model,
so you're only paying for resources consumed
and never overprovisioning.
This, combined with the powerful hosting and developer
tooling of Firebase, becomes the startup golden stack
that lets you develop and iterate quickly.
First, I will show you how you can serve dynamic content
and build REST APIs with Cloud Run and Firebase.
Cloud Run is a fully managed compute environment
that lets you easily deploy stateless containers.
It scales up and down with your app's traffic,
scaling down to zero when there is none.
You only pay when your code is running.
It's easy to use.
You can write your app using your favorite language.
And with one command--
GCloud Run deploy-- your app is live with an HTTPS end point
and TLS termination on your own custom domain.
Since Cloud Run is built on the Knative spec,
it's portable and easy to move your applications to Kubernetes
if you choose to do so in the future.
Using Cloud Run, you can build any stateless workload
that runs in a container.
These can be dynamic websites, asynchronous microservices,
APIs, data processing pipelines, or business workflow
automation.
There are two ways to use Cloud Run.
The first way is request-driven services,
where you trigger a Cloud Run service via an HTTP
request or events.
The second way is Cloud Run jobs,
where you can run jobs that run to completion without an HTTP
request from the user.
This might be database migrations, cleanup work,
export, or import processes.
Cloud Run can easily be combined with Firebase Hosting.
Firebase Hosting is a web hosting provider
that lets you deploy static websites
and server code to a blazing-fast global
infrastructure.
Files deployed to Firebase Hosting
are cached to SSDs and CDN edge servers around the world,
making it great for global apps.
Caching can improve performance and lower costs.
Let's see this in action.
Cloud Run lets teams easily deploy in their language
of choice without knowledge of containers or Kubernetes.
Let's dive into a demo.
If you already have the URL of a container,
you can simply open Cloud Run in the Console
and paste the URL of that container image.
I'll choose the container image that I previously stored
in my container registry.
Another option is that you can continuously
deploy new revisions from a source repository.
You can set up continuous deployment
from cloud source repositories, GitHub, or Bitbucket,
so that when changes are made to a branch like main,
they are automatically built as a container image
and deployed to Cloud Run.
And if you don't have knowledge of containers, that's OK.
You can deploy from source and leverage open source
build packs which will detect the language
and build the container for you, giving you an OCI container
image that can run anywhere.
I'll go ahead and build my existing image.
I'll click unauthenticated so we can access this website
publicly and click Create.
That's it.
That's all we need to do to deploy a container to Cloud
Run.
There's no infrastructure to provision, no nodes, clusters,
or YAML files to manage.
We get a stable and secure HTTPS endpoint to invoke a container.
We open it, and we see it running with Cloud Run
at next and the current server time printed.
This is dynamic.
When I refresh the page, the server time will update.
Let's say I want to make a minor change for the text to say
"Cloud Run is awesome" instead.
I can make this change and build a new container image.
Then I can easily deploy a new revision.
I select the revised container image
that has "Cloud Run is awesome" as the text instead.
I see my revision up and running.
But even better is that I can manage
traffic between revisions and split traffic if I want to.
Cloud Run is awesome.
But what's even better is Cloud Run with Firebase Hosting
to generate and serve your dynamic content
or to build APIs and microservices.
First, we need to hook up Cloud Run to Firebase Hosting.
We can do so by installing Firebase
Tools with the commands.
I already have it installed.
Then we can set up hosting with Firebase with another command.
I've already done this, but this process will give you
a firebase.json file.
In my file, I've told Firebase Hosting
that my public folder will be my static assets folder.
I want every single part of my site served through Firebase
Hosting, but I want the dynamic parts
generated through Cloud Run and then served back
through Firebase Hosting.
When a user requests a site, Firebase Hosting
will check to see if it's static or dynamic.
If it's dynamic, it will go to Cloud Run.
It'll generate, and Firebase Hosting will serve it back.
For the paths that are dynamic, I need to set a rewrite.
So I set a source to be star star, which
means it will match everything except if it's a static file.
I'll also add the service ID of my service, which I call run.
In my static folder, I've added a CSS file.
So this should decorate my "Cloud Run is awesome" text
and make it more fancy.
I can run firebase serve to see how this looks.
This spins up on localhost 5000.
We see the CSS styles for the static folder
served by Firebase.
And if we refresh, we get a server timestamp
being dynamically served by Cloud Run.
Now, the best part about Firebase and Cloud Run
is the CDN caching from Firebase Hosting, which is significant.
This also serves as a cache in front of your Cloud Run
instance, which can potentially reduce costs
while improving performance and avoiding cold starts.
Setting up these magical caching powers is super easy.
Let's take a look at app.py.
I have imported the function make_response,
and I've created a template variable for render_template.
I've created a response variable to pass in that template
to make a response.
Then I added the headers.
I added a cache control header.
It's public, so it's possible.
max-age means the max browser time in seconds.
So I put five seconds for this.
And s-maxage max age tells the CDN how many seconds
it can cache the content.
I put seven seconds.
I've already built and deployed with Cloud Run,
so I only need to deploy to Firebase Hosting.
I type the Firebase deploy command with only hosting.
And this is very quick.
We have our URL, and we have our page.
When I refresh right away, I see the same server time,
meaning that the page is cached for the 5 seconds I set.
We can see the cache control header is set
and how many times our cache hits.
The best part is this part, where it only
took 19 milliseconds to load this page.
And that's because it's stored in the CDN.
So the first time the container runs,
it will store that in the CDN for however
long you set the s-maxage header.
This provides a huge boost in performance
because we don't have to run the container every time.
With Firebase Hosting integrating with Cloud Run,
you can generate content from anything
that fits within a stateless OCI container.
This means you can pick whatever language or server framework
you want and get great performance.
Now that we've seen the power of serverless, let's jump
into BigQuery-- our serverless data warehouse.
If you're a developer, data analyst, or anyone
that works with data, your data starts
to grow to terabytes and even petabytes,
and you need a more efficient system, like a data warehouse.
Larger data sets often mean longer times
between asking questions and getting answers.
BigQuery was designed to handle massive amounts of data
in real time.
It provides virtually unlimited and seamlessly scalable
storage.
And it's highly secure, serverless, and has
built-in machine learning.
BigQuery's operational philosophy
is to minimize the operational burden for users.
Customers of any size can bring their data into the data
warehouse and start analyzing their data using SQL,
without worrying about the database operations and systems
engineering.
BigQuery's service architecture decouples storage and compute
and allows them to scale independently on demand.
This structure offers flexibility and cost controls
because as a customer, you don't have
to keep expensive compute resources up
and running all the time.
This is very different from traditional node-based cloud
data warehouse solutions or on-prem solutions.
Let's see BigQuery in action.
As a startup, it is important to scale up the ingest,
store, and analyze data as you rapidly grow.
BigQuery was designed to make large-scale data
analysis available to everyone.
It has public data sets from governments as well as
from top cryptocurrencies.
These include Tezos, Polygon, Bitcoin, Litecoin, Ethereum,
and more.
Bitcoin makes its data easy to analyze.
For example, the public Ethereum data set
lets us query all Ethereum addresses with their balances.
We can easily run a query to see the top 10 Ethereum
wallets and their balances.
These wallets belong to billionaires.
This data set is uploaded in near-real-time
with around a 4-minute delay to account to block finality.
We've seen some of the amazing benefits of Google Cloud.
What is even better is, as a startup,
you can supercharge your growth with the Google
for Startup's cloud program, which provides you
with up to $100k US dollars in credits and access
to technical resources.
You can learn more at cloud.google.com/startup.
Now we will jump into a fireside chat
with Leon Sasson, the CTO of Rise Science--
an innovative startup that went through our Google Cloud
for Startups program.
Leon, why don't you tell us a little bit about Rise Science?
LEON SASSON: Hey, Rachel.
Thanks for having me here.
Rise is an app that makes it easy to improve your sleep
and daily energy.
We take pride in being powered by validated sleep science.
Sleep researchers agree that there's
two key things that impact how you feel and function--
your sleep debt and circadian rhythm.
Rise can tell you what time in the day
you will have a low or high levels of energy
so you can optimize your activities for that time--
like taking a nap or doing something low-key
when you have a low in energy.
It can also tell you what time your melatonin
will be released so that you can go to bed and get deeper sleep.
We've been able to scale, in part,
by leveraging Google Cloud and Firebase to scale to millions
of installs and hundreds of thousands of customers
in over 160 countries.
RACHEL TSAO: That's incredible.
And at Rise Science, I understand
you use Firebase and especially Firebase Remote
Config and A/B testing.
For those not familiar with Remote Config,
it's a service that lets you change the behavior
and appearance of your app without requiring users
to download an app update.
Using Remote Config, you create in-app default values
that let you control app behavior and appearance.
You can then use the console or backend APIs
to override the default values for segments of your user base
with minimal impact on performance.
Firebase also has an A/B testing functionality
that lets you run experiments and gives you
the power to test changes in the app's UI and features.
It lets you see if the changes move
the needle on revenue retention before they're rolled out
widely.
A/B testing works in Remote Config,
and you can test changes in your app.
Leon, tell me how Remote Config and A/B testing
has helped Rise.
LEON SASSON: Yeah, we're a small team of eight engineers.
And Remote Config allows us to rapidly develop and release.
We release to the App Store twice a week
and deploy to our back end daily.
Remote Config allows us to confidently ship features
faster.
When we have an experimental feature,
we can slowly roll it out over time.
We also use A/B testing, which lets
us randomly assign a group of user as a segment for rollouts.
This allows us to understand which segments use features
more often and measure the impact of our new features.
We save time with Firebase because it provides
a lot of the tooling that would take our engineering team
wants to build.
We released the app in the summer of 2020.
And since m we have release over 200 times in the last two years
of releases.
RACHEL TSAO: That's a great example of how Firebase
enabled you to iterate quickly.
Now, I understand that, as a sleep tracker,
you also have to work with a lot of sleep data--
in the terabytes.
And I understand Rise uses Firestore
as the cloud database.
Firestore is a scalable NoSQL database
for mobile web and servers.
It keeps data in sync across clients
with real-time listeners.
It also offers offline support for mobile and web
so you can build apps that don't rely on internet connectivity.
Leon, let's dive into how Firestore has helped Rise.
LEON SASSON: Yeah, at Rise we process terabytes
of data and billions of writes.
With Firestore, we haven't seen any issues with our data.
The offline syncing is great because our users can
access data from hours ago, even when
they don't have a connection.
We see this as a win because we get this functionality
for free from Firestore.
Our main benefit is that it solves a lot of hard problems
for offline access and move that to the client.
So it reliably keeps data in sync
between the client and server.
We get to outsource this to Google instead
of worrying about it ourselves.
Additionally, the cost is reasonable
as it's metered by reads and writes,
and the database doesn't require any prewarming,
so it scales with us.
We ingest data in many ways, including from wearables
like Fitbit and sleep trackers.
This is a lot of data every day, and we
need the front-end and back-end data to be able to share state.
Our data can also be freeform, as it includes
exercise and workout data.
We really like the flexibility of Firestore for that use case
because it doesn't require prewarming.
When we have spikes in traffic, Firestorm is able to scale up
and our back end is protected.
In addition, the app loading time
can be outsourced to Google, as Firestore has great latency.
This is important, especially, when
we go viral, where we can have 10 to 50 times as many users,
and we do not have to prepare ahead of time.
It saves a lot of backend engineering and DevOps time.
RACHEL TSAO: Going viral-- that's awesome.
How many times has that happened?
LEON SASSON: Yeah, we've been viral a few times.
We were actually a number-one app in France
because the social media creator loved us and did a fantastic
review.
Everything worked, without a blip and no hiccups.
When we were viral, Firestorm was serving 50 times the amount
of writes, and we were able to handle this volume easily.
And a few weeks ago, we were featured as app
of the day on the US App Store.
We received five times load in terms of sign-up
and saw no blips in service.
We didn't have to configure server capacity
because everything worked out of the gate.
If we didn't have Firestore, we would
have to fetch data ourselves to meet the need via GraphQL
and REST APIs, which would be a lot of work for our team.
RACHEL TSAO: That's impressive scale.
Thank you, Leon, for sharing Rise's experience.
Rise's product and growth is incredible,
and I'm so happy to hear that you're
able to scale by outsourcing the hard stuff to Google Cloud.
Thank you, viewers, for joining us on Next '22.
I hope this session gave you valuable insights
on how to accelerate your application
development on Google Cloud.
[MUSIC PLAYING]