The (Fixable) Problem with Serverless
Organizations I’ve spoken to have expressed an average of 10x cost savings over microservices-based infrastructure for the code they’ve moved to AWS Lambda. While being billed-per-invocation of a function changes how one views their stack and perspective of their architecture, the reality is that offloading one’s event-loop eliminates infrastructure and reduces costs. For instance, running a process that polls a queue requires more resources than having the queue trigger an event that directly invokes your code.
Yet, despite the advantages, developers are still figuring out the most basic operational challenges, despite the popularity of the NoOps moniker. They cannot trace or debug their applications easily, if at all. There are yet no clear monitoring or support strategies. There are also concerns floated around lock-in. Although this, I think, while not necessarily wrong, is overstated.
The principal lock-in issues for “serverless” are differences in underlying infrastructure (VPCs, security groups, etc) and the reliance on other IaaS/SaaS products. Yet, these concerns are nothing new, they apply to VM and microservices architectures, too. There’s also the issue of differing expectations of the functions on a FaaS (Function as a Service), in how the code is packaged, positional arguments, etc.
We need tooling and platforms that enable operations, eliminate or prevent lock-in, and offer users choice.
IOpipe is an open-source solution to these problems.
We’re building a community to provide a common development model to build, ship, and run code anywhere. Compared to Docker, which runs operating systems and their applications as a bundle on homogeneous systems, IOpipe uses code as its unit of compute and truly deploys anywhere code can run, including onto — but not limited to — Docker clusters.
It’s not just deployment, but provides facilities for sharing code and extracting telemetry from your running apps. We believe that operations should be coupled with development, that developer tools should also be operational tools. For this reason, we’re keen to ensure that telemetry — metrics, logging, analytics, distributed tracing — is built-in from the beginning.
Our goal is to make it easier to share and run functions anywhere. This includes working with other tools in the ecosystem such as the Serverless Framework (JAWS). The Serverless Framework is focused on bundling and grouping functions, to construct applications, which is great — meanwhile, IOpipe offers the experience of building, running, and managing those functions — anywhere.
Run Anywhere
There are at least two clearly emerging models for FaaS computing. One is the consumption of a cloud product like AWS Lambda, and the other is FaaS-on-CaaS (Containers as a Service) which may be on your own infrastructure such as a private Docker Swarm, or on fully hosted CaaS products. The applications are largely the same, although there are trade-offs on latency and operational concerns. IOpipe abstracts the differences in underlying infrastructure, delivering your code to AWS Lambda, Google Cloud Functions, Azure Functions, and Docker, without rewriting your application.
We support deploying to AWS Lambda, but using our Dockaless project, we’re also integrating deploy-to-Docker to support scalable serverless applications on Swarm clusters, Rackspace Carina, and Joyent Cloud. Docker themselves made a call to action for these tools and we’re happy to see our work demonstrated and well-received at DockerCon with quotes such as, “This is where the serverless world is headed!“.
Finally, because IOpipe code is lightweight and runs anywhere, it can run without a traditional operating system. Not only are unikernels a perfect target and means of rapid deployment anywhere, but we can also plan to support deployment to embedded and IoT platforms where Linux containers do not fit.
Call to Action
We’re building open source with an open community. We cannot do this without awesome contributors like you! Join us on GitHub, check out our code, and submit pull requests! Our CLI and base runtime are in Go, with an in-app runtime & SDK for NodeJS, as well as a module for serverless telemetry (metrics, distributed tracing).
Finally, join us on Gitter (or IRC bridge) where we will discuss development objectives and help anyone seeking to join our contributor community.
Next: Building Applications
We’ll be writing a follow-up post to explain how IOpipe will help users develop and build their serverless applications. We have some exciting ideas on how we’ll make it easier for developers to adopt serverless, both for legacy and greenfield applications. Follow our blog and we’ll tell you more!
Reposted from the IOpipe Blog: The (Fixable) Problem with Serverless (comment on HackerNews)
