Watch this episode on YouTube.
Reasonably Accurate 🤖🧠 Transcript
Morning everybody. How you doing today? In this episode of the show, we're gonna talk about serverless. Now, a lot of you are probably uh have heard the term serverless but aren't quite sure exactly what people are talking about. And that's no surprise.
There's about three different definitions of the term serverless that are floating out there. And we're gonna circle back to all three of those. But the primary focus of this video is on what I truly believe to be where we should be focusing our efforts around serverless.
And I'm not the only one. So I've been talking about serverless within this context for a few years. Um But don't take it from me. Look at this clip from uh Doctor Verner Vogel, the CTO of amazon.com at the AWS summit in Santa Clara a couple of weeks ago.
But it's so much more so for this, by the way, than just lambda. Lambda was just the last piece that was needed to stitch things together so that you never had to think about serves any any more. Now, I think the general model for servers is really that you have no infrastructure to provision it scales automatically, you only pay for what you've used.
And you know, the service itself manages high availability and security for you. So you can see from that short clip that Dr Vogels is really focused on four main areas that define a serverless architecture or a serverless design. He talked about not having to provision anything, so not having to set up um instances, set up uh services ahead of time.
He talked about auto scaling. So things go up and down the capacity is just there. You no longer have to worry really about capacity management. And he talked about value for money. So truly only um paying for what you're using, there's no idle compute time.
And of course, the fourth aspect is being highly available and very secure. And that's really the thing that I wanted to talk about was the security aspect of that because as much as the naming has been a debate and you'll see if you watch that full um keynote by Dr Vogels, you'll see he talks about serve a full and server less and it really doesn't matter what you call it.
Um But as long as we're all talking about the same thing and I think that's really key. Here's a little bit more from Doctor Vogels and that's not just lambda. I mean, it's all the different capabilities that we've seen at AWS over the years S3 is surface matches this description perfectly Dynamo DB.
Yeah, or Aurora surface or all the other integration capabilities that we have to stitch your applications together, whether they're the step functions or SNS and SQS and API gateway and appsync. So you can see in that clip where he was talking about the fact that uh serverless is not just LAMBDA.
Um And that's obviously in the AWS context, but in the Microsoft context, it's not just Azure functions in Google context, it's not just Google cloud functions. Serverless is this design pattern. And I think that's a fantastic way to look about uh at it because it gets you thinking about the value and the business outcome.
What are you trying to do for the business? You're not just building something for uh building its sake, you're actually trying to draw value for your business, you're trying to serve a customer need. And I think that's the way we need to think about serverless in the security context is holistically, you don't just have code running in a function in an Aws lambda function.
You've got data sitting over in a database server, you've got an authentication service, you've got a whole bunch of other aspects to this application. And if you myopically think about serverless security being only about functions, you're going to shoot yourself in the foot.
And I mean that, you know, that sounds aggressive, but there's been a lot of noise lately in the security community around serverless security. And I understand it's far easier to say serverless security is just about securing your Aws LAMBDA functions.
And even there, they're talking only about the code and that's a part of it. That's an important part of it. But it's only one aspect of sort of three major pillars around serverless security. So you've got functions, you've got serverless choice and then you've got data flow between them.
Those three pillars are where you need to focus. If you only focus on one, you're not gonna have the holistic view of security that you really need. And I think that's important to keep in mind. Again, you can call it whatever you want.
We've had that debate within the service community for years and I'm not interested in rehashing it. What I do want to call out is that there are really three ways I see the term serverless being used. Now, I fully um I'll use it in the context that Dr Vogels did where it's referring to the design pattern.
But the more common use and we're seeing this in marketing materials pop up a lot in the security space, a lot in the developer tool space where they're talking about serverless and they're actually talking about functions as a service.
So here we're talking about Azure functions. We're talking about Google cloud functions, eight of LAMBDA and things like open whisk. And they're talking about having your code running in somebody else's um ephemeral containers that just execute by a trigger and then are destroyed or lay idle until they're required next time within your account.
That's a great server list. But that's a great service. Let me see. I almost even made the mistake. That's a great service functions as a service, but it's not the entirety of server list, but most common usage. That's what you'll hear.
People talk about cuss and they're really only talking about Aws Lambda challenge. The second common usage as you'll hear as an adjective, people will describe something as being serverless. So uh in this very keynote that I've quoted here, um Doctor Vogels goes on to talk about or previously, he had talked about um Aws Fargate, which is a containers service as being serverless.
And the reason there is that it is abstracted away all of the attributes that would make it server full. So yes, there's a bunch of stuff going on under the covers, but go back to his four pillars of a definition of sort of a serverless pattern is that in Fargate, you no longer worry about provisioning.
You don't worry about scaling it will scale for you. You're only paying for what you use and it's highly available by default and secure by default. So Fargate is a serverless container service. So that's being used serverless as an adjective.
And again, that adds some confusion to the mix. But I understand that usage. And then the last usage is the one that I hold near and which is a now and again, talking about Serverless as the architectural pattern, as the bigger design approach.
And I think when you're talking security, you absolutely have to use that definition. Serverless is an architectural approach. If you only look at one service within this entire mesh that builds up your application, that's not security, that's a part of security.
But you got to cover everything else and you have to cover the systematic hole. We're now talking about a distributed system and system security is very different than an individual service or an individual endpoint within that mesh. You need to worry about distributed challenges, distributed problems, the flow of data among those services, how you pick those services and yes, the code that's running there.
So a little bit of clarity, hopefully, um you can use this reference graphic to remember those three definitions. It's important to actually stop people and make sure that you are talking about the same thing because even if you don't go with my preferred definition of being the architectural pattern, if you're talking about functions as a service and someone you're talking to is uh thinking the architectural pattern, there's gonna be a mismatch there and that's gonna lead to security problems.
Communication solves the vast majority of problems in these instances. So be sure to make sure you're using the same definition as the people within that conversation. That's the show for today. Let me know what you think. Well, how do you serve us uh at Mark NC A in the comments down below.
And as always by email me at Mark N dot C A, I'll talk to you online and we'll see you on the next show.
