So you know what serverless means but still see it as just a bandwagon? Maybe you consider yourself not a serverless developer? The most beautiful thing about serverless is that you are using serverless services without ever realizing it! That’s right—if you have ever launched an EC2 instance from an AMI, it came from S3, a serverless object store. Since the whole concept lends itself to fading into the background, it’s easy to take the benefits of serverless for granted. So let’s bring them to the forefront! There are endless reasons why serverless is worth your attention and investment, but we’ll start with 5.
So… why serverless?
1. Serverless delivers the fastest time to market
Ever had configurations hit you like a pillowcase filled with door knobs? Knobs are fun—but they carry a dangerous level of optionality, spelled l-i-a-b-i-l-i-t-y, with them. Take DynamoDB, for instance. You just createTable() and go! Who cares what instance type, CPU architecture, RAM, SSD capacity, etc. is? You just want the table to be ready when you need it, at the scale you need it. In contrast, you get a ton of knobs with rolling your own database on EC2 or with RDS. Getting them right takes research. Getting them wrong can cost you your business.
By eradicating the countless knobs, serverless lets you focus on what matters: your customers. And then, because serverless services get you up and running so quickly and eliminate distractions, you can iterate rapidly to meet customer demands! If you host a static site on S3, you never have to worry about it not scaling sufficiently to handle load. You aren’t sitting there configuring versions of WordPress, patching Linux kernels, or worrying about whether to use an ELB, ALB, or an NLB for your load balancing.
2. Serverless services have higher availability
What’s the maintenance window on your Lambda functions? When was the last time you got an “Instance Retirement” notice from Lambda? This is a huge reason why serverless services create so much delight—they work 24/7. They do not carry the obsolete “planned downtime” that their counterparts in the serverfull world do.
ElastiCache has a 60-minute maintenance window each week! That’s another way of saying “planned downtime”. If you are running Memcached, your nodes come back empty. If you are running Redis and don’t have sufficient memory on the primary or are experiencing high write traffic, you may be simply out of luck. According to the Amazon ElastiCache Managed Maintenance and Service Updates Help Page:
It is also possible that replica may never sync if the incoming write traffic continues to remains [sic] high.
Additionally, the provisioned capacity in ElastiCache is a liability. You have no choice but to overprovision because if there is one thing that ElastiCache isn’t (other than serverless), it’s elastic. It takes tens of minutes to scale your cluster, so you may miss your peak. Meanwhile, since you own the node types, number of nodes, etc., you just may not know what limits you will run into if you scale under duress. That raw pain in the midst of an outage is when the pillowcase of door knobs really hits you.
3. Serverless is more secure
Serverless services tend to be secure by default. Serverfull instances give you lots of knobs to tune your security. Did we mention knobs are dangerous? Let’s pick on ElastiCache again for a minute. The default configuration on ElastiCache Redis gives you a node/cluster that does not have end-to-end encryption enabled. This is something serverless customers take for granted! Worse yet, let’s suppose you figure out the lack of end-to-end encryption after getting to production. You cannot just flip a switch and have your ElastiCache Redis cluster support transport layer security (TLS). You can enable the TLS port on your existing cluster, but you’ll have to very carefully drain clients from the unencrypted port to the TLS port. TLS is one of those knobs that should always just be set to “YES PLEASE”. Serverless takes this off your plate—that’s why Momento services have end-to-end encryption out of the box.
Instances need to be patched—and patching them is your responsibility. Some serverfull services will do this for you during the aforementioned “maintenance windows”, which are not seamless. For most vulnerabilities, serverless services handle patching themselves and do so in ways that have no effect on your use of them.
4. Serverless is cheaper
Serverless thrives with simple pay-per-use pricing, which scales to zero. Armed with focus, iteration velocity, and high availability, you may be surprised at which parts of your stack require the most scale. This is another reason why serverless is wonderful: you never end up paying for the services that don’t see much traffic. A common myth is that serverless becomes expensive at scale. This could absolutely be true if you are running your serverfull services at 100% utilization all the time, but we assure you that you are not. In fact, most ElastiCache customers we run into are sitting at below 5% average utilization of their clusters. The utilization problem becomes even harder at scale. If you hit that sudden growth phase, you are going to be even more risk averse and want to provision more capacity than needed to avoid disappointing customers.
5. Serverless service != for serverless only
The serverless club is not exclusive! You can use serverless services with your existing all-serverless stack or with a completely serverfull stack. It is totally fine to use DynamoDB and S3 from EC2 or Lambda. Momento offers a serverless caching service, but many of our customers use it from Fargate, ECS, pure EC2, and yes—even Lambda functions.
That’s “why serverless?” answered. Now ask “where?”
We are serverless mega-fans, but you don’t have to be one to make it work for your use case. You can reap the benefits of serverless incrementally—one service at a time. It’s easy to get started! Here are some ideas for you to take a serverless service for a test drive:
- Fire up a Lambda function, hook it up to API Gateway—and bam! You have a web service that costs almost nothing when idle and can scale when you need it. You can build simple microservices like this really quickly. We routinely find ourselves building Slack plugins for internal convenience features, deploying on Lambda, and just letting them run.
- RDS slowing you down? Add a simple query cache with a single API call to Momento Cache. Or you can use it to replace DAX to make DynamoDB even faster and even more robust.
- Got a static website to host? Put it up on S3. No more web servers, instances, etc. required. It just works.
We’re helping customers make the transition to serverless and found caching temporary data can be a great place to start. We’d love to be your tour guide as you explore all the reasons why serverless might be right for you.