Serverless Craic Ep30 AWS Serverless Services with Paul Swail from Serverless First

Serverless Craic from The Serverless Edge

AWS Serverless Services with Paul Swail from Serverless First

In this episode the team talk about AWS Serverless Services with Paul Swail. Paul is an independent Serverless Consultant helping teams get started with serverless on AWS.

The Value Flywheel Effect Book Review

Paul also reviewed our book The Value Flywheel Effect. The team talk about his views of the book. And the fact that it is essential reading to get higher level buy in to serverless in your organisation.

Serverless Mindset versus Serverless First

We talk about the difference between the terms serverless mindset and serverless first. And how it is essential to be pragmatic in your approach and not insisting that serverless is the default for all your architectural decisions. It is better to use serverless as the architecture or service of choice. And then fall back to non serverless or less serverless services for certain parts of the architecture.

Wardley Mapping your Tech Stack

Wardley mapping and mapping your tech stack became really useful. Because you can see the individual components that can be moved to serverless. Instead of insisting the whole thing must move.

The origin of Serverless

Ben Kehoe came up with the term 'the serverless spectrum'. And it captures the notion of falling back. You can see if you have fallen back to things on one side of the spectrum.

Leading with Context

There's a fundamental thing with developers. Generally, they identify with the technologies they've use frequently. And they get really attached. And fanboy/girlism kicks in as well. There is a natural tendency to do that. Before your rational mind kicks in and says hold on. What is this? And what are the drawbacks of this? Or what sort of context would this not work in?

Context can be vague

I split it up into the application context of the actual system. What are the features or operational, latency and performance concerns you need the system to have. And the actual organisational context. The first application context is usually known. People know that they are building a specific app. It has these features and these requirements.

But the second organisational context is what developers do you have available to you? What skill sets do they have? Are they developers without ops skills so we need to hire infrastructure folks. Or do we have infrastructure folks, and they might not have much to so because we're using serverless? These things need to be considered when you're adopting technologies for a new project.

Serverless Maturity

We have reached maturity in the serverless ecosystem. Developer advocates are starting to codify and articulate their patterns. We have CDK patterns and things that are Google-able. Teams can reach out to see how to do it in an API gateway, lambda or dynamo. And see videos, tutorials or documentation of workshops that are maturing and established.

AWS effectively becomes a platform team, if you follow the serverless first approach. And they're going to keep investing in making it easier and adding more features and capabilities.

How will Serverless evolve?

Tools that optimise for small teams to get stuff done are essential. Like operational stuff or standardised CICD pipelines and testing mechanisms around that. There's a lot of good work being done on the friction that serverless had over traditional app development. Because it's a big overhead f

Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube