Guy Podjarny published a great blog post discussing the Serverless space from a security perspective. I highly recommend reading it as it touches on some great points, going over both the security benefits and possible risks.
Two points he made definitely stood out to me, and the first was the concept of a greater attack surface. When I explain FaaS (Functions as a Service) to people, many immediately equate a function as being synonymous to a simple API endpoint. To a degree, they are correct. Then, what’s the difference, and why should we look at security in regard to both from different perspectives? I believe the differentiator becomes how the endpoint is exposed, and what its purpose is.
Standard API endpoints will often belong to a broader application or set of microservices that reside behind a shared layer of security. This could be dedicated network hardware, hardened reverse proxies, etc. As a security minded developer, you develop your endpoint and consider the possible client side attack vectors (Guy points to the OWASP Top Ten guide (Open Web Application Security Project) which is a great place to start; Thomas Ptacek also has a great list here); then possibly move on to write another endpoint, which will share these concerns, all the time relying on that first level layer of security.
When you start developing a suite of functions, things can start to get fragmented. Dependencies start to change between functions, software versions might differ, and the ways the functions are triggered may require different configurations on the network/gateway layer.
The second point that stood out was around monitoring: There are countless battle-tested monitoring solutions out there, but the way functions are deployed and used within an underlying architecture might leave them completely out of their scope. Guy makes a great point about how many of these products are agents that rely on long running processes to keep an eye on and collect from. In order to monitor functions, different techniques need to be implemented for short-lived and hot processes.
All of these are great problems to have and point to fast moving innovation in already fast moving industries. You’ll see most vendors and platforms already tackling these issues and building solutions into their products. This space is still young! Here at Iron, we’re committed to helping make IronFunctions become a respected open source solution for delivering FaaS to wherever you want to deploy it.
We are pleased to announce a new project to enable Functions as a Service (FaaS) on OpenStack — Picasso.
The mission is to provide an API for running FaaS on OpenStack, abstracting away the infrastructure layer while enabling simplicity, efficiency, and scalability for both developers and operators.
Picasso can be used to trigger functions from OpenStack services, such as Telemetry (via HTTP callback) or Swift notifications. This means no long running applications, as functions are only executed when called.
Picasso is comprised of two main components:
- Picasso API
- The Picasso API server uses Keystone authentication and authorization through its middleware.
- Picasso leverages the backend container engine provided by IronFunctions, an open-source Serverless/FaaS platform based on Docker.
- OpenStack Wiki
We’ve created some initial blueprints to show what the future roadmap looks like for the project.
You can try out Picasso now on DevStack by following the quick start guide here. Let us know what you think!
If you’re interested in contributing or just have any questions, please join us on the #OpenStack channel in Slack.
Today we’re excited to announce IronFunctions, our first major open source project.
IronFunctions is a serverless microservices platform that you can run anywhere; on public, private, and hybrid clouds, even on your own laptop. The world is moving towards hybrid/multi-cloud, so should your serverless platform.
It runs on top of the popular orchestration frameworks (Kubernetes, Mesosphere), inside PaaS runtime environments (CloudFoundry, OpenShift), and on bare metal.
Functions are packaged using Docker so it supports any language, any dependencies, and can run anywhere. It will also eventually support other container technologies, and today it supports the Lambda function format for easy portability and will soon support others as well.
IronFunctions is written in Go, extremely fast, and written with scalability and operability in mind.
Finally, it’s being driven by our team at Iron.io that is unashamedly taking credit for coining the term serverless dating back to 2011 and 2012. We’ve launched billions of containers through our flagship serverless job processing service IronWorker, and now bring this knowledge and experience to IronFunctions to round out our portfolio of products with synchronous capabilities.
So without further ado, we’d love your help in building an amazing platform and community. Fork the repo and please give us pull requests and create issues!
The Project: https://github.com/iron-io/functions
Join our Slack room: http://get.iron.io/open-slack
The Press Release: http://www.marketwired.com/press-release/ironio-releases-first-open-source-project-2175887.htm
Join the conversation: https://news.ycombinator.com/item?id=12961296
Thanks for supporting Iron.io for the past 5+ years.