Serverless Use Cases: The REST of the Story - Think FaaS Podcast
Serverless is often used hand in hand with building APIs whether they be RESTful, GraphQl, or what have you. Let's look at other ways to leverage serverless.
Howdy, I’m Jared Short 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.’
Serverless is often used hand in hand with building APIs whether they be RESTful, GraphQl, or what have you. While this is a typical use case, let’s look at other useful ways we can leverage serverless.
Data processing and ETL
Clearly this is also a very popular usage for serverless and FaaS systems. Being able to scale and run hundreds or thousands of functions in parallel against massive datasets makes a powerful and natural pairing.
There are a couple fantastic patterns and even some ETL frameworks a google search away for working with for instance s3 data sources and crunching the data. One of the popular approaches is “cascading” operations to more and more concurrent functions until you get to chunks of work that are easily completed in the lifetime limits of a lambda function. These then aggregate and bubble back up to a “main” lambda. Adding in Step Functions can give you even more flexibility and control on the ETL process from end to end.
What’s more interesting in this particular space, is that there are many higher level serverless services that take this pattern of rapidly scalable, pay for what you need. Take for example Amazon Athena, AWS Glue, and S3 Select. All of these services exist and operate to give you access patterns to your data in the way you want it, only when you need it. You pay directly tied to how much data you process. No longer do you need a massive ETL clusters running 24/7 to serve some simple reporting needs.
Orchestration and Ops
At Trek10, most of our internal processes and systems integrate with lambda in some way. We have security scanning, zendesk ticket automation, slack alerting, EBS volume cleanups, CloudFormation automations, log processing, search indexing, and all sorts of stuff that runs on lambda functions.
Think about how many crons jobs, jenkins scheduled jobs, or even manual checks you have out there. It can be painful to update those servers or dependencies, or add new ones. Plus, you are paying for those servers to just sit there and do nothing a lot of the time. What happens when two big jobs need to run at once? Well, time for another server! The practical application of lambda as an ops tool is simple, but potent.
One thing to watch out for is that lambda makes it so easy to automate away these things, that you are going to want solid CI/CD and pipeline practices to maintain good account security and hygiene. You may get an explosion of roles, languages, and dependencies that become tricky to cleanup later if you are not careful.
Serverless at the edge
One of the most exciting spaces, and one of my personal areas of interest, is pushing the power of serverless computing out to the edge. What’s the “edge” you may be asking? The edge means pushing your lambda function out to the closest possible point it can be for your systems or users executing it.
This may be on POPs or CDN systems closely located to your users, or even on IoT devices or gateways in physical locations. Instead of needing to traverse a network all the way back to the “home” data centers, events and requests can be served much quicker from those edge locations. The brilliant part of all this, is that in many situations, the development deployment model is similar to what you are already used to.
AWS Greengrass is a superb example of this. Allowing you to manage groups of IoT with relative ease. The magic really happens when you realize you can cut off the network, and your “lambda” functions on the devices at the edge can keep working as expected within the group. Greengrass even has the capability of pushing machine learning models out to the edge for low latency machine learning capabilities!
It doesn’t stop there, soon we’ll see entire applications running at the edge with occasional connections back to regional datastores for synchronization. We already don’t worry about the servers we are running on, soon we may not even need to worry about where they are running, we can just depend on the platforms to provide high performance executions for us!
And that’s all I have time for this week. Do you have any compelling use cases or ways that you are leveraging serverless? Let me know on twitter @shortjared. You can follow Trek10 there @trek10inc. See you on next weeks episode of ‘Think Faas’!
