[Music]
good morning and welcome back to devops
uh as a quick bit of housekeeping and a
reminder we are planning lightning talks
this afternoon specifically for Dev oops
separate from the main conference
lightning talks if you would like to
submit to that if you go to the program
on the website and you scroll down a bit
there's a link to Google forms that'll
be closing partway through lunch and
we'll be picking talks then up now
though we have Luke Luke is a senior
software engineer at wsp he's worked in
the industry for seven years and has
spent more time than he would like to
admit debugging Django and python code
Luke was also a long time ago an
Australian representative gymnast
competing at the Commonwealth Games and
World Championships please welcome
Luke all right test is this thing on yep
cool um today we're talking about D
Jango on AWS for Chum change so really
the um the inspiration of this talk is
uh Heroku uh which uh when I first
started out writing python code um was a
real uh Forerunner in making it able to
just deploy python code out there and
get something out for really really
cheap I think things have kind of
changed uh over the years with Heroku
but um the eventual goal is to kind of
somewhat uh build our own Heroku in uh
in
AWS um if you want to play along uh all
the links that I have within this uh
talk are over on my website in the blog
um you can also skip ahead to see the
end of this so you don't have to hear me
R Ramble On for half an hour um my name
is Luke vitovsky well done to anybody
who knows to actually pronounce that
last name but that's okay um yeah I'm a
senior software engineer for wsp and in
my foral life I was a Australian uh
level representative gymnast um if you
want to catch me on any of the socials
Luke we is my handle you know find me
wherever um so first off let's talk
about AWS if you're going to build
something on AWS uh specifically with
Django and python um here's an
Enterprise gra grade stack Enterprise
and inverted commas because this is
about how much I could fit on the page
um ignore all the stupid names and stuff
uh I didn't really have time to draw
pretty pictures about how you would do
it um but this is kind of an
autogenerated uh thing from uh AWS to uh
show you the kind of Stack we're talking
about
here um so that's pretty complicated
it's pretty annoying um there is another
way to represent this and that is in
code um so here's the same thing uh
don't be too worried if you can't fully
understand what's going on here but
essentially all that stuff that we had
over there is now written down in some
nice easy to read inverted commas uh
python code um very logical structured
bang bang bang uh down the page um so
what we're going to do here is we're
going to play a game we're going to
build ajango app but we're not going to
scale it up to Enterprise we're going to
scale it down imagine you got this app
you've built it up and you want to share
it with your friends and family maybe
just one other person your partner you
don't want the world to see it you don't
care about scale you want to scale down
how do you do that in an AWS context
where everything is pushing you to scale
up um so I've built ajango app for my
family I want to host it somewhere um
and I don't want to maintain it I don't
want any pets I don't want to uh bother
with a VPS or anything um I want
something that I can push a button and
it'll spin up and push a button it'll
spin down and it'll largely
self-correct um the rules AWS
exclusively uh there are plenty of
services out there you can use but AWS
is the goriller in the room um and it's
a good learning exercise uh we're going
to use infrastructure as code because
we're in a python conference we're going
to write some python uh to spin up all
these Services uh in this case we're
going to use uh the AWS cdk which is the
cloud development kit I believe there
will be a lot of three Le threel
acronyms in this talk so apologies um if
I get ahead of myself and I don't
explain them all uh another one we're
not going to use any stateful services
like ec2 there's been plenty of other
talks in Pon over the years about how
you can make a ec2 instance really cheap
essentially run it as a VPS that's not
this talk I don't want to run a VPS I
just want to spit the code at AWS and do
it all for me and finally we're going to
use Jango because Jango is an excellent
uh web framework and we love to use it
and we want to deploy it everywhere we
can so um I'm going to have a little bit
of audience uh participation here so
just yell at me what's expensive in AWS
come on tell me datab databases
yes cues
storage yeah yeah
all almost every
is a good uh answer yes um there are a
couple of specific ones that we're going
to talk about in terms of Jango
specifically and that is yes relational
databases um the services uh IDs which
is yeah the relational database service
um load balances can get very expensive
as well um especially if you're just
spinning one up uh singularly suddenly
uh if you're a poor student in a dorm
room and you're paying $20 a month for
just a load
balancer yeah that's a bit a bit pricey
um not
gateways they can bite you in the butt
um and uh ads is very sneaky in that it
will spin these up for you without you
explicitly knowing a AWS is very helpful
in that scenario also like uh W where
about application framework can be
expensive too so um we're actually not
going to talk about the W we're g we're
just going to let things hit our servers
um what's cheap what's
cheap Lambda Lambda yes Lambda is very
cheap scales to zero anything
else uh spot spot instances yes very
good uh anything else S3 S3 yes the
canonical storage uh service in
AWS um Cloud front also very uh cheap as
well we
probably won't cover this today but uh
really good to um front anything you do
on AWS with a cloud front cloudfront
instance as well but yeah I think you
got them all um and we're going to
transfer over to using
these um so as I said before we're going
to use the AWS cdk there's plenty of
tools like this uh under the
infrastructure as code um umbrella uh
what are they called a terraform open
tofu
uh palumi I think there are a couple of
others on this occasion we're just going
to use uh the cdk one because it's
native to AWS and two because it's cheap
um it's very good uh I have links in my
blog post uh to just the uh the general
hello world starter on this occasion
we're using python on a slight aside um
if you do happen to use other languages
um I would say that typescript ends up
being the best in terms of support for
cdk um and uh ergonomics Python's still
pretty good um but typescript is what
it's actually written in under the uh
under the hood and that ends up seeing
uh the earliest support for newer
features and stuff what cdk actually is
um is just a wrap around cloud formation
which is aws's way to spin up all these
through like a template um cloud
formation is like yaml blobs and Json
blobs all the way down and it's sucks um
so we're going to use Python instead so
let's begin um from our Enterprise grade
stack we're going to do some quick easy
savings that should have pretty much
zero practical effects on um our
application so first off we're going to
remove the load
balances um and before I keep going I
will say what we're doing here is we're
going for the cheap services that scale
to zero there is always an inflection
point where if you end up getting a lot
of load it's often better to go with a
load balancer than the alternative um
because you get savings uh because of
the load um so this is how we would
Define a load balancer in cdk really
simple we've got our load balancer
connected to our VPC it's going to be
internet facing really nice easy
language to understand we add a listener
to Port 80 or whatever Port you want 443
I guess we should uh say here and then
we add our D Jango container um Port
8,000 which you know D Jango by default
kind of serves on that port and you're
good to go but this is expensive you
spin one of these up and you're spending
20 $30 a month just on the load balancer
alone and that's not including any of uh
the requests or services so there is an
alternative anyone want to guess what it
is uh API Gateway I've heard very good
gold star to the person in the back um
here we're going to do it in an ECS
elastic container service um context so
everything we're doing here is we're
running D Jango in a container that
makes it easy to kind of switch between
different Services um we're going to use
ECS uh because one it's cheap um two
it's native uh to AWS and makes it
really easy to spin up stuff in the cdk
uh eks is a a different nightmare um all
deployments are nightmares in some way
but uh we're not going to use the eks
because it's expensive um so yeah here
we go uh in our ECS cluster uh we simply
enable cloud map simply because
everything we do here is actually going
to be adding code and doing things uh in
a more difficult sense cloud map is a
way to add a network within your ECS uh
cluster don't care about the Implement
implementation details um but uh we add
it to our cluster we add a service
endpoints so that uh our container can
read out to the VPC link so we're inside
a VPC everything happens within a VPC
which is a virtual private Cloud um in
AWS uh and we uh attach it via an
integration to an API Gateway um all of
this trying to do it in the console or
trying to do it through cloud formation
or trying to do it through any other
method is like really really verbose and
annoying um but here we have these
lovely uh uh Integrations uh
specifically default uncore integration
equals HTP service Discovery integration
Bang You're Off to the Races you're out
to the world what we are going to ignore
in all this exercise is DNS that's a
completely different problem um which
you can do in several different ways but
we're out to the internet great and
we've saved a few
dollars um next we're going to use some
spot instances somebody over here
mentioned spot instances so here we're
going to use fargate Services because uh
I don't want to manage the cluster in
any meaningful sense AWS will spin up
all the Services Under for me uh so here
we're going to make sure that we have
exactly one container running because we
don't need more we don't need scale we
don't care if it goes down for a few
minutes or whatever um and we're going
to set the capacity providers to spot um
spot instances are what AWS uh kind of
gives you is like their leftover CPU
Cycles from other instances that people
aren't using generally speaking uh it's
a pretty reliable service but uh AWS
will cover out with that it could go
down from time to time and your service
just needs to be able to spin up and
down and know that it's it might um get
taken down generally speaking though if
you're just spinning up one spot
instance you're generally okay
especially with our application which is
just for my friends and family um if
they notice that it's down hit a refresh
it'll probably be up
again um all right those are the easy
wins now we're going to start doing some
slightly more risky stuff um with some
tradeoffs but you know uh we want to
save money at the end of the day we're a
poor college student in our dorm room
and we want to save a few bucks so we're
going to remove Nat gateways Nat
gateways what is a Nat
Gateway someone tell me because I don't
know I mean I know it does some sort of
translation uh and allows you to speak
to the public internet um these are
sneaky things uh that a AWS will spin up
for you if you just uh spin up a a
virtual private cloud with no parameters
whatsoever it will by default give you
uh three subnets a public a private and
a private with natat generally speaking
if you follow all the like guides in AWS
it'll push you to uh running your
application within the private withn
um and you run your database service for
instance in the private subnet but
basically giving you a little bit of
protection so that not everything is out
to the open
internet um but here we're going to go
straight out to the open internet uh set
NE net gateways to zero uh we might have
two subnets we'll have a public one and
a private isolated one um but we're
definitely not going to have one with a
because they uh are quite pricey and you
pay not just for the N instance but you
pay for the traffic that goes through it
as
well all right big one we're going to
remove RDS we're going to remove the uh
um postrest service the managed service
because you know what let's just do it
ourselves it's not that hard right who
who needs data reliability anyway um so
this is how you would uh Define it in
cdk pretty simple you make your database
instance and then you attach it to your
VPC set your engine and which subnet it
goes in uh this would be quite a bit of
a faf to do um if you're doing it
through click Ops or through uh cloud
formation or whatever but here it's
super easy um but we don't want any of
that we want it complicated um so here's
a really simple way to spin up your own
uh IDE uh postest service using a
postrest container Trucking it in ec2 uh
sorry ECS
actually I'm surprised that actually
fits on the uh on the slide let's dumb
it down a bit okay um so all you do is
add your e e EFS file system elastic
file uh system uh add the file system to
ECS volume add the volume to ECS task
add the container to the task Mount the
volume to The Container add the task to
the service allow service to connect to
EFS uh Mount the container service into
Cloud Nam space and you're done
simple let's compress it down a bit
let's let's talk it through slightly um
so what we're going to do uh first we
need a persistent file system everything
in ECS uh in the elastic container
service generally is like stateless and
you need to do special things to give
some State um and of course AWS has a
service or in many cases many services
that will do this for you um on this
occasion we're going to use uh the
elastic file system uh which allows you
to map basically a volume to a container
if you're if you've worked in the
container world if you've used Docker
compose Docker um you you might be
familiar with mounting persistent
volumes to Containers that's just
essentially what we're doing here um but
of course because it's AWS we have to do
it in a very um Vose fashion um so we've
got our file system we create uh our
persistent file system we attach it to
an ECS
volume
um then we attach it to the task
definition which is basically um the
definition of how we're going to run our
container um the task becomes a service
um you attach the volume to the service
uh and then you give permission um to
the service to actually talk with the
volume itself
uh remember this just remember the
pattern cuz it might pop up again soon
um so there we go we've got our own
postgress uh container running in
ECS uh we're not paying for RDS anymore
big big savings um because I think the
lowest RDS instance is still quite
expensive just to spin it up um I know
there are like Aurora Services as well
which are also very expensive but anyway
if you're doing a relational database
service in in uh AWS it's expensive as
hell um but what we could also do is not
use postgress at all um we could use SQL
light uh which you know uh on a big big
project I wouldn't recommend but on a
small project like this we're only going
to have like a couple of dozen users at
most um SQL light's pretty good D Jango
has excellent support for SQL light uh
sqlite itself yeah you can you can get
into trouble using it raw but Django
gives you a lot of protections over it
and generally in a small app um it's not
too bad uh and it simplifies the stuck
it gets rid of uh uh Network calls um
how are we going to do
this does this look familiar we had an
EFS file system we had the file system
to ECS volume we add the volume to the
task we add the container to the task we
Mount the volume we allow the service to
connect to EFS and we Mount the
container service into the cloud map Nam
space simple and cheap we've just saved
ourselves uh a bunch of money on uh
another ECS
service um some technical details here
about uh where you mount the actual
container um here we're just doing it to
the temp path you can do whatever you
want um but the you know the basic idea
is there
um and now we've kind of hit our limit
of things we can do with a Jango uh app
without actually doing anything to the
Jango app we've we've done a bunch of
stuff with services around let's cut to
the Bone um let's get
wild let's use Lambda um how do you run
ajango service and a Lambda uh
Service uh on this occasion I would very
much suggest you use a Docker
image um AWS has like python run times
and they all suck um they're all really
annoying to work with and it's just
really hard to recreate what AWS is
doing under the hood uh with their
python run times so in general I suggest
if you're going to do python in Lambda
just Chuck it in a Docker function and
then throw it over
uh so this is how you do it um we use
that same file system that we use for
SQL light um you got to do some magic uh
which is well documented out in the AWS
docs about how you mount your volume to
a Lambda
function um we attach our docket image
and then we do uh an API Gateway
integration
it's once again this will be all
complicated in Click Ops but it's
actually quite simple when you write it
out in the uh in the
code um a few problems though this will
spin you up a nut Gateway very very
sneaky
um and lambdas don't work out of the box
with a Jango uh application like this so
we got we got to do a little bit of
tweaking now within the actual uh
application code to make it work turns
out um AWS has built something to make
that really really easy so there are a
bunch of libraries that will do this
translation of what a Lambda response
does uh looks like into a HTTP response
I think Mangum is one of them that's out
there there's a bunch of others um but
what I really don't want to do I don't
want to mess with application code if I
don't have to so we're going to use the
advantage of the docker image and we're
going to use this thing called aw AWS
Lambda
adapter um the Lambda web adapter and
and basically what it does you just do
this one line of coding from public
ECR into this particular um directory in
your container and then when you run it
in Lambda you'll just get a HTTP request
you can run uh gunicorn uvicorn whatever
you whiskey whatever works for you um
and it should just be plug andplay and
the advantage of this is when you run it
locally as well it just ignores that so
you can just run python manage run
server for your local um and then you
run your G unicorn uh in production and
you should be good to go uh links there
links also in my blog post about it uh
check it out it's pretty cool I haven't
checked out checked it recently but it's
in the AWS Labs uh GitHub um
organization so it's still experimental
but plenty of examples not just for
python but for uh a bunch of different
languages
um okay there we go can we go deeper
what can we do here what's cheaper than
EFS S3 S3 the cheapest file system file
system it's not really a file system but
let's make it a file system
um so I I built this little Library here
um I will admit it's not original uh
there was something like this in uh
Zappa which was a library to help you
deploy uh D Jango applications to um to
AWS Lambda um essentially what it does
is it just downloads a file from S3
locally uh you do all your changes and
then re-uploads it um so really safe you
know your data is safe S3 is a
really um really robust uh object
storage uh
don't do this for work once again as I
say at the start um not employer
approved we do not do this in production
at all so uh don't try um so how do you
do this okay uh we create an S3 bucket
in uh in cdk super simple it's the
canonical example create an S3 bucket
whatever Library using super easy and
then we just uh map it to uh our Lambda
function here I'm using an environment
variable do it however you want um
specifically you do need to make sure
that you map it to the sltm file when
you're working in Docker when you're
working in Lambda because that's the
only writable um directory uh and then
you got to do a slight bit of Jango
settings so install D Jango SQL light
object storage uh make sure it knows the
bucket name and you should be good to
go and given all this now we have our
stack or that that big initial um stack
has whittel down to something like this
which is pretty small and gives you a
pretty good amount of functionality um
for ajango app that you're going to
share amongst people you lose a few
things um initial response cold starts
pretty slow um but you know what that's
something you can live with uh you can
do this a bunch of times if nobody hits
it at all you pay nothing which is
absolutely great all these Services
scale to
zero um there are some opportunities
that I haven't covered here uh so you
could explore scheduling of spinning
stuff up and down um AWS has uh event
Bridge Schuler I think is the name um
which is really robust and you can do
all sorts of crazy things um also with
cdk you can do crazy things with uh
lambdas for internal uh Dev opsy type
code it's really really useful for that
I used it as a um bit of a DNS resolver
for a little bit of uh time there I
decided not to use a load balancer and I
just mapped whatever the public IP
address of the container was to uh the
DNS uh uh which is not great I wouldn't
do that in real life you know it's not
happening anymore
um uh you could perhaps use Lambda as a
proxy to negate the need for natat
gateways there is a weird way you could
do that in some certain scenarios where
you only hitting external like a
specific external API and you can also
use I don't know if I'm I'm going to
pronounce this wrong
fckn um to reduce natat costs as well
there's like a cdk tutorial on how you
can just easily add it so that your n
costs go
down but that's really where we're at
we've run out of time and we've gotten
to the point where you've built your app
you shared it with your friends you
haven't looked at it a while and you
finally log into your AWS account you
look at the logs and you see nobody's
hitting it and you realize man I haven't
used that app in a long while why is it
even there anymore
um let's just let's get rid of
it and it's really really
easy through cdk to just get rid of all
those uh resources as well everybody's
got that story of I've got that one cost
that keeps coming up in my AWS bill it's
like 30 cents I have an S3 bucket
somewhere and I don't know where
um cdk and uh cloud formation gives you
a lot more um overview of all your
resources and this is super super useful
not just for when the Project's done but
for when you're spinning up and you're
just noodling around and figuring out
what to do and how things fit
together thus ends my talk uh there any
I I think we have one one minute for
questions any questions from the
floor we got one up the back and then
I'll come back for
here I'll come to
you oh thanks for the talk I was
wondering um how much weigh you or are
you paying for your personal app that
you deployed using that cheap method uh
well the the brilliant thing is that
Lambda has a whole bunch of um uh stuff
in the free tier and I'm paying zero
well that's that's unfair I'm paying a
couple cents for S3 costs I think but I
I run a few stupid little apps through
this method um and largely I don't know
the bill comes in and it's like a couple
of cents so um caveat though I will say
if your app gets
popular all this goes out the window all
of it uh you will you will suffer the
pain of um of those of those Services as
I said before there's that inflection
point at land is cheap until it's not if
you start to get really popular that's
when you have to start thinking about
switching over to something like ECS and
load balances and stuff where you you
get uh the the cost of volume actually
drives those prices down if that makes
sense sorry one more question was there
yes would you suggest using um like
event Watchers for spooling up the uh
ECS instance via Route
53's logs it's really cheeky as as I
mentioned before there are plenty of
opportunities here with schedulers and
events and stuff and because cdk makes
it super easy to spin up um little uh
utility Lambda functions yes there's
probably an opportunity where you could
spin it like spin everything down to
zero and then when you get that request
after some time out you know let's say
someone uh you you spin everything down
and someone finally hits it the next day
you hold on to the request you spin
everything up and then do the um you
know do the request very much like what
herok used to do on its free tier I
don't know if I'm talking to the right
crowd here but heroki used to spin down
to zero if it had no traffic after I
don't know x amount of hours and that
was how it kind of made its free tier
viable you could Poss possibly build
something like that too that's that's
definitely an option especially if
Lambda is not good for you Lambda kind
of sucks when it comes to you know
longer running things and things where
you want a file system and yada y so on
and so forth but this is AWS the world
is your like the Horizon opens out in
front of you and you can do a lot of
stupid
things um that's that's time isn't it
thank you all righty then thank you