At Stackery, our engineers live and breathe serverless development every day. Because of this, we are constantly evaluating the current soundbites about it; when a field is expanding this quickly, it's not uncommon to hear a generous handful of misguided assumptions. So, despite the increasing influence of cloudside development, there are still a number of declarations published every week that seem to amplify some common and outdated misconceptions.
It's important for us to say that these misconceptions are understandable and blameless. We don't sit around theorizing that there's a creepy Serverless Myth Machine spreading propaganda— although then our daily work would consist of plotting a supervillain overthrow, which would be epic. Instead, we recognize that the serverless community is still relatively "new" (stay tuned, because we're about to challenge ourselves there). As such, it's growing constantly, which can be difficult to keep pace with if you're not using it daily. Essentially, myths are a predictable symptom of a new chapter in any field. But we're here to challenge them... For the safety of the galaxy. (Sorry.)
Serverless isn't unprecedented. In fact, the road to serverless has been paved and ready to ride for decades, so it makes sense that we've landed here. We've been talking about the concepts of agile software development, microservices, and cloud infrastructure for years, and well before that, key concepts like virtualization set the stage.
Get a bird's eye view of these milestones and the overall journey to serverless in our infographic that our whole team contributed to and discover precisely how we've all been working towards the current era for, well, eras.
In AWS world, when we talk about functions, we're talking about Lambdas. As outlined beautifully by Nica Fee in this recent Stackery blog, Lambdas are the dominant form of serverless functions and are essentially lines of code that AWS will run for you in a virtualized environment, sans configuration. So isn't this essentially serverless? Nope. Serverless takes it a step further. A serverless app is actually made up of a function (Lambda), the resource architecture that lets it behave like a production-grade app, and the secrets to authenticate the database. By resource architecture, we're referring to cloud services like databases, API gateways, authentication services, IOT, Machine Learning, and container tasks. Without all of these three components, a Lambda/function alone wouldn't be able to communicate with the world outside of AWS and what kind of serverless app would that be?! Trick question... it wouldn't be one at all.
It's really always been true that our web applications are more than just the application code: your web app couldn't run without a configured server, a populated database, and maybe a caching service. In the world of serverless function code, that requirement is more explicit: your functions are just tiny pieces of logic inside a larger system. There are even viable serverless applications that don't use functions at all for routing or handling! Therefore, it's possible that the future of serverless won't include functions at all.
And if you'd like to see how users are really building applications beyond simply using Lambdas, be sure to take a look at Chris Munn's Serverless is Dead presentation (...around slide 52 for this specific topic).
Hungry for even more info on why we need to consider a serverless app holistically? Catch this recent article for The New Stack, again by Stackery's Community Developer, Nica Fee:
This concern is prudent- You should always heavily consider security when adopting any new toolset- but it's also something of a logical fallacy. In fact, serverless isn't more secure than traditional computing but it certainly isn't less secure. It's a different model entirely. But that probably isn't enough to assuage your concerns. Some teams hear the words "serverless" and immediately get sweaty, thinking of an enormous total attack surface due to the fact that REST API functions still run on a server and utilize layers on layers of code to parse API requests. These teams think that, since serverless functions (Lambdas) are able to accept events from dozens of different sources within AWS, this means they would be "extra vulnerable" using serverless. Right? Not so much.
Instead, you should rely on trusted outside tools, like Twistlock. Used in tandem with Stackery, Twistlock allows developers to increase velocity, observability, policy enforcement, secrets management, and more. As serverless has expanded rapidly, it's smart to keep application security at the forefront of your team's minds. But know that your options for serverless innovation- and security- have evolved at a similar rate. Think of serverless as a new landscape. Would you arrive, hunting for the same scary intersection as you had in your hometown (i.e. worrying about needing to patch servers)? No. Instead, arrive in this new landscape equipped with car insurance for a different intersection as you admire the scenery.
For more on how Stackery and Twistlock keeps serverless security in check, take a look at this brief: https://www.stackery.io/pdf/twistlock-stackery_SB.pdf
As soon as serverless boarded the Hype-Cycle Express™, one area of perennial debate has been the cost of cloudside development. The good? We get to tell idle server-payments to scram so you'll no longer have to funnel money into a framework when nobody is requesting data from the server. For software teams eager to explore their serverless options, it's tempting to use this as a selling point for the powers that be. But this is a misguided approach because it's not the full picture and nobody wants surprise fees. Serverless might not equal running your own servers but it sure does equal managing and using services as you see fit. For instance, if you are storing data on AWS EC2, transfer rates apply when your app initiates external transfers. There are a number of services involved when you decide to go serverless and it's crucial to be transparent and frank about this when you're evaluating your serverless options.
So no, serverless isn't some kind of development loophole that inherently saves money, but it does equip you with the power to choose what you pay for.
Take a look at this cool serverless cost calculator from Peter Sbarski and the A Cloud Guru team to get a look under the hood of what your serverless strategy is costing you.
On the flip side, many teams looking into adopting serverless get very caught up in the fear of paying for a million services (micro sometimes doesn't feel so micro) and don't focus enough on the positive impact not paying for idle servers will have on their bottom line. For one thing, as your business grows you won't be paying for new equipment because a new serverless app can handle the same amount of traffic as it would in a parallel universe full of tricked out servers. Also expensive? Not getting your apps to market on schedule. With serverless, the cost of a server maintenance team is similarly eliminated and the rule is: get your app to market, and then optimize it. Both of these save a significant amount. James Beswick contributed a lot of valuable information on this overall topic in one of the recent Stackery Wednesday livestreams. Replay it on-demand.
Regarding the myriad of (potentially expensive) services you can take advantage of in serverless development, there is a solution: CloudWatch. This AWS service gathers data in the form of logs, metrics, and events, allowing for a comprehensive view under the hood of your AWS resources, applications, and services. Stackery's integration with CloudWatch allows for all changes to be saved as Git commits so you'll get a panoramic view into every application's history and underlying infrastructure. And yes, you'll only pay for what you use with CloudWatch as well.
The takeaway should be that with serverless, you get fine-grained control over what you spend, only paying for services when you actually need them.
As for the cost of Stackery, we've recently introduced a free tier for developers and hobbyists that removes the barrier to entry. Get more info on that plan here.
What myths have you heard about serverless? What challenges surrounding cloudside development or Stackery have got you stumped? We clearly like to stay on top of such things so let us know on Twitter by linking to this article.
Click here to share it with your Twitter cohorts.