Hi, I’m Forrest Brazeal at Trek10, and this is ‘Think FaaS’, where we learn about the world of serverless computing in less time than it takes to run a Lambda function. So put five minutes on the clock - it’s time to ‘Think FaaS’.
I’m seeing a noticeable expansion in the serverless community here in 2018. Serverless technologies are gaining a lot of traction in large enterprises as well as startups, and a whole bunch of folks are being introduced to these ideas and concepts for the first time. As we here at Trek10 work to help educate this expanding community, we hear a lot of the same concerns over and over again. So in this episode, I want to address a few of these common misconceptions and hopefully set the record straight.
1. “Serverless is a buzzword - it’s all hype.”
There’s definitely silly serverless hype, and the serverless movement hasn’t helped itself here by its own choice of name, which is why in 2018 we’re still spending time explaining that yes, there are still servers in a datacenter somewhere, nobody is saying there aren’t. But even beyond that, people need to realize that we are past the point of serverless being a toy, or used for background jobs. If you want to see examples of serious companies running production systems without managing servers, check out my Serverless Superheroes interviews at A Cloud Guru. At Trek10, we build these kinds of systems on a daily basis. It’s not necessarily as easy as the hype might claim, but the advantages are real, and so are the systems.
2. “Serverless is a trap to get you into the cloud provider’s walled garden!”
I did a whole episode of this show on the subject of vendor lock-in, so for now I’ll just say: in my opinion this argument is pure FUD. That’s fear, uncertainty, doubt. Remember, FaaS is usage-priced, so you don’t have contracts. And a well-architected serverless system will be decoupled, so it’s easier to move a piece of it than shifting some huge monolith.
That said, we are starting to see serious efforts made toward cloud agnostic frameworks. CNCF is working on a standardized event spec. The Serverless Framework is betting big on multicloud, which makes sense for them. If you need to lift and shift a function, you’ve got tons of options, especially as the cloud providers scramble to offer competitive features.
3. “Serverless is just a retread of CGI scripts, PaaS, whatever. Nothing to see here.”
I think people use this kind of reductionist language because they don’t want to deal with the reality, which is that modern serverless development as typified by AWS Lambda and friends is not really something we’ve seen before. The concept of functional billing combined with managed execution at massive scale is a game-changer, which is why we see companies saving something like 90% of their compute costs by switching from traditional VMs. If you’re saying AWS Lambda is just like some other technology you’ve used in the past, you’re probably not getting the most out of Lambda.
4. “Serverless doesn’t scale!”
Particularly, folks will say that serverless doesn’t work at “web scale” — hundreds or thousands of requests per minute — and they’ll cite reasons like performance and price.
Now obviously, depending on your application requirements, you may very well reach a scale where it is more cost-effective and performant to run your own servers. But I would seriously question whether most of the people making this argument are really at that point. Keep in mind that you have huge companies like Nordstrom now serving real-time web traffic with serverless. Our friends over at A Cloud Guru have been serving thousands of concurrent users on a fully serverless stack for years. And as the technology and the tooling and the best practices mature, that kind of engineering success is available to more and more people.
5. “Serverless could never work for me.”
Remember, there’s more to serverless than FaaS. Just because your workload isn’t a good fit for functions doesn’t mean there isn’t some other managed service that could help you. The whole point of serverless is to manage fewer things - less code, less infrastructure - saving money on admin overhead as well as infrastructure. If you can’t be fully serverless, fine — at least use servers less. Only incur as much technical debt as you have to.
What makes all these arguments bad is not that they don’t contain a grain of truth — which they all do to one extent or another — but that they are blanket statements. There’s nuance here. And there are certainly good reasons not to implement a serverless architecture. Here’s one:
“Serverless technologies don’t work for my specific application, at this moment in time, because I’ve carefully evaluated the cost/benefit tradeoffs and determined that I’m better off sticking to a more traditional solution.”
That is a totally valid statement to make, as long as you fully understand what you’re gaining, and what you may be leaving on the table. In particular, if you have a critical balance of developers who understand an older technology, and you have a tight timeline to deliver something, this might not be the right time to learn serverless. Because it’s a big paradigm shift, and requires learning a new set of skills. Nobody is denying that. Serverless development will reveal uncomfortable truths about your application’s access patterns, about the utility of your code, about how much time you are spending on work that is not directly aligned with your business value. And the real question should be: are you up for the challenge?
If you are, Trek10 would be glad to help. You can find us on Twitter @Trek10inc, or hit me up @forrestbrazeal, and I’ll see you on the next episode of Think FaaS.
