WoodITWork.com

There’s always been a lot of talk about defining “Serverless”. That’s what you get for coming up with a term that describes what something isn’t rather than what something is.

There isn’t actually an authoritative definition of what “serverless” is, as it depends on what message your trying to convey, and that’s actually OK, we’ve somehow managed to eventually understand what “cloud” generally means.

Jeremy Daly recently did a presentation at ServerlessDays Milan, Stop calling everything serverless!,

Stop calling everything serverless! from Jeremy Daly

Jeremy listed some of the terms the collective wisdom of the community has come up with, great presentation, worth watching.

• Serverless as a Compute Model
• Serverless as an Architectural Pattern
• Serverless as an Operational Construct
• Serverless as a Spectrum
• Serverless as a Mindset

I’ll let you go through the presentation to see what Jeremy comes up with as his own definition.

Paul Johnston adds to the mix with the great Serverless is a Doctrine, not a Technology

View at Medium.com

Serverless Evolution

The initial hype and excitement of the term serverless started with its new compute thing, Functions as a Service, serverless became synonymous with function code. Thinking of AWS products, you throw some code into a Lambda function and you were now “serverless”. Time has marched on and “serverless” as a term has evolved from being just about a compute code execution environment into storage/databases/etc. Something where you don’t manage an OS or deal with a cluster is the first smell test.

Minimilism Mindset

I’ve been thinking we also need to add to the definitions an explicit design goal for a serverless system as being as minimal as possible. Serverless should have a “Minimilism Mindset”.

If we start with a premise that every line of code written is a liability that needs to be maintained, then limiting the number of lines of code written should be a goal.

Someone wise, probably Justin Warren said “80% of writing software is creating bugs. The other 80% is taking them out again.”

All the Code

Code is not just Lambda code but includes infrastructure as code or more accurately with serverless, described as deployment code. For a full “serverless” application you can have a vast amount of CloudFormation code to get it all up and running. This is the glue that binds the different services together. Minimising this code (as well as Lambda code) should also be a design goal.

This is why AWS Serverless Application Manager (SAM) and the Serverless Framework are so important. These take simpler build instructions and split out longer form CloudFormation which you don’t normally need to have any visibility of. You get to manage as little SAM/Serverless Framework code as possible even though under the hood it expands into more CloudFormation.

Codeless Serverless

Avoiding writing code should be a goal of any system. Being able to tie together various existing services to form an application is one of the powers of serverless. Something uploaded to your website/API lands in some storage, gets parsed, streamed, sent via a queue, processed as perhaps an image/text/query, something worked out from it and results in another database and something back to requester. This is a pipeline and there may not need to be any Lambda involved.

Friends don’t let friends write your own code to do something when there is a service that can do it for you.

Patterns are also developing to handle these kinds of pipelines and its evolving. Today, you need to manage this flow through perhaps a database + API + stream and/or a queue with retries, failure detection and somewhere to place errors like a Dead Letter Queue. Lambda functions everywhere to handle the transitions. I can see this being further abstracted where you can build a flow by using an existing service as a well architected pattern that has for example, simply uploads as an input, a processing stage to work stuff out and a destination.

All the queues/streams/callbacks/DLQs/etc. are abstracted away from you into a single component. Again, further minimising any deployment code you need to write. This is where “serverless” evolves to become even more minimal.

Have a look at what Nike is doing with Moving Faster With AWS by Creating an Event Stream Database, a distributed system, transforming data, very scalable, serverless and look, no Lambda.

There will be many more patterns defined as we evolve serverless. These will solve more and more issues, be consumed as a service, be searchable and shareable from something like the Serverless Application Repository.

I suggest a Minimilism Mindset should be part of what you’re thinking about as you embark on your serverless journey.