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.
Travis Reeder, CTO and co-founder of Iron.io, gave a talk at Goto Chicago 2016 discussing Iron.io’s early migration to Go, why we changed our infrastructure and the benefits it has brought to us.
One of the questions that always comes up after telling people we migrated to Go is:
“Why not Ruby?”
Continue reading “Four and a Half Years of Go in Production at goto Chicago 2016”
Thanks to Eutelsat_SA for the base image! CC BY 2.0
Space, the final frontier. If only we could take selfies. Wait, what? We can? This is the service Astro Digital provides. A selfie-stick from space is my crude analogy. Turns out, there are better analogues.
I had the pleasure of catching up with Bronwyn Agrios, head of product at Astro Digital, to learn how it works. In Bronwyn’s (much more refined) words, Astro Digital is kind of like DropCam for space. Just pick a spot to monitor. When new images are snapped, Astro Digital runs some fancy image processing algorithms, and boom! You’re notified of new space-selfies.
Click to enlarge the Astro Digital infographic:
(more content below)
Continue reading “Case Study: Astro Digital – DropCam for Space”
There is a ton of use cases for batch processing and every business is probably doing it in some way or another. Unfortunately, many of these approaches take much longer than need be. In a world of ever increasing data, the old way can now hinder the flow of business. Some examples of where you’ll see batch processing used are:
- Image/video processing
- ETL – Extract Transform Load
- Genome processing
- Big data processing
- Billing (create and send bills to customers)
- Report generation
- Notifications – mobile, email, etc.
We’ve all seen something that was created during a batch process (whether we like it or not).
Now, I’m going to show you how to take a process that would typically take a long time to run, and break it down into small pieces so it can be distributed and processed in parallel. Doing so will turn a really long process into a very quick one.
We’ll use Docker to package our worker and Iron.io to do the actual processing. Why Docker? Because, we can package our code and all our dependencies into an image for easy distribution. Why Iron.io? It’s the easiest way to do batch processing. I don’t need to think about servers or deal with distributing my tasks among a bunch of servers.
Alright, so let’s go through how to do our own batch processing.
Continue reading “Docker + Iron.io = Super Easy Batch Processing”
Thanks to Yahoo for the base image CC BY 2.0
As one of the earliest users of Docker, I’ve had the pleasure of creating and working with multiple different platforms built on containers. Each platform has evolved in step with current ecosystem around it, and I’ve gotten the chance to really put Docker’s “batteries included, but removable” philosophy to the test.
Here at Iron.io, we have launched over 1 billion user containers in production, not to mention the containers we launch to keep our services running. The massive volume of containers we launch is enough to place great demands upon any platform that we use.
In our search for the right direction for the evolution of our platform, we’ve explored as many tools as possible. The release of Docker 1.9, combined with production-ready Docker Swarm and Docker Networking, brings a lot of value to those wanting to roll their own platforms.
Continue reading “Shepherding Containers”
Thanks to Jared for the base image CC BY 2.0
Containers make life easy. Oh, you don’t have Ruby 2.2 installed? No problem, try this Docker image. Knowing what I tested on my local is exactly what’s running on production gives me warm fuzzies.
Docker gets a lot of love because it simplifies development. That’s not all though. If Docker punished infrastructure, there’d probably be a lot less love going around. Thankfully, Docker does some cool things on the infrastructure side, as well.
The biggest benefit is the “right-sizing” of compute resources. Your program might only need 200 MB of memory. Why dedicate an entire VM + OS to that? Docker insures our compute resources are neatly divided by memory and CPU between instances. Neat! There’s a lot to love about Docker on the infrastructure side, as well.
Continue reading “Right-sizing with Docker Stats and cAdvisor”
I had a lot of fun sharing pre-commit with everyone earlier this week. In case you missed it, here’s a link. As a follow up, I whipped together a quick How-To video.
In it, you’ll follow along as I add a pre-commit hook to a brand new Node.js project. Init a git repo locally, and you can the same as you watch. I’ll take you through adding the initial config, picking your hook, and testing to make sure pre-commit works. Continue reading “Helpful hints: Pre-commit”
Thanks to Kārlis Dambrāns for providing the base image. CC BY 2.0
Facebook’s suffered three outages this month; two of which occurred within the span of a week. Ouch. If you know any folks on the FB ops team, now’s a good time to buy ‘em a beer.
Whenever a blip like this appears, it’s a good time for all of us to look at our own infrastructure. Are you prepared?
First things first, what caused the FB outage? Facebook links the most recent to an issue with the Graph API. The September 22nd issue was due to a hiccup with the Realtime Update service. It’s the sort of thing that could happen at any company.
Despite the impact, it’s good to see Facebook has a sense of humor about the downtime. Their response to the update service issue reads, “will post an update here as soon as we know more.” I love the sly wink.
Continue reading “Learning from Facebook’s Outage”