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 working with and 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.

Keep it simple

It's the worst thing in the world, when a senior engineer builds something really complicated because they are smart. However, the beauty of a good system is simplicity. It is worth going the extra bit to get to simplicity. And don't overcomplicate things just for the sake of it. I don't you know if it's an ego thing, but sometimes people build things are way too complicated.

If you're the architect you need to imagine yourself not being there for two months. How will the team fare? Have I designed a system that's simple enough if they hire a new developer in the meantime. When I'm not there to get them up to speed.

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?

One reason for being attracted to Serverless in the first place, was as a developer you are working close to the product. Full stack developers build a front end and back end. But you can have a team of one back end and one front end developer. And they do everything. So 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. And having to deploy to the cloud locally and making that fast. I think it will continue to get better for individual developers. By creating stuff that would otherwise have complex AWS nuances. Because it's a big overhead for for developers to learn without AWS certifications.

ServerlessFirst.com and @PaulSwail

TheServerlessEdge.com and @ServerlessEdge

The Value Flywheel Effect Book with IT Revolution