Cool.
We are here today to talk about AWS Lambda in five minutes.
My name's Brian.
You can reach me at the link on this presentation and anything that's blue is usually gonna be clickable when you get the slides.
So let's talk about AWS.
Lambda.
Lambda is a cloud functions product from Amazon Web Services.
Cloud functions are a tiny little bit of utility compute-it's compute that you can rent per the millisecond, that was launched in 2014, which makes it eight years young.
And it really is sort of the darling of the of the serverless movement.
Which is leads us to a quick dig aggression, what is serverless?
So, yes, there's still servers in serverless, but serverless is more of an ethos than a particular technology.
Now functions as a service is a really cool idea and cloud functions are definitely serverless, but not all serverless things are cloud functions.
So serverless is really an ethos about outsourcing to specialist vendors, non-core business things.
So if your business isn't building data centers, you should probably outsource that to a provider, a cloud provider.
Now, if you're looking for a way to describe a cloud function centric architecture, there is a term for that, and that's called functional web apps.
And I've got a link for it here on this page.
A bigger question that people are gonna ask and why is this important to me?
And why should I care about, you know, utility compute?
Well, a good reason is that this is just sort of an inevitability with industrialization.
As time goes on, accelerate technology tends to accelerate.
It gets smaller, faster, cheaper, and these forces are compounding.
And so instead of you paying to over-provision servers, in case you get a spiky event, you can take advantage of Amazon's economy of scale and, and let them figure out the provisioning.
And you'll just rent the compute, ideally down to the millisecond.
Another aspect to this is specialization.
So.
This is what AWS does.
And what you are doing is, is probably uniquely differentiated.
And you want to focus on that business, not the business of building infrastructure.
So this lets you outsource the undifferentiated work and focus on your unique value.
It also allows you to be more free as you're doing software development.
You won't have to worry about things like patching.
The big features for the compute platform that is Lambda is it can run any run time.
Node and Python are by far away the most popular because they have kind of the best cold start performance characteristics, but you can run anything.
There's PowerShell, there's Rust, there's Deno, there's all kinds of ways to run pretty much anything that runs on Linux.
And so you can run on X86 or ARM architecture.
You can have a 10 gigabyte temp disc up to 10 gigabyte temp disc.
It runs in the most regions out of all the cloud providers and regions are a feature, especially if you need to have your compute close to someone in particular or customers in particular, or maybe for legal or compliance reasons you have your compute in a particular region.
Amazon has the most event sources for cloud compute cloud functions compute.
It has the shortest invocation time down to the millisecond and the fastest scale up.
There are lots of cloud functions providers now.
This technology is maturing, but there's sort of three roughly buckets we would put these technologies in.
There's virtual machine based, which is Lambda.
There's container based solutions like Azure functions and GCP functions.
And then there's isolate based cloud functions, which run on V8 effectively.
These aren't necessarily one better than the other type comparisons.
They have different performance, security, isolation, and runtime capabilities.
Obviously with isolates, you only get JavaScript with something like Lambda, you, you probably get the best performance characteristics, but you also brought a whole operating system to the party.
So maybe, maybe that's more than you need.
The use cases are broad.
This is very mature technology now, you can build everything from CRUD apps to real time apps.
There's MMOs being built with, with Lambda there's big data processing going on.
I think the most, you know, important cohort for this is startups that are looking to move fast.
You don't have time to worry about deploying clusters or chasing um, infrastructure concerns when you, you need to be finding product market fit.
Now this doesn't come for free.
It means you have to think about how you build your system in, in particular that, your move to a stateless model.
So you have to think about, or architecture in a new way.
Lambda's incredibly generous, free tier it's.
You can get up to 1 million invocations a month for free, which is, I found more than enough for most use cases in low traffic situations or occasional use situations anyways.
It's cheap after that it's 20 cents per million requests.
So for a buck, you get 6 million requests.
That's, that's pretty incredible.
There are always going to be fear, uncertainty, and doubt about a technology and the big one with Lambda is lock in.
And, and the thing about lock in is you're basically, you're worried that you, you don't have portability.
That code isn't gonna run one to one on another cloud vendor and that's true, but I also think this is a bit of a red herring.
The first concern about lock in would be that you don't want to get broken and then have unplanned work.
So a typical situation there would be they'll, you know, release a new API and they'll deprecate an old one.
AWS doesn't do this.
They, they keep their APIs around forever.
So you don't have to worry about breaking changes.
You sometimes hear people are worried that they might raise prices.
There's three cloud vendors that are competing heavily for your compute workloads right now.
And they've only dropped prices since they've all launched.
So I'm not worried about prices going up for compute it's rapidly approaching zero.
Poor performance is a bit of a red herring also, I-there are ways to mitigate cold start.
There's two in particular.
One you can just not have cold starts by writing smaller functions.
The other way is that you can pre-provision capacity so that your functions are always warm.
So this is really not an issue anymore as far as performance goes.
There are legitimate objections to Lambda.
The big one being that it just doesn't really support traditional databases very well.
Traditional usually relational databases require sockets to connect and Lambda is inherently stateless.
So if you get a bunch of traffic, you're gonna have a bunch of Lambdas trying to connect to your database all at once and it'll knock it out.
So that's, that's a bit of a bummer.
You, are kind of backed into having to only use managed database for whatever it's worth-we're extremely happy users of DynamoDB, it performs great.
But you know, that's a choice that we have to make and Azure, they have Cosmos and Google's got a few different databases.
So the other two big kind of concerns are basically that AWS is kindascary.
And this is true.
AWS is very big.
I mean, it's, there's a lot to learn.
I don't think that means it has to be scary.
There's always gonna be new services, but you know, the core stuff that you use is gonna be quite stable.
Lambda has been around for a long time, so there's a ton of knowledge there to draw on, a huge community.
AWS billing is another concern that I think is, is real and it's legitimate, but it's mitigatable, but people don't necessarily want to, you know, have a credit card attached to this infinitely scaling compute thing.
And that's understandable because you know, you don't want it to run away and, and cost you a lot of money.
There's a few tools out there to help with this, but really at the end of the day, I think it's a bit of an overblown concern.
It can happen.
I'm not not saying it can happen, but I think if you're, you're pretty diligent, and if Amazon knows it's a mistake, they're usually gonna be good and honor it.
So then the final sort of thing would be like, how do I do this?
How do I build for Lambda?
And I'm gonna strongly recommend that you consider an infrastructure as code solution is the way to get there.
You don't have to use infrastructure's code to deploy.
You can deploy with the SDK or the console or, or CLI, but, these methods are manual, which requires following checklists, which makes them quite error prone.
And so the best way to build for these things is to use infrastructure as code.
This is a practice where we will describe the outcome of the infrastructure and we'll check it in with the code it depends on, and that way, every time we deploy we'll have the exact infrastructure that we need.
This is great because it means we're totally deterministic and we get the same deploy everytime.
It's almost identical, and as a concept to dependency management, where you check in a manifest file.
There's a few options there.
I'm a bit biased.
I think Architect is probably the best one.
So thanks very much.
And if you're looking for any follow up stuff, you can find me at all these links.
Have a great day.
