The power of Serverless hit home recently when I overheard a conversation between a couple of devs. I fully promote and embrace the Serverless mindset; one where you pay to make the non-value-add elements of building, testing, deploying, and running bespoke Cloud Native applications somebody else’s problem. Realisation dawned as they discussed patching windows, release windows and servers overloaded with multiple unrelated applications. I have truly been spoilt by Serverless.

The first realisation centres on technology choice. When solving your business problem Serverless-ly, you are empowered to select the best fitting technologies. If a particular language will work best, just choose it. Would a particular database work best? Then pick it. If a historical technology choice begins performing undesirably, replace it. Development teams don’t need to coerce technologies to fit solutions, solutions are designed with the most suitable technologies.

My second realisation flows on from the first; where to host and deploy applications. I always start with infrastructure-as-code to deploy applications into dedicated, environment specific, AWS accounts. I have removed any concerns of changes impacting other applications, nor concerns that other applications will impact me. Single tenancy, coupled with full-managed services, removes potential issues with patching, restarts or random outages. Security gets pushed down the stack too to the point where I have a small slice of domain-specific security to worry about. The rest is AWS' problem and I’ve literally ‘paid to make the security pain go away’.

The last realisation is my participation in full build-and-run teams (aka DevSecOps). The team owns the application from idea inception through to build, deploy and run. Everyone contributes to the design and testing of small, continuously deployed changes. I have literally seen production bugs fixed within hours. I have seen customer ideas go from suggestion to being in their hands within a working day. And I have seen outages being proactively identified, and even resolved, before end users are impacted. No need for lengthy architectural review processes, or box-ticking ‘Change Boards’ that delay even the smallest changes by days or weeks.

These realisations also have a dark side; not every developer and organisation gets to experience how much joy Serverless can bring. Too often over my career, I’ve seen ‘smells’ like:

  1. Sticking with obsolete or expired versions of operating systems, runtime containers (think app servers) or vulnerable libraries just because there is no ‘project team’ to upgrade and verify. A related issue is sticking with a technology or language just because it’s the way things have always been done (‘We’re and XYZ shop’).
  2. Servers overloaded with services from multiple teams, just to make sure the business is getting every dollar out of the assets. The increased complexity holds teams back as they become too scared to make changes. Or they firefight issues due to random unrelated changes affecting their code. Or using a single AWS account to host 6 team’s worth of workloads as it was literally impossible to obtain separate accounts.
  3. Having separate project and support teams. Tribal knowledge builds up in the project team’s heads, only for the team to become disbanded when the system gets thrown over the fence to the support team. Writing software is a continual process of decision-making and trade-offs; leaving the support team struggling to understand the ‘whys’ buried in the system they just inherited.

Looking back over 20+ years of developing software and running bespoke applications, Serverless really is a warm blanket. Its warmth allows us to try new ideas, it protects us (like a shield) from all the tasks that do not add value and comforts us as we work at a speed that is unparalleled.

Serverless is a warm blanket, change my mind! 😄