Don’t dip your toes in serverless — you have to dive right in
I’ve spent the last two years or so telling the story of serverless, and sharing my experiences. It’s been fascinating to hear all the stories, but there’s something that’s been bugging me through that time.
If we’re getting such a benefit from it, why aren’t more people jumping on board and doing the serverless thing?
I was having a chat with Jeff Hollan today (who is just as smiley as his twitter photo suggests) and just talking all things serverless. His thoughts and questions were intriguing to me though.
We’re both finding that just “trying out” Azure Functions or AWS Lambda hasn’t really led to people getting a major understanding of the value of serverless.
And that’s very interesting to me.
What you learn by trying out
It’s fun to try new things in tech. We’ve all done it, and we like following a quick tutorial that shows you how to use a new or up and coming technology in a fun way.
We’ve done it for years. For example, I remember picking up Ruby on Rails from a web tutorial, and running with it. The same goes for Django, and the getting up and running tutorial.
And Go
And Node.js
And that first tutorial is often your first encounter with a technology.
Serverless has a bunch of “tutorials” that you can play with and get some value out of. But it hasn’t taken off in the same way…
… why?
Well, maybe because the tutorials are speaking to the wrong crowd?
Maybe the image resizing isn’t actually a big problem that needs solving?
We’ve spent years getting Developers to shift technologies. And that shift from one technology to another is relatively simple, because they do roughly the same thing, but with a different syntax.
I’m wondering though whether that process needs to be different for Cloud people (I’m trying to avoid the word DevOps on purpose here).
The majority of tutorials for Serverless appear to cater for the Dev crowd and not the Cloud natives.
Value of serverless occurs over time
The value that I’ve seen in utilising serverless technologies (primarily AWS Lambda in my context) has been seen over time.
The reason I was immediately attracted to Lambda in 2014 when it was announced, was because I could immediately see how it fitted into my current way of thinking.
I had spent several years working on developing mobile apps for startups. Mobile apps are different by design to web and the approach I took was simple:
Build an API
Build an internal client SDK (a way of connecting to the API)
Build the client around the SDK
Build an autoscaling backend behind the API
Simple right?
So when I saw Lambda, my first thought was that it simply replaces the backend behind the API.
And when AWS built API Gateway, it became even simpler.
The point is, that I was already there. I was cloud native already (using Elastic Beanstalk or Heroku or autoscaling AWS solutions) so that was a given for me.
So going serverless wasn’t a big leap for me, and I had a lot of confidence in the solution and how I might engineer solutions utilising it.
And over time, using serverless principles, the value has become clearer for me.
Because as we scaled the solution, we’ve been forced to interact with a serverless solution, and grow our skillsets, and build our understanding.
Which means that as a team, we now have become one of the most experienced serverless teams around.
But the thing we did (that others have not) is jumped in with both feet. We’ve taken it on, with an expectation that we’ll have to learn quickly.
Where companies have not jumped into serverless, but relegated it to the world of company hackdays and minor pieces in the puzzle are missing out. If you don’t have to grow your thinking to use serverless, then you’ll never really find the value for your team. Maybe that’s a leadership problem as much as anything else.
Serverless needs to be for both DevOps and Dev
Because the crowd that needs to see serverless as the future is the DevOps crowd.
And we’ve separated them from Development so successfully over the past few years that the “web tutorial approach” is not the only approach we should be looking at.
If you think about it, serverless principles impact on multiple areas in a company. It’s not just the web developers, but it’s also the DevOps person and the Testing person and the CTO (who will carry the can if it turns out to be a bad idea). It affects all levels of technology, and that’s maybe it’s problem.
Being a CTO on a greenfield project, with a background in Cloud, I saw serverless as a “no brainer”.
I still do.
And maybe the only way to bring in serverless to an existing environment is to move a core part of your business into a serverless way of doing things.
Maybe onboarding employees (Jeff Hollan thought of this one)
or maybe the creation of an account on a website
or something that has a heavy workload that is triggered by a single event that can be captured
because that’s the way you will find the value for your business.
It’s a leap, but it’s not that big of a leap.
I would argue without diving right into serverless, that you never really see the value.
It’s a long term play.
I’ve said many times, it’s a TCO thing. They often take a while to provide value (it’s not immediate).
It’s like switching from data centres to cloud… always take the low hanging fruit as your first foray into it.
That’s how you learn the value of Serverless.
Dive right in.
So just go for it, or you’ll find yourself a long way behind the curve when everyone starts to go Serverless.
I know where I’d rather be.
PS talk to Jeff Hollan and follow him on twitter
