Back in November 2018, we were launch partners with AWS for the AWS Lambda Layers feature. We immediately launched layers for our supported runtimes that provided whole-event observability and instrumentation with IOpipe without code modifications.

We found that layers alone did not sufficiently solve the story for our users.

Why we don’t sample or aggregate our metrics

There are sometimes ways that things have always been, or ways that have become standardized that we become accustomed to. Choosing to sample and aggregate metrics has become the de facto standard in traditional monitoring tools. Even as other observability tools move away from write-level aggregations, they continue to operate on samples.

At IOpipe, we have chosen to implement Whole Event Observability that is complete, unsampled, and non-aggregated.

Along with real-time metrics and mobile-first design, we believe this is a core tenet of serverless observability and should be part of any monitoring and debugging solutions for serverless.

The legacy of sampling

Typically, sampling refers…

We’re excited to be a launch partner for the AWS Lambda Layers! This exciting new feature allows developers to mix and match source code and other application resources into a single AWS Lambda function deployment.

Lambda layers allows developers and operators to add and enable the IOpipe libraries to your Lambda functions without directly modifying your application source code, or even redeploying your code!

Updating the IOpipe libraries becomes as simple as an API call, or updating your Cloudformation stack. It also makes it painless to audit which functions are running IOpipe and utilizing the latest version of our libraries.

Using AWS Layers

…

At IOpipe, we monitor user’s Lambda functions, receiving runtime data for each of a user’s function invocations. This means ingesting a lot of data, sometimes billions of records per day, which we do in realtime using Kinesis and Lambda.

Introducing Kinesis Streams

We picked Kinesis Streams to process this data as a hosted version of a service similar to Kafka, but different in important ways. For one, it’s managed, but also, it scales readily and the workers that consume it automatically scale, when combined with Lambda.

Kinesis accepts data via a “PutRecord” API call. It then invokes a Lambda function we have registered…

The recently announced SAM Local tool offers a great option for developers to test their code with an accurate local representation of the AWS Lambda environment without a lengthly dev, deploy, test cycle.

However, the Serverless Framework (sls) is hugely popular for simplifying the process of developing and defining the infrastructure requirements of AWS Lambda applications. Wouldn’t it be great if developers could leverage the power of both of these tools?

In fact, these tools are better together! Lets walk-through using them together to build and test a serverless application!

Preparing your Serverless project

Create a project! You probably have a project already, and…

This article was originally written in the beginning of 2014, originating as a Keynote I gave at USENIX. I made some small edits toward the end of that year. It was never finished and there remain placeholders for graphics. Trends highlighted here have happened in some ways, such as the invention and increased popularity of GraphQL. Serverless technology is changing how we manage and use immutable infrastructure. Many lessons are yet to be learned, and I may yet publish a revised article! — Erica Windisch (July 2017)

Hello.

Today I come to you to speak of a future. A future…

Public and cross-account functions on Serverless platforms such as AWS Lambda offer compelling use-cases to build non-HTTP, non-RESTful web services that skip API Gateway and can be connected directly to event triggers on other user’s accounts.

For instance, a function processing S3 uploads with AWS Rekognition could be connected to a number of S3 buckets across several accounts, with all image processing charges aggregated and billed under one account.

At IOpipe we support creating alarms that execute Lambda functions. We also support webhooks, but to connect those with Lambda would demand using API Gateway, which demands configuration, adds latency, and…

A couple weeks before writing this post, AWS had a single-region failure of S3. It was the worst failure of S3 ever, and it took down many services. We at IOpipe survived fairly well, with our dashboard offline, but our APIs and metrics ingestion were unaffected.

Still, we’d like to avoid these problems from happening in the future, and it turned out that resolving this was really, really easy. Yet, I didn’t find much documentation, tutorials, or how-tos on configuring S3 multi-region failover.

This tutorial will show you how to configure a URL which provides multi-region failover for S3 buckets…