Serverless is about Automation, not Functionsby@PaulDJohnston
1,575 reads
1,575 reads

Serverless is about Automation, not Functions

by Paul JohnstonOctober 20th, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

I recently spoke at ServerlessConf NYC on Managing <a href="" target="_blank">Serverless</a> Development. The slides are here (enjoy the cat pictures!):

People Mentioned

Mention Thumbnail

Company Mentioned

Mention Thumbnail
featured image - Serverless is about Automation, not Functions
Paul Johnston HackerNoon profile picture

I recently spoke at ServerlessConf NYC on Managing Serverless Development. The slides are here (enjoy the cat pictures!):

Managing Serverless Development October 11th 2017 ServerlessConf NYC_Managing Serverless Development Paul Johnston CTO, Blogger, Opinionated Serverless Person Serverless all the things…

I had many routes down which I could take this talk (I shared my thinking beforehand), and wasn’t really sure of the route until the evening beforehand, after a number of really useful conversations.

The talk in the end went down a relatively simple route of saying that Serverless Development is roughly the same as normal development, with some nuances, and these I outline later on.

But the thing that struck me was how important it is to automate your processes as much as possible.

Automation is the new Function

Originally, the function was the unit of “Serverlessness” in the Serverless community. We were all over it, worrying about cold starts, breaking up our monoliths and microservices into clever functions here and there.

And I figured that the key for all of this was that we weren’t managing servers and that the cloud vendors were doing it all for me.

“No maintenance” was what Serverless was all about.

But then we realised something else…

…there are lots of functions to manage…

…and lots of other elements to manage…

…and lots of infrastructure to worry about.

So it became replacing one set of problems for a different set of problems.

Which is fine, because I prefer the serverless problems.

Examples are easy, real world is harder

What we found is simply that when you have more than a few functions, and a small number of elements and you had to start managing it, that there were issues.

Not insurmountable issues, but issues nonetheless.

And those issues of scale and management were resolved using tools like CloudFormation and Terraform.

The “Infrastructure as Code” and DevOps world began to take greater importance in the Serverless world.

Which meant that us pioneers had to start doing the Infrastructure as Code thing.

Which was great.

Because it meant that we could automate our deployments and manage our large numbers of “resources” that we now had to manage (functions, data, streams).

Automation has become King

Serverless became more about Automation than it did about Functions.

In fact, there are some solutions beginning to be discussed that don’t use just functions for processing, but some vanilla containers for long running tasks.

Functions are still a huge underpinning of Serverless.

But Automation is becoming the Power behind Serverless.

The power to automate deployment

The power to automate scale

The power to automate maintenance

The power to automate repeating tasks

Serverless is all about the automation at all levels.

Emergence of the Serverless Engineer

We have used the word Engineer within technology relatively freely for many years. Most people who do development work call themselves an “Engineer”.

But maybe we have spent a long time ignoring the word. Because maybe we’ve spent too long thinking of it like a “mechanic” than a creative genius role.

Maybe Serverless is an opportunity to show that engineering is at the heart of future technology.

Because Serverless is about Automation.

And Engineering is about using technologies to push us forwards.

Maybe we should allow our developers to become the engineers they have always been.

Maybe the Serverless world will show the wider tech world too that we are more than just developers/mechanics.