By IOpipe Co-founders Erica Windisch and Adam Johnson
We started IOpipe in 2016 with some burning ideas on how to make it easier for developers to build and run serverless applications.
What we quickly recognized was that debugging and monitoring challenges had become a major barrier to serverless adoption. Debugging issues across millions of invocations throughout many functions, and living ephemerally, without a concept of a traditional process and host management quickly highlighted a gap in tooling for serverless. …
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.
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.
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.
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.
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.
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!
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)
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…
Okay, it’s been a year since I promised a follow-up to Part 1 where I introduced the Chromebook and some of the security advantages it offers.
With the current political climate, border agents unlocking devices of many if not all international travelers, further awareness of domestic spying, and more obvious foreign influence and spy access, users are increasingly looking for secure computing options.
With computer hardware, it’s often said that once you have physical access, it’s game-over. When the government asks that you physically hand them a device, what are you supposed to do? Well, lets explore!
In this second…