PyCon Ireland 2019 – Serverless Scheduling using Python Step Functions – Ben Ellerby

PyCon Ireland 2019 – Serverless Scheduling using Python Step Functions – Ben Ellerby


MR ELLERBY: Hey thanks for coming, my name’s
Ben and I’m an architect developer at a start up that helps start-ups launch digital products. As I mentioned I work at Theodo we’re a start-up
that helps start-ups launch digital products. Made.com are a large E-commerce start-up in
London and various countries. We helped them build their website, mobile
App and sharing experience. We are all full stack engineers and today
I want to talk about some of the newer stuff we’ve been doing serverless. We’re full stack — Before I jump into the talk there’s a couple
of things I am doing outside of my day job at the moment. I run a blog on serverless transformation
if anyone is interested in serverless or anything from the talk feel free to follow it. I also run a newsletter each week with the
type five articles of the week and that QR code will be at the end as well. What is serverless? Has anyone here deployed a lambda function
before? Or any other cloud provider they are similar
concepts. I’ll go over what serverless is, it means
different things to different people. What is this serverless thing? It’s an architectural movement from my point
of view, also the name of a framework which is super confusing, serverless is code framework
that is good to use, but it makes talking about the topic confusing. Why I say it’s architectural (inaudible),
is because it changes the way developers work, we send pure source cloud to cloud provider
and it’s run on containers isolated from us. It can scale up, we’re not concerned with
the operating system and we can focus on business value to our application. Why do people do serverless? There’s a cost reduction, you might have seen
the hacker news article recently which puts it into case a bit. It can work really really and reduce costs
and I’ve seen that for several clients there’s a move to no ops, it’s definitely not that,
it’s DevOps, but something better, having autonomy to deploying new environments quickly,
but helping and coaching them provide information. It allows developer focus on business value. On the previous slide I mentioned it’s not
just this sending of application code in functions of servers but using third party cloud native
services when necessary, so as well as building your own user authentication using something
like Octa or something else to manage users without having servers to manage that, really
trying to use everything as a server that you can. It’s more scalable so from day one you don’t
have to think about scaling so much, as long as the code is stateless, and as we make better
usage of server utilisation in data centres we can reduce the amount of data centres we
need, which could reduce the carbon footprint of the internet which at the minute is the
equivalent to the aviation industry and is only growing with the rise of streaming. Serverless is not just functions of service,
AB. S lambda is what people talk about but here
we have other cloud providers of your choice, API gateway for routing, cog neaty, Sqs, step
functions which will be the topic of this talk and many other AWS services where you’re
not managing the servers yourself or aware of them. This gives a great deal of power and flexibility
and can build event driven architecture, today we’ll focus on lambda and step functions to
do serverless scheduling. It
let’s you send up application code that’s run on isolated containers that can scale
out to thousand of lambda functions you can set rules and it can be triggered by many
services, in terms of run times there are many native supported ones, nodejs.net, Ruby,
you can run your own, I have a client running serveless PHP, I wouldn’t recommend it but
you can. As you can imagine we’re doing serverless
Python, there’s 3.7, 3.6 and 2.7, the way it works with versions is they become deprecated,
they move off the platform, but if you have legacy code you’re running you can run to
particular versions needed. What is the function, that pure function sending
to a cloud provider in the AWS lambda model it’s a handler function it takes two things,
an event, APi is a Dict of the gateway passed in, from other services the format changes
and it’s also context, that’s context of the request. So maybe some metadata about the request ID
and any X-ray tracing you might have, further login data and other thing you can config
and all we need to do is return value. In a super basic example we are taking in
an event, that event — let’s try not move it too much. We have a handler function that takes event
and context and then can return a response. Handler function is triggered by AWS whatever
trigger you use coming in, with API gateway that’s often a get post with HTTP. Serverless framework is super useful, it let’s
you write code in Yaml, it’s abstract to different cloud providers which can help you work differently. Not sure that’s going to work. I have another adapter in my bag, I might
just grab that. Okay that’s working better. So serverless framework. Let’s us do code (Inaudible). How do we install serverless framework? We can install it with npm, we won’t see any
Javascript I promise, we install it globally, we can run serverless create, with template
AWS Python 3 and path which everyone calls the service. Then it generates a Yaml file and a handler.py
which is the function that will handle the event. So here we have a simple hello, it takes an
event and context, builds a body and runs with a status code, a Json.dumps net body,
triggered from gateway front-end single page application, these will click, that will trigger
a lambda function that will send back response which will come back through to the user. The serverless.yml is simple, we have the
service, provider, function and we’re doing handler.hello. We can invoke it locally on the command line
with -f hello and the command comes back with status code and body. If we want to deploy it we do SLS deploy and
SLS invoke -f and we get the response back. That’s running in whatever region we choose
to deploy to. And here we’re triggering with API gateway,
there are many services in AWS or other cloud providers that trigger function as service. That serverless in a quick overview and let’s
jump back to use case, the problem I was trying to solve was scheduling of e-mails, it was
a platform, I won’t go into business context, but basically they need to get a load of users
to be sent an e-mail, other users who were admins to schedule them to go out, a pretty
basic use case. Really it could schedule any event that’s
dynamic, this is not something happening every month, it’s changing for different users. In Python we think celery, it can manage work
flow, it’s distributed written in Python. If you want to schedule things, Celery Beat
is a scheduler that kicks off tasks at regular intervals and checks for tasks that are scheduling
so you’re polling a database. It could look something like this. Don’t have multiple Celery Beats because otherwise
strange things happen. As you can probably tell from the start of
this talk I don’t want that many servers I don’t want to see any servers I just want
to write application code. This is where step functions come in and we
found a nice flow in the project for how to manage this. Step functions let you create, coordinate
multiple AWS services in a work flow that allow you to in a serverless way have a work
flow through different services, it looks something like this, a bit like celery, you
can have a number of different steps, a start and end and all work through, you can have
different conditions. There’s a number of different ones supporting,
the list is growing currently. In cloud formation which is the native infrastructureless
code, it’s a bit verbose, that’s one step that says hello, that’s too much code for
me. Serverless step functions is a nice plug into
the framework, it’s a nice model that is easy to contribute to. And here once we have installed the serverless
step functions plug-in, we can find a state machine with a name, we can say what the states
are and we can say if that’s the end states and that’s all we need to do. Jumping back to our user case of scheduled
e-mails we wanted two use cases first in first out user click as button and people get e-mails,
we also want a date queue. We started calling First In Date Out, Fido
was born. It’s also turns out on Wikipedia a demonstration
of unwavering loyalty which always sounds good from a scheduling service, so we stuck
with it. What does Fido look like, it’s a first in
date out queue, which isn’t a thing, it’s an API gateway trigger a Lambda function e-mail,
this will trying triggers an instance of step function which has a start state, a wait state
I’ll go into, but that waits to a given time or particular number of milliseconds and then
we have a push to SQS which is a queueing service that allows us have a dead letter
retrial logic then a Lambda function to send an e-mail, a push notification, to generate
a report. It’s agnostic to what you are doing at the
other end. Let’s look at the state machine, we have start,
wait, push and end. Now wait is an interesting state, because
the whole idea of serverless is your build based on runtime, if I schedule an e-mail
for three months time I don’t want to be billed for three months. Luckily step functions are billed in an interesting
way, you are charged over the number of step transitions in the application, not overrun
time. So here we’re charged for each of those transition
steps. Not for how long we’re waiting for. You are limited to wait for a year, you can’t
go longer for some use cases won’t work, but ours it was fine. So we call a Lambda function to schedule e-mail,
that triggers start, it will wait till a given date, it will then push which is this step
here is calling the trigger to a Lambda function and that function is pushing to SQS which
will get picked up by send e-mail Lambda function, the finite state machine written in the serverless
framework looks like this, name of the state machine which is e-mail MSM, states we’re
going to state at wait for due date states, that’s type wait as you might imagine. This is the parameter that stores the due
date in the event that comes through and next state is push e-mail. Push e-mail is type task which means it will
go and call the Lambda function and we give the arn, the identifier of that function. SQS a queueing system needs to be configured
you can do it in the cloud formation, but I like doing everything in the infrastructure
file. We have an e-mail queue which is SQS queue
and gave it a name, there are lots of parameters you can give about dead letter queue handling,
concurrency, etcetera. This function is not named correctly, it should
be send e-mail, but this is what’s consuming the other side of SQS queue, if you jump back
this is the Lambda function here that calls third party to send an e-mail. Here we’re saying event is SQS, and we give
the arn of that SQS queue and automatically when anything gets pushed on the queue it
gets picked up by the function. The event we pass through the function looks
like this, due date when we want to send out, we have from, the e-mail it’s from, a to which
is Pycon and subject is serverless. We implement it a little differently we gave
a UID of template and UUID of a tag, we didn’t want it to get too big. The scheduled e-mail Lambda function, what
is it doing, it’s using boto 3 client, it’s instantiating that and it’s using the step
functions as part of it, it’s calling start execution, so it gives the arn of the state
machine it gets from the environment variable, you can set environment variables for Lambda
function in serverless conflict, you can pass arn through there. We are giving event.schedule, that’s a name
and the input is the body of the event we have got through. Event through Lambda function contains metadata
and body is Js.insurance you pass through. Then we have a return of 200, return event
body, we don’t need to. All we are saying is cool, got that, put into
the finite state machine, Lambda function waits for 15 minutes, can’t wait for two months
to run, it would be expensive. Next is push e-mail, we’re waiting in the
step function and then come on to push. This needs to push to SQS, again we instantiate
bot 03, SQS will call client send message, we give the event queue of the SQS an again
pass the body, so the body has gone through the finite state machine and push through
the SQ S queue and that will be consumed at the end, response is 200 event pushed. The final Lambda function involved is send
e-mail, here we are constructing mail, mail is a class that comes from send grid, actually
bought by Twilio, you can use SES and AWS others are available. We are going to construct a client using API
key, you can use SSM, Secure Sequence Managerwhich is encrypted and a little more secure, so
Lambda function has to have the right IM policy to be able to access this key, we are then
going to return a response. Going to get the response from send grid,
we’re going to print out some data about that and then we’re going to return 200, e-mail
was sent, everything is good. I’ll just jump back to the finite state machine
for a second. So we started here with schedule e-mail, that’s
triggered through the bot 03 Sdk in Python, invocation of the step function, we are going
to use the wait state to wait a given state time, we’re not billed on that, that’s abstracted
from us, we are not polling, I imagine AWS are polling somewhere, we don’t need to care
about that. We are not running any code between when we
push the event and when it happens. We then push the event on to a queue, so push
e-mail is the next step after wait, that event body has been passed through the whole way
down. We are going into SQS queue and send e-mail
is listening on that queue. That was all that was needed to get our scheduling
working and it worked in production for months and it’s all great. There are some constraints around you can
only wait for a year, you can only have a million step functions being invoked at the
same time which for some people would go past some limits, they probably go past that limit,
but step functions are a nice way to create work flows. AWS provides good serverless services for
Python and the iser was framework plug-ins allow to you manage scheduling nicely. The syntax is concise, that won’t be cross
provider, I’ve not tried with Azure or GCP but they are catching up on some of the serverless
services, so I think we’ll see that kicking off soon. Before I finish and get some questions, as
I mentioned serverless transformation is a blog, I’ll write an article and put slides
on it from the talk, I’ll also tweet out the slides if anyone is interested. I run a newsletter so every week we send out
the top five serverless news articles. And we also run a serverless podcast on Spotify,
you can listen to interview with people doing serverless production, Python, PHP and different
use cases. The final thing is we opened an opensource
tool last week, SLS-Dev-tools only works on AWS at the minute, but gives you visibility
of the way you deployed what you deployed and logs to give you internal feedback with
simple visibility and targeted metrics. As a developer I don’t want to log on to a
web portal to debug my back-end code, I want to stay in the ID and terminal and not leaving
anything else. So we get this interface in our terminal,
so you run SLS Dev tools the name of the stack and get an overview of all the Lambda functions,
the average duration of the functions a cool 1960s hacker movie map of where your servers
are deployed, logs at the bottom of what’s happening and some new graphs that will come
soon. That’s released and I welcome any feedback
if anyone is interested about it, feel free to ask me at the end. I have been Ben, feel free to toll me on Twitter,
one of those takes you to Twitter, one to the blog article, I can’t remember which is
which so subscribe to both, so if you have any questions feel free.>>So in terms of performance can you talk
a little about the benefits for that with using serverless just over having a bunch
of servers, is there any specific advantage in that around performance? MR FINUCANE: I don’t have any metrics off
the top of my head, but for us on this project serverless was coming from a total cost of
ownership. They didn’t have the facilities to manage
the services, they didn’t have, they had a ten year legacy that migrated from on premises
to cloud, they were tired of dealing with server, from performance point of view we
have not had any problems, in terms of application it runs exactly the time we’re expecting,
we have not do a lot of measuring, with serverless you have cold start times, that’s the first
time, it’s not in the containerisation of cash in AWS, if you do a warm invocation,
someone calls Lambda function and someone else calls later they will get a fast response,
the early one can be slower, we can mitigate that by keeping the deployment package small,
keeping the Lambda small, keeping the number of packages small. So we’ve not noticed problems, but I don’t
have stats there are quite a few articles dedicated to it and there was one in the last
newsletter so feel free to look.>>I have a question just on that, did you
package and deploy Sipy stack ever? MR FINUCANE: I haven’t, but you have to do
to Lambda fair with AWS, there’s a custom runtime API, if you deploy a Lambda layer
a way of sharing code between Lambda functions you can write a bootstrap files that ties
AWS infrastructure to your binary, if you compile that binary on an ECT of the same
AMI of Lambda it will run perfectly, so you can compile Python with all the dependencies,
but one thing to check is will you go past the limits of the Lambda function in terms
of code, but I think you will get away with it.>>I have a second question, I love the terminal
dashboard, what’s the package for that? MR FINUCANE: It’s SLS Dev tools.>>Did you use a framework for that are?
MR FINUCANE: Yes using Blessed which in Javascript, and it’s not all huge amount of code, we’re
now on 60 stars, so super exciting.>>The Dev tools replace AWS console or you
can use it as replacement to check for Lambda functions? MR FINUCANE: No definitely not, it’s not a
production observability tool, there are tools which are dedicated log in providers for serverless
application, the dashboard isn’t great at serverless yet. It has the data, this is like the Chrome Dev
tools of serverless, it’s for developers to use when coding, it’s not forgetting alerts
and observability in production.>>Anyone else? No, well thank you Ben. [APPLAUSE]

Leave a Reply

Your email address will not be published. Required fields are marked *