[MUSIC PLAYING] [APPLAUSE] COLT MCANLIS: I love the
first person that clapped. Where are you? High five. A round of applause
for this man up here. Started the clap
for the presenter. I like it. Hey, everybody. Welcome to day three
of Google I/O. Yeah? We feeling it? Everyone properly
caffeinated today? No? OK. Good. Good to know where we're
starting off as a team here all together. So I've got to tell
you, when we actually got this talk agreed
upon, they came to me and they said, all
right, you know, we love the title of your talk,
GCP on a Shoestring Budget, we love the narrative that
you're trying to bring, helping developers
save on money. When do you want
to give the talk? And I had one answer. I said, day three. 8:30 in the morning. No other possible
opportunity there. And you want to know why? Because the people
who are willing to go through two days of standing
in the sun and wake up at 6:00 AM to stay in the security line
to get in the seats by 8:30, they care about saving money on
Google Cloud Platform, right? Yeah, exactly. So thank you for being here. Now when we get a chance to
talk to a lot of developers around the world, I find
that there's generally two buckets of people, or
two buckets of companies that companies fall
into when you're talking about saving costs. The first one is
your large companies with established codebases. They may have expected workloads
that come through Google Cloud, but the predominant
conversations we have are, hey, you know if you make
this change and this change, you can save a lot of money. And their response is always
along the lines of, well, how much would that
cost to implement? We've got this legacy codebase. You know, bill over here
really is attached to that API. We really don't want
to get rid of that. Basically any conversations we
have with these individuals, they always have an
opportunity/cost trade-off that they have to
make in their head before they're willing
to actually make the changes to save the money. Right? On the other side,
though, are the hustlers. The rise and grind, right? The startups. The people living customer
to customer every single day, trying to get those
costs as low as possible because they know that
that's the key to keeping their business afloat right now. And those are the
people hopefully that wake up so early,
after two days of sunscreen and dehydration, to come
to this sort of talk. And that's who we're
talking about today. All right. Now Google Cloud
Platform is huge. We have a ton of
different products, and quite frankly, the
40 minutes that they've given me here, we
don't have enough time to go through all of them. So today we're going to
focus on three main things. Number one, we're going to lay
some foundation on the network and show you how to save
a little bit of costs there, just to kind
of ease everyone into what we're talking about. Then we're going to
talk about some ways to save costs on compute. And then we're going to go
through a couple of scenarios that hopefully some
of you fall into and you'll have a little
bit better time attaching to your business model. But the most important
thing you need to know is that nothing I'm talking
about today is secret. None of this requires a
handshake or the right Google badge to get this
information about how to optimize this stuff. Every piece of data
you're seeing today is available for you to go
get right now, either using the Google Cloud Platform
pricing calculator, or looking at the pricing pages
for the individual products. Like this is it. Again, it's not an
Illuminati style thing here. You can go run the same
analysis on everything you're doing on your own. So let's get started. Serving data. This is where we're
going to start today. Let's figure out
what does it cost to serve one terabyte of
data from Google Cloud Storage to your users. Just bare minimum
discussion here. Let's just talk
about serving data. Now when you think
about this, you have two components involved. First off is storage-- where you're storing your data-- and second off is
your network costs for actually
transferring the data. Now the costs for these
are dependent upon usage. So for example, Google
Cloud Storage, what you pay is a function of
where you're hosting your data alongside of
how much you're hosting. So for example, if you're
actually hosting your data in US central one region, you're
paying about $0.02 per gig to actually store your data. However, you move to
US East, that changes. And if using a
multi-region bucket, then that changes as well. On the networking side, it's
a tiered cost structure. So if you're under one terabyte,
you pay a different price than if you're in the next
tier of one terabyte to 10 terabytes, and 10 terabytes up. And then this also changes
per region as well. So for example, if
you're transferring data from the Iowa location,
which is US central one, and you're in the first
tier of under one terabyte, you're paying about $0.12 a gig. Now with this in mind,
though, we have to point out something-- and again,
this is not secret, this is widely known-- is that there's a whole tier
of usage on Google Cloud that's absolutely free that you get
every single month that you can just use this stuff. No one cares about it. You're not going to
get charged for it. And it ranges from mostly
all of our products. But most specifically
for our case right now, we're worried about,
what is the free tier for network and storage? On the storage side, we
actually get five gigabytes of storage for free
each month, each region. So if you've got five gigs in US
East and give gigs in US West, each one of those is free. On the network side, we
get about one gigabyte of egress, which
is outbound data traffic, from North
American locations to other destinations. And by the way, you will see
many caveats of little stars during this, and you'll also
see a lot of little labels that says, the price of today. This is the Cloud. Prices change. And if you discover this
video in the future, you will undoubtedly
find that there's a discrepancy in the prices. So please make
sure you check out the documentation
for the latest. So this is our free tier. Let's talk about
egress cost then. So one terabytes of data
that we want to send. So what would this cost us? So to store it, we get
about one terabyte of data storing in US central one. That's 1024 gigs, minus our five
gig free tier at $0.02 per gig. About $20 a month. Just to store the data at rest. Not too bad. On the network
side, though, things get a little bit trickier. So we've got our one
terabyte of data, minus the gig in the free
tier at $0.12 per gig. About $122 a month for
a total of about $143. So storing the
data, transferring a terabyte of data, about $143. Which isn't too
bad I don't think. But the truth is
that most of you actually don't send
your users directly to your Cloud storage bucket. Chances are you have
some proxy, some front-end that
they're hitting first if you're website or something
else that this data is being routed through. So let's take a look
at what that costs. Basically the same. So as long as you're
transferring information in the same region
between a Cloud storage bucket and a Compute
Engine instance, it's free. You don't have to worry
about that as long as it's in the same region. And then your egress
rates are still the same if they're coming from Compute
Engine or from Cloud storage. So basically, if you're
transferring all your data through a proxy, you're
paying the same exact price as you would if it was going
from Cloud storage directly. The only difference is that
you're now actually paying for the Compute Engine
instance running there, or the Cloud function's instance
or the app engine instance. So basically, as long
as you're using proxy, the basic serving
costs don't change. But let's look at this
from a different way. When we serve data
to people, especially through Cloud storage, one
of the things we care about is locality and latency. So we want to get our data as
close to our users as possible, but we also want to do it
as cheaply as possible. So let's take a look
at that scenario. So let's say we're
serving our data here, we've got it in US
West one, and we want to serve it to a
user in US East one. So we're going across
the continental US. Price here is still
the same, $143. It doesn't matter where
the user is coming from, we still have the same cost at
rest and the same egress costs. But we want to get that
data closer to the user. So what if we actually cloned
that data in US East one and got it closer to the user? Well of course at this point,
our egress is still $0.12. No change there. And Cloud storage
itself, we're now duplicating the data between
two buckets so of course we're paying that extra
$0.02 a gig to copy it into this other
location, so we're doubling our cost for storage. And we also have
this extra $0.01 per gig transfer
cost between them because we're moving our
data between regions. So now we actually have a cost
that's incurred with that. So to actually clone this
data between regions, we're actually looking at $173. Not ideal, but it gets our
data a little bit closer. But the truth is we
might be thinking about this the wrong way. So we do have these things
in Google Cloud Storage, we have regional buckets
and multi-regional buckets. And what multi-regional
buckets do is effectively duplicate your
data between regions in an area so that you don't have to
do this cloning by yourself. The trick, though, is that
multi-regional buckets cost a little bit more. So take a look at that. So if we want to go
from Cloud storage right to our users, our egress
rate from a Cloud storage multi-regional
bucket-- by the way, there's going to be
lots of weird acronyms and terminology in this talk. It's labeled intermediate
so hopefully we're all move in together-- $0.12 per gig egress. However, we're
paying $0.026 per gig to store in a multi-regional
bucket, which puts us at about $26 a month
for that storage instead of what we were
paying for the single region. We're at about $149 there. So not too much cost change. But the difference here is
that when a user in US East one actually asks for
this asset, Google handles the
duplication of getting that data closer to the
user on your behalf, and you don't have
to clone it yourself. So we basically just
saved an extra $30 by using a multi-regional
bucket per month instead of actually
cloning it ourselves. OK. Sounds good. So we've actually reduced our
cost inside the regional US. But what if we want
to go international? So we want to serve this data
to someone in Europe, right? Well let's take a look
at cloning there as well. So again, we have our clone data
in a US multi-region and an EU multi-region, so obviously
we're duplicating our costs. We have the same amount of cost
egress for the EU multi-region, which is selected
for these numbers. However, now because
we're transferring data between multi regions
in different areas, we're actually at
$0.12 per gig transfer. So we actually get a
little bit pricier there. $286 this is the result of this. So if you're trying to
get your data to users in a different area
using the multi-region, it's actually really expensive. But let's rethink this here. So the goal-- again,
we're shoestring. We want to make this
as cheap as possible. We want to get data from the
cheapest bucket we can store it in to the farthest
away user as fast as possible, as cheap as possible. We already have this. It's called the CDN. Right? We've all been
working with these. So let's figure out what
the cost is of that. So we've got our standard
regional Cloud storage in EU West at about $0.02 a gig. Now for CDNs, there's two
costs you need to be aware of. We have a fill cost
and an egress cost. To fill data into the cache,
you're looking at about $0.04 per gig to get it into the CDN. And that's worldwide. It doesn't matter
where you're going. So if you have data here
and someone in Nairobi asks for your asset,
it's $0.04 per gig to cache it to the
closest point of presence that Google has there. Now egress from the CDN
is only $0.08 per gig. So when you combine these two
together, $0.04 and $0.08, you actually end
up at about $0.12 per gig, which is your
standard outbound egress rate. However, this is assuming
a one to one ratio. So if you're actually
pushing a terabyte of fill and serving that
same terabyte, you're going to end up at about
$143 to get that asset as close to every user in the world
without you lifting a finger, except making sure your cache
headers are turned on properly. But in reality, this isn't
how things work out, right? Typically the amount of
cache fill versus cache serve are quite different. So if you're actually
in an 80-20 split here where 20% of your data
is filled into the cache and 80% is actually served
out, you actually only end up closer to about $91. So as long as that ratio is
on the serving side instead of the filling
side, you're going to have a lot cheaper
representation and set up. You're going to get closer to
that shoestring value you want. So in general here,
if we're looking to serve a terabyte of
data, the cheapest thing we can do to get it to
users across the world as fast as possible is simply
to set your caching headers. Any other tricks or
any other smartness that you're trying to do
is going to blow that up. It's going to make
things more expensive. So find the cheapest bucket
that's as close to you as you can tolerate,
put your data in that, and then turn on
the CDN and like Google's point of presence
network handle the rest of it. All right, let's
talk about Compute. So Google Cloud Platform has
a lot of Compute offerings, but today we're only going
to talk about three of them. First off is Google
Compute Engine, which is our standard VMs
that run in the Cloud. Second is, of course,
Google Cloud Functions, which are our invocation
based Compute resources. And third, of course, is Google
App Engine, which has both managed and invocation based. And for the sake
of this talk, I'm going to ignore things like
Google Kubernetes Engine and GAE Flex because
these actually tend to price themselves
closer to what GCE is. But for the sake of
this 40 minute talk, we don't have to go
into all the nuances. It's a little bit weird. So I'm just going
to ignore those. We're going to focus on these
three offerings right now. So by cost, of course,
GCE is variable on config. Depending on what configuration
you're using is how much you're going to pay. The beefier the
machine that you're using in the configuration,
the more you're going to have to pay there. Cloud Functions, though,
it's a little bit different. Cloud Functions is about $0.40
per million calls that you make to it. And then there's also
an additional cost you have to be concerned with
is what we call gigabytes second and gigahertz second. And if you check out
the documentation, there's a little bit-- a little bit better
breakdown here. I'm not going to get a chance
to go through it today. And of course, App Engine is
going to be $0.05 to $0.30 per instance hour, depending
on your config. So this is the default
cost that you have here. Now on the other side, we
have our free tiers, though. Now here's where
things get really cool. In Compute Engine,
if you're using an F1 micro configuration,
it's free the whole month. No cost to you. Free instance sitting in the
Cloud, doing your bidding, as much as you'd
like it, all free. On GCF, you got about two
million invocations a month, or 400,000 gigabyte seconds
and 200,000 gigahertz seconds. And on App Engine's, you
have 28 instance hours a day for an F1 instance, and
about nine instance hours a day for a B1 instance. And I know there's not-- I know there's more than 20-- there's less than
28 hours in a day. So that gives you a little
bit of wiggle room in case your extra instance
spins up in an F1. So basically here when you look
at GCE F1 micro and GAE F1, you kind of get
free compute as long as you're under a
certain strata of usage. With this in mind, let's take
a look at an always-on cost. So let's say you want to run a
box 24/7 for an entire month. What does that cost you? So months have different
days and we always have leap year and stuff like that. So I'm just going to assume 730
hours of consistent run time. What we end up with if
we're using an F1-micro, it's free the whole month. Don't have to pay a thing. However, when you bump
up to an N1-standard-1 because you want a little
bit more performance, you start paying $24 a
month, and $194 a month for an eight core machine. This is all on the
Cloud pricing page. You can see all of this. And by the way, this is after
a 30% sustained usage discount, which I'll get to in a second. Cloud Functions,
though, we can't really compare apples to apples. Because it's an
invocation based system, we can't just say,
consistently running. So what I've done here is
I'm making the assumption that you're getting one
invocation to your Cloud Function service every
second for the entire month. So you got about 2.6
million invocations a month that's going on there. That lets us kind
of simulate what an always-on cost would be. For this, it's about
$3.51 to basically have a GCF function
running every second for an entire month. On App Engine, you end up,
of course, in the F1 config, it's free. Don't have to change
anything there. However, if that second F1
instance actually spins up, you get a little
spike in your workload or all of a sudden
you're the top of hacker news for some
reason, you're going to pay $36 for that second
instance to come onboard. Of course, when you move
up to an F2 or an F4, which again, are beefier machines,
you get the $73 and the $146. So basically across
the board here you can see that in GCE and GAE,
as you get a stronger machine, of course the costs go
up, while GCF is still pretty instance based. Now here's the
interesting thing. So those are basic costs. So obviously Compute Engine
is the most versatile thing we have. It can run whatever
code you want, whatever instance you
want, your images, and all this other stuff. But the problem is it's
also the most expensive for what you're using. So it would be really cool
if we could figure out how to make that as cost
effective as our other services without having some of
the same limitations. So for example, if we just
wanted to run our code on GCE, we have problem which is that
each function invocation has a nine minute timeout. So you can't
actually get anything for more than nine minutes. On the other side,
on App Engine, you have a 60 second
time out on requests, but if you push
that off to a task, later you're going to end
up with the same nine minute timeout. So our goal here
is to figure out how to make GCE as cheap
as our other alternatives. And the good news
is we can do this. First off, let's take a
look at the GCE discounts. Now these are the
things that you really don't have to lift
any fingers to do to actually turn this stuff on. So first off is sustained use. So what we'll do on Google Cloud
Platform is analyze your usage and if you have a sustained
usage, so you're always on for a certain
amount of time, we'll give you a default
discount for just running your instance
with consistency across the entire month. If you're willing to make a
phone call to our sales team and can actually commit to
usage, specific usage, and say, I'm going to run at least
2,000 hours this month, or 730 hours this month. You know, it doesn't matter
what configuration you're using and you don't have
any pre-definition of specific upfront
fees or whatever. You can actually get
up to a 56% discount by just making a phone
call to talk to sales. So if you're a
startup and you're starting to see a little
bit more usage and you need that dedicated
resource and you know you're going to have
one or two instances running at a dedicated
fashion, making that phone call and getting that 56% savings
is actually pretty huge. And of course, right sizing. So what will happen is
Google Cloud Platform will actually analyze the
usage of your GCE instances and look at how
you're using them and actually tell
you whether or not you're over provisioned
or under provisioned. And you'll see a little icon
appear on the home page that will say, hey, if
you click here, we'll reconfigure this for you
and save you money every month. Likewise it'll say, hey,
you're using this pretty hard. If you click here, will
beef up your machine so that your users
get lower latency. So it's a fun little
button that you can just click, the deployment
happens behind the scenes, you don't have to do anything. So this is kind of
automatic stuff. However, something
that's a little bit more drastic in terms of
saving that does require a little bit of
work on your part is something called preemptive. Now what preemptive
VMs are means that the scheduler is allowed to
kill your instance when we need the resources in Google Cloud. Now that may sound really
scary, but here's the fun part. It will actually
alert your instance before it's about to get killed. So it'll send you a message and
your instance will say, hey, I'm about to terminate you. You've got roughly
about 30 seconds to backup any data to
some persistent resource. And then once it
kills your instance, it'll start your
instance back up later and then you can then
go fetch that data and continue working on. So if you allow us to kill your
instance when we need the time, we actually give you a
substantial discount. If you're running at an
N1-standard that's preemptive, instead of paying
the $24 a month, you get a 3x discount
down to about $7 a month for the same
instance, and all you do is to have to write the
code so that you can lay over those sorts of
terminations after time. And the cool thing is that
you can actually put a load balancer in front of that. So if you need scalable
compute and you need the ability to allow
these things to die, but because you've got so
much load coming in, you know, one of them going
down means another one might have to spin up. Putting a load balancer in front
of your preemptive instances, since load balancing
is free, again, means you're only paying
about $7 a month per instance that you're actually running. Of course, we can get this a
little bit cheaper, in fact, if we actually use a micro
instance there instead. We can actually get it down
to $2.96 per month using an F1-micro, but because of
the fact that we have our load balancer and because of the
fact that we've re-engineered our code to make sure that it
can be fault tolerant when it's killed, we actually have a
massively scalable compute resource that can handle
itself getting kicked over. So if you've got large
amounts of workloads or individual things,
you're processing lots of individual files
where something can pick up processing 50% where
something else left off, this is an extremely
cheap solution for you. Probably as cheap
as I was actually able to find in my research. So in general, if you to
reduce your compute costs, you got a couple of
things you need to do. First off is
distribute workloads that are based on invocations
to either App Engine or Cloud Functions. Those are going to be the
cheapest situations where you can put your code
and have them run. If you need something
long running, then leave it back
on Compute Engine, but otherwise try to
push as much as you can to those resources. That's going to be the
cheapest you can get. Likewise, make sure
that you're making that phone call to sales. Let them know that
you're willing to commit to a sustained use and get
that discount, because that's going to be huge for them
work jobs that you actually need running consistently
on Compute Engine. And likewise, if you
have scalable needs, a load balancer plus a
micro preemptive instance is pretty much the highest
flexibility, lowest cost scenario you can be in. Having a bunch of little
spiders doing your work for you at scale is just as effective
as having one behemoth doing it for a higher price. All right. So those are our
basics here, so we've kind of laid the
groundwork for how we're going to
evaluate these things and look at the big picture
between network and compute. Now let's talk about
some scenarios. Personal privacy
matters online, right? We all kind of care about that,
especially when we're logging into public WI-FI and whatnot. But sometimes I don't
like paying a subscription to some other service
to handle a VPN service. So how cheap can we build
our own personal VPN service on Google Cloud? Now to be clear here, I know
that personal security online is a very hectic area
right now, and there's lots of back and forth. So to be very clear, I'm
not going to talk today about why you need a VPN. I'm not going to debate
the different software libraries you can use
or having your own VPN versus being part of a cluster. I'm basically not going to talk
about anything that PR or legal would raise an eyebrow about. But I am going to
talk about how you can run your own VPN on Google
Cloud for as cheap as possible. All right? So with this, we have
two components, Compute and Network. Pretty easy. How a VPN generally works is you
have your client that connects to some Compute Engine instance
that's running your VPN, there's a socket
connection between the two that are exchanging
encrypted data, and then the Compute Engine
instance or the proxy will actually go out into
the fantastic internet and do all your
fetching for you, return that data back
to your computer. This is a high
level approximation. If there's any security
engineers in the room, I apologize for
generalizing that to a point that I can fit on a slide. So let's look at the free tier. Here how cheap
could we make this? Well if we use our
instance as an F1-micro, then we know we can
get that for free. And as long as our usage
is about less than one gig, we know that we can
basically get that for free as well, right? So if we're using an
F1-micro and our usage is less than one
gig, we can get a VPN that we can use whenever we
want for free every single month using Google Cloud Platform. And you only start to pay when
you go over that free gig. So if you're just using this
to log on to Wi-Fi hotspots when you're traveling
around the world, you basically get this
entire thing for free. No big deal. But here's one of
the problems is that if you're using a
preemptive version of that, you have a problem that you need
to know where to connect to. And every time you reboot
that VM, you have a new IP. Good news is on
Google Cloud Platform, you can actually reserve
a static IP address, and as long as it's assigned and
being used, it's free for you. So you can go in, create
your instance, let it run, get a static reserved
IP address that you can use from your
personal devices that stick around waiting for you,
and you don't pay anything. So again, we can
run a personal VPN with a static IP for
nothing each month. And again, if you eclipse
the one gig free tier, that's when you
actually start paying. Let's talk about two
specific scenarios here. What if you want
better bandwidth? So what if you're
traveling and you actually want this VPN because
you need to stream some video from some
different location, right? Well the important thing
you need to understand is that the throughput
for a GCE instance changes based upon
the core count. It's actually capped
at the core count. So the more cores you have-- you
can see here that on the side there, we're at our
64 and 32 cores-- the more cores you have, the
higher your TCP throughput. And this is where
a lot of people get caught up when
they're trying to increase their
bandwidth for their VPNs, because you'll
notice that moving up from the F1-micro, the next
available option is F1-small. Which you would want to
use because that's going to be one of the cheapest. However you notice because
the number of core count is the same, we actually
don't get any better bandwidth by moving to there, even
though it's only $14 a month. Moving on to the next one. The actual first stage
you get where you actually get some bandwidth increase
is actually the N1-standard. So unfortunately, if
you're moving up and trying to get better bandwidth,
to even get it there, you have to start paying $24
a month for your VPN instance. Unless of course it's
preemptive, in which case you get it down to $7
a month, but then you have to deal with
what happens when you're in the
middle of a session and your VPN decides to die. So let's talk about
something I deal with a lot. Traveling. So a lot of us are
international nomads. We spend a lot of time traveling
around, going to conferences, talking to customers
and whatnot. It'd be really nice if
we had our VPN follow us because if we boot up a
VPN and US central one and yet we're in
Malaysia, we don't want to wait for our packet to
go all the way to the US and then come back to us
because that's just going to make our experience bad. So I actually put together
a little hack for this that I wanted to
share with everybody. So it turns out that
you can actually run the Google Compute
Engine APIs from Google Cloud Functions. So I actually wrote
a little web location that I host that when I
load it while I'm traveling, it'll figure out
what my location is, and in Google Cloud
Functions, it'll figure out what
the closest zone is that I can run an F1-instance. It'll kill whatever the
previous VPN instance I have is and actually create a brand
new instance as close to me as possible. So as I'm traveling,
I can basically just click a single
button, kill the old VM, and create the new
VM as close to me as possible, no matter
where I am in the world. Again, for free,
because then I'm not doing more than
two million invocations of Cloud Functions per month. So this is really nice. So if you want to get the people
in your family using your VPN and maybe charge
them $10 a month, this might be a nice little
racket to play at Thanksgiving. All right. So let's talk about something
a little bit closer to home for a lot of you,
is WordPress site. Anyone WordPress
experts in here? Couple people. Still no caffeine in the house. I like that. I like that. We're closer to 9:00 AM now
and everyone's still sleeping. This is good. So WordPress is a large
and unwieldy beast, right? There's lots of different
components involved and lots of different ways
you can take this. So when you actually Google
for WordPress Google Cloud Platform, the first thing
you're actually introduced to is a page for our
Google Cloud Launcher with all of these pre-configured
operations that allow you to one click deploy a WordPress
instance to your Google Cloud account and just get
up and start moving. So you can click any
of these and they have a bunch of
different configurations of how you want it all set up. However, the default
setup for this is actually less than ideal
from an expense perspective. So these are all going to be set
up with an N1-standard-1, which is $24 a month. And of course, you're still
paying that $0.12 outbound egress from there. So this is putting us in
something we've seen before. But let's talk about
complexity here. So what if you're using
the simplest WordPress site possible? Well obviously you don't
need-- and you're only using a single instance, right? Because you don't
have that number-- that many number of users. Well, you can actually use
the F1-micro for this instead, which is free per month. And again, if you're under one
gigabyte of outbound egress, you can actually get
that for free as well. So if you're a brand new
startup and your friends are all like, hey, go sign up
for this website over here, it's $10 a month to host
your WordPress site. And you're still live in on
ramen out of the VC incubator along with 40 other
people, this actually saves you that $10 a
month to buy more ramen. Yay. But the question
that we have then is the concept that we're
free as long as we're under the free tier. And this is something
I've been harping on for a while is, what is the
cost before we eclipse that? So if we assume that we've got
a network of one gigabyte free, and our default WordPress site
that you deploy on App Engine is about 272k per
visitor, it means you can get roughly about 3,800
visitors a month before you eclipse that bandwidth and
actually have to start paying. And this is a really
important number for startups, for the hustle and
flow type people. Knowing how many
visitors you can actually take before you have
to start paying money and where you want to start
optimizing all of that data. And of course, we could go into
a massive diatribe about how to properly optimize your images
and compress your headers, and serve all that data. That's a different talk. Right now we're just talking
about the fundamentals. So right here we
basically say if we're under roughly about
4,000 users a month, we should be OK and
always in the free tier. And of course, if you turn
on caching headers, that will put things
going into the CDN so it will increase this
number significantly because the more users you
have that hit the same content, it doesn't come out
of your main bucket, it comes out of a
different bucket, and you get a lot more users
to hit your information. But what if you actually
end up on the top of hacker news suddenly and you need
to start scaling up and down? Well, the cool thing
here is that putting the load balancer between the
CDN actually lets you do this. You end up with the same
egress, $0.08 per gig outbound; and the same fill,
$0.04 per gig fill. And we can actually end
up with the F1-micro. The problem now
we have though is because we have a number
of instances instead of a single one, you
need a persistent MySQL instance for each of
your Compute instances to be able to sync between. Now unfortunately, as
of today I could not find a way to get a free tier
setup with the SQL instance. So that's going to be
around $29 a month. So if you're above
that 4,000 user mark and you're expecting
scaling, the minimum cost you're going to end up
paying is around $29 just to make sure
that that Cloud SQL instance is sitting around. Or you could run it on your
own and N1-standard or F1-micro and deal with all of the
provisioning and everything else yourself. Now it's worth noting
here that there's also a plug-in for App Engine. So if you're running
WordPress and you want to run it on App Engine
instead of dealing with all that other stuff,
you can actually run it on an F1-micro instance--
or F1 instance on App Engine and get that down to about
zero dollars a month. Unfortunately, you still need
the SQL scalable back-end, which runs on its own instance
at about $29 a month as well. So something to think about. In general, if you're doing
WordPress on Google Cloud Platform, I got to
tell you there's three strata you
need to think about to make sure you're really
thinking about your shoestring style budget. If you're under 4,000 visitors,
just to use an F1-micro and turn on the CDN
and you'll basically get the whole thing for free. Which is fantastic, right? That's where we all want to be. If you're above 4,000
visitors, then you need to start thinking
about stringing together Compute Engine plus
the load balancer, plus the CDN, and
plus the SQL option; or using App Engine
to do the same. Because you have
enough users there you need to start making
sure that you're doing things properly. However I got to
tell you that there is a number of hosted
WordPress companies that have their back-ends built
on Google Cloud Platform that do offer you a
subscription based service. So paying $4 a month, they'll
host your WordPress site, they'll deal with
all the scalability, they'll deal with all
the security updates, they'll make sure everything
is running in the background. You don't have to lift a finger. And it might be a
cheaper option for you to fall into that bucket if
you're above 4,000 visitors. So that might be
something to look at too. All right. A final topic for the day. Video content site on
a shoestring budget. So with these things
in mind, we have to look at what it would take
to make an education website or like an online mook. You have students
that log in, they have some data they want to
look at they, watch some videos, they take some tests. You know, maybe you
have maybe a sports site that's streaming all of your
high school sports games and you got a lot of video
that you need to transfer. But you have some combination
of rich multimedia and rich website presence. So with a standard
layout here, you would probably have to store
that video data in Google Cloud Storage and serve
that right to the user so that you can get
streaming capability. You don't want that
going through a proxy, you want that coming
straight to the source there. On the website
side, you probably have an Apache instance or
maybe a WordPress instance that is actually
hosting your website. It's got some connection
to some relational database so we can keep track
of who the users are, what data they've seen, and any
other keywords that you need. And then of course, you've got
your standard load balancing and CDN in front of that so
you can scale up, scale down, and make sure that your
data is consistently sent to users around the world. This gets pretty
pricey, unfortunately. You're looking at $24 for the
Compute engines per instance a month. You're looking at $29 for
the Cloud SQL instance. Of course you've got your
fill and your egress costs. But where you really
get hit here of course is serving that video. Now as of today-- and again, this can change
in the future-- internet-- if you're watching this
sometime in the future. As of today, the
Cloud CDN that's coming from Google Cloud Storage
does not cache 206 responses from an HTTP header. 206 responses are the ones that
are used for streaming video. Which means as you're
streaming video, it's not going
through the cache. So we have to be very
cautious of this, which means we're
going basically into the $0.12 per gig ratio if
we're streaming data directly from Google Cloud Storage. Not really ideal. This whole thing can
get pretty costly. But there actually is
a solution if you're willing to make a
couple of changes. We can get it's almost down to
free instead of all this cost. So first off, if you're
willing to make some changes, leave your CDN in
place but instead of actually using a dedicated
Compute Engine instance, switch over your page serving
to be something invocation based like Cloud Functions. Minimize all of your crazy
complexity down to something that he can use a template
for to just scrape the data together,
put it together, send it down in the HTTP
request as easy as possible. Make it invocation based
so you don't really need to do that much
in the back-end. And as long as you're under
two million page views a month, you can basically get that
entire serving process for free. Which is pretty nice. Likewise, instead
of using Cloud SQL, try to use Cloud Datastore
for your relational database. If you're on a
shoestring budget, Datastore will still
give you the performance you need because most of
it is fetch based if you are using a website like this. And it has its own free tier. If you're under one
gigabyte of stored data and you're doing less than
500,000 reads and 100,000 writes per month, you
basically pay nothing. Which I think is right in the
range of a MOOC-style startup because you don't really have
all the visitors you need yet. And even successful
ones are probably not doing 500,000 or
100,000 per month. And a gigabyte of
relational data is actually a lot
in that scenario. So we can basically get
our entire web site serving and back-end storage
for about $0. Now the problem,
though, is what do we do about the video content? Because there's no
real other place to store this in Google
Cloud Storage because of 206 responses. My only solution here,
a little bit of a hack, store all your video in YouTube. Upload your video to YouTube,
leave it is unlisted, and basically when you're
streaming your embedded URLs down to your user, obfuscate
the hell out of your code so they can't figure out
where the video URLs are. If you can set it
up this way, you get it entire content serving
and video production platform for free. A lot of chuckles, yes. This slide is very
contentious internally. We had a lot of talks-- we had a lot of talks
internally about whether or not that
last little animation should be in this talk at all. So with that, I want to thank
you for your time today. I want to thank you
for being the hustlers and the grinders working on
your costs every single day. I want to thank you for
waking up this early to hear another bald man rant at you. Most importantly, if
you care about cost, if you care about
the performance your Cloud applications,
I got to encourage you to check out our YouTube
channel for Google Cloud Platform. We have a ton of amazing people
working on amazing content to help you lower your costs,
increase your scalability, and basically get your Cloud
application to where you want it as cheap as possible. With that, thank you. Stay sunscreened, stay hydrated. Enjoy your last day of Google
I/O. Thank you very much. [MUSIC PLAYING]
