Look Ma! No servers...

Now how are we going to feed ourselves son?!

Shiva Narayanaswamy / @shivamaan / Envato
Learner of systems, practicer of practices and thinker of things

Smells like Serverless

You don’t make infrastructure choices
How big... What instance type... Which subnet...
You don’t make capacity choices
Do I need autoscaling... How many instances do I need...
You don’t make software choices
Which OS... What patch level...
You don’t pay for idle capacity

Shades of serverless

Compute
(AWS Lambda, Azure Functions, Google Cloud Functions, Stdlib...)
Database
(DynamoDB, Firebase, FaunaDB...)
Containers
(Fargate, GKE, Azure Container Service...)
PaaS
(Heroku, OpenShift, Cloud Foundry...)
Others
(Algorithmia, Auth0, Stripe, Cloudflare workers, Auth0 webtasks...)

Serverless function Execution Models

The first two patterns for me to use serverless compute are the asynchronous patterns triggered by event like coming from a notification service like SNS, or S3 event notifications, and the ones triggered by streams like Kinesis or DynamoDB streams, or even the IoT service. Asynchronous workflows triggered by events and streams are no brainers for me and have well defined serverless architectural patterns. The 3rd one, which I think is where there is a lot of discussions, and typically is what most people try to use serverless for the first time, is the synchronous invocations. Write a Lambda function, put API Gateway in front of you, and it is so easy to create rich APIs without running an servers yourself. But IMHO this is also where most of the troubles are. I am not saying this is not a good pattern, just that you will need to think about the attributes you are optimizing for and whether the idiosynchrasies of this pattern meet your needs.

Asynchronous workflows

EVENTS AND STREAMS

Rube Goldberg architecture

Coordination

Just because you can doesn't mean you should

Yes you can, but should you? Yes you can quite easly put a Lambda function behind API gateway and get a serverless API going in no time. But typically you will have some sort of authentication (custom authorizer?), some logic in your function, which might make one or more API calls to other services or systems or some data source, and return back. Depending on scale you will have to deal with cold start taxes at some point in time. If you have a user waiting on the other end, you want to make sure it doesnt affect their experience. If you have your Lambda function reaching into your VPC like in this slide, you have to deal with worse cold start times to attach ENIs. Then you go about hacking your way to keep your functions warm. In those cases consider well architected containers or EC2, because they will have less moving parts.

Make it Async

NoCode Nirvana?

Noops Nirvana?

about

Deployments

Tool Sprawl

[Credit] https://www.flickr.com/photos/adam_jones/11215737103 [/Credit] There are many many tools out there to package, ship and safely deploy functions. Serverless framework, Serverless Application Model, Apex, Claudia and others, and a few home grown ones too. Each of them have their pros and cons, and none of them are perfect. Many of them on the backend depend on Cloudformation, and I dont think that is the right choice to deploy functions. Cloudformation is an infrastructure context, and at the moment uses infrastructure paradigms to deal with Lambdas. Typically I see the developer type tend to prefer the serverless framework, and the infrastructur-ey type prefer Apex or SAM. Each of these tools have their own opinionated defaults, and know what they are and see if they match your sensible defaults. SAM has come leaps and bounds in the recent past. sam-local allows to local testing without having to mock all your API calls.

Function Sprawl

Pipelines

[Credit] https://commons.wikimedia.org/wiki/File:Steam_Pipelines_Near_Taupo.jpg [/Credit] if you have a synchronous API, you could potentially orchestrate a portion of your traffic to go to a new version...think canary deployments...run some tests or watch some metrics and slowly cut over. Or you might choose to swap function versions using aliases and do a blue-green style. When you have asynchronous architectures and functions triggered by events you dont have too much leeway around how many times the events are retried. There is no way to persist the events until you flip over functions in your deploys. Depending on your volume you stand the risk of losing some events, and will need to put in place out of band mechanisms to retry. It is a slightly better story with Streams, because you have some persistamce in the stream. However whether you are able to do a Canary deploy or do you need to do a blue-green flip is based on your implementation. Irrespective of how you deploy, my recommendation has always been to orchestrate it via a pipeline. Watch metrics and manage rollbacks. Have out of band mechanisms to catch failures.

Shared code, infrastructure

[Credit] https://commons.wikimedia.org/wiki/File:Life_is_Sharing_(8188824613).jpg [/Credit] Another interesting problem to tackle is how do you split up you functions? If you are providing a CRUD API, do you write a CRUD function, or do you write seperate functions for Create, Read, Update, Delete etc? Presumably each of those have different scaling requirements. So if you have seperate functions, you are probably going to have to duplicate code. In those cases you have a a couple of choices to make. Duplicating code is generally a bad idea. You write shared private libraries like npm modules that are imported by different functions. Or you could encapsulate it into a shared service that you run and used by other services. You might not be able to run everything as a shared service. Both methods have their pros and cons. If you are using shared libraries, any updates you release have to be used by client and they have to be backward compatible, or you will end up maintaining multiple versions of the library. Similar problems exist with providing shared components as a service, but easier to maintain versions of API and deprecate them. You have more control. But with shared service, te client now have to make an extra hop across the network.

about

Security

Vulnerable Libraries

[Credit] http://www.thebluediamondgallery.com/wooden-tile/s/secret.html [/Credit] With Lambda fucntions you can have secrets in Env vars, and they are encrypted by KMS. But it is not ideal. What if you have secrets that need to be shared across multiple functions? Also if you need to rotate your secrets, you need to redeploy your functions. Also access control. Can the person who deploys functions have access to the secrets? Do all secrets required by function have the same level of access control? When you are using Env vars, you cant have fine grained access control. Use SSM parameter store to store your configs and secrets. One considertion if you choose this path is that reaching out to Parameter Store is another API call your function will have to make. If you cannot afford that, then load your configs and secrets in a global context, so that your warm functions wont need to make that API call. But make sure you have a TTL set for expiry of those global variables.