Serverless Functions with Datastax Drivers

Serverless & DataStax
Presented By:
Patrick McFadin & Chris Splinter

Serverless
&
DataStax
1. What is Serverless?
1. Why should I care?
1. Is it everything it says it is?
1. How can I do this with Cassandra & DataStax?
1. Lets see it.

What is Serverless?
Our focus will be on Functions as a Service ( FaaS )
Spoiler
There are still servers that host the containers where the functions run.
Main Differences
- You don’t have to provision your own servers / virtual machines for application instances.
- You are subject to the runtime of the provider’s container and the constraints of the framework.
- You only pay for what you use.

What is Serverless?
High
Optimism
Standard
Stack
Virtualization
&
DevOps
Containers Serverless
How did we get here???

What is Serverless?
Source: UC Berkeley Study
https://arxiv.org/pdf/1902.03383.pdf

What is Serverless?
Cloud Provider
serverless offerings
Cloud Agnostic
serverless tooling

What is Serverless?
Serverless is the native architecture of the cloud that enables you to shift more of
your operational responsibilities to AWS, increasing your agility and innovation.
Serverless allows you to build and run applications and services without thinking
about servers. It eliminates infrastructure management tasks such as server or
cluster provisioning, patching, operating system maintenance, and capacity
provisioning. You can build them for nearly any type of application or backend
service, and everything required to run and scale your application with high
availability is handled for you.
AWS says ...

What is Serverless?
Google says ...

What is Serverless?
Develop more efficiently with Functions, an event-driven serverless compute
platform that can also solve complex orchestration problems. Build and debug
locally without additional setup, deploy and operate at scale in the cloud, and
integrate services using triggers and bindings.
Azure says ...

Why should I care?
Accelerate time to market Only pay for what you use
Scalability & AvailabilitySimplified DevOps
Focus on business value
Looks
promising ...

Why should I care?
Source: 2019 Cloud Foundry Research Report
https://www.cloudfoundry.org/digital-transformation-2019/

Why should I care?
Modernization
Monolith
App
Microservice
Microservice
Microservice
Microservice
Function
Function
Function
Function
Function
Function
Function
Function
Function
Function
Function
Function

Why should I care?
TCO
Charge per GB-Seconds
Run Time * Transfer

Why should I care?
TCO
Charge per GB-Seconds
Run Time * Transfer
+
GHz-Seconds

Is it everything it says it is?

It depends
Yes
No

Let’s talk about “state” aka - data that is fixed at a given point of
time

Let’s talk about “state” … or rather, lack thereof in serverless functions
Typical Serverless Workflow
Process Store
Add to cart
POST
You need a database or storage system to store state

Typical Serverless Workflow
Process Serve
Read cart
GET
You need a database or storage system to serve state

What does this mean?
- Data storage system must be fast
- Data storage system must scale with your functions
- There is an extra hop required to access stateful data
- Serverless functions should share nothing

Let’s talk about cost
How many executions of the function per month?
How much RAM is needed per function?
How long is the function expected to take?

- If all goes well, let’s say 1 billion
- Mmmm 1 GB
- You tell me?

- If all goes well, let’s say 1 billion
- Mmmm 1 GB
- You tell me?
https://dashbird.io/lambda-cost-calculator/

Let’s talk about cost It’s always good to get a 2nd opinion
http://serverlesscalc.com/

So ~$3500 for 1 billion requests with 1 GB of RAM and a duration of 200ms, cool
Is that more expensive than a single reserved instance with the same capacity?
Yes, BUT with serverless
- You get guaranteed high availability ( don’t have to mess with load balancers )
- You get guaranteed scalability ( don’t have to provision more stuff )
- You get the built-in security of AWS IAM and VPC ( don’t have to point fingers )

Cold Starts When a function is invoked for the first time or after a period of inactivity …
1. code and dependencies are downloaded
2. new container is spun up
3. runtime is bootstrapped
This takes time.

Cold Starts When a function is invoked for the first time or after a period of inactivity …
1. code and dependencies are downloaded
2. new container is spun up
3. runtime is bootstrapped
This takes time.
1. Periodically ping your functions
2. Reduce size of deployment package
3. Reuse connections to external systems
Mitigation Strategies

Vendor Lock-in
You will be subject to the API of the serverless offering of choice.
Invocation semantics and packaging differ across the cloud providers.
Integrating with other cloud services will increase “lock-in” surface area.
There are technologies that facilitate cross-cloud serverless actions ( serverless.com / OpenWhisk / fn ).

Testing & Debugging
Difficult to test serverless functions locally.
Debugging will require integrations with cloud providers logging systems ( ie. CloudWatch, StackDriver ).
Follow best practices for unit and integration testing.
- Exclude test dependencies from the lambda package.
- Separate business logic from the function entry point ( also improves portability ).

Limits

Limits
https://docs.aws.amazon.com/lambda/latest/dg/limits.html
https://cloud.google.com/functions/quotas
https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale

How can I do this with
Cassandra & DataStax?

The same DataStax C* drivers can be used in all serverless frameworks
Serverless w/Cassandra & DataStax
const cassandra = require('cassandra-driver');
const client = new cassandra.Client({contactPoints, localDataCenter});
client.connect()
.then(() => console.log('Connected to the cluster, discovered %d nodes', client.hosts.length))
.catch(err => console.error('There was an error trying to connect', err));
Node.js example

There are some serverless-specific best practices for the drivers
1. Create the driver connection to the database outside of the function entrypoint
1. Be aware of the number of client connections to your database
1. Consider the query characteristics compared to the function runtime
1. Optionally reduce startup time by disabling driver metadata & pooling warmup
1. Disable the driver heartbeats that ping idle connections
1. Move the data access and business logic away from the function entrypoint

Take the time to think about decoupling
1. We have seen cluster, data center, and keyspace per microservice
1. Functions are even more granular, table per function or a few tables per function
const readQuery = `SELECT name, description, price FROM ${keyspace}.${table} WHERE item_id =
?`;
async function getItem(item_id) {
const params = [ item_id ];
const result = await client.execute(readQuery, params, { prepare : true });
return result;
}
CREATE TABLE ${keyspace}.${table} (
item_id int,
name text,
description text,
price decimal,
PRIMARY KEY (item_id));

Idempotent: If I do this twice, will the result be different than if I only did it once?
Read this: https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-idempotent/
and this: https://docs.aws.amazon.com/lambda/latest/dg/retries-on-errors.html
- Basically your Lambda functions might be executed more than once if there is a failure.
- Lambda retries function errors twice.
“If at first you don’t succeed ...
( maybe ) try, try again
await client.execute(writeQuery, params, { prepare: true, isIdempotent: true
});

Multi-Cloud:
Cassandra and DataStax
run in any cloud,
giving developers the
freedom to choose the cloud
that fits their serverless needs.

Demo
Check it out! https://github.com/csplinter/datastax-serverless-examples

Serverless Functions with Datastax Drivers

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de DataStax

Mais de DataStax (20)

Último

Último (20)

Serverless Functions with Datastax Drivers

Notas do Editor