Securing Serverless

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.

Four and a Half Years of Go in Production at goto Chicago 2016

GOTO_Chicago2016

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”

Case Study: Astro Digital – DropCam for Space

Astro Digital a case study from space

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”

Best Practices and Anti-Patterns for Workers and MQs

Best Practices and anti-patterns for workers and message queues

Thanks to Ruth Hartnup for the base image! CC BY 2.0

If you’ve been programming for a while, it’s probable that someone, somewhere, has recommended the Gang of Four book.

The book dissects Object Oriented programming. It lists numerous ways of royally messing things up, but it’s claim to fame is that it also lists ways to do it right! These well tested paths to success often come with explanations for when to use them and why they’re good at avoiding common pitfalls.

These are design patterns. They’re embedded in the culture of programming, and they’re an amazing way to learn from others’ mistakes. At the outset of any project, a lot of paths are open to you. Design patterns illuminate the dark paths from the healthy, low stress approaches.

Today, we’re releasing our very own set of best practices and anti-patterns in the form of a white paper. It’s a quick read and will save you time as you tinker on your own workers and message queues. So, what do you have to lose?

Continue reading “Best Practices and Anti-Patterns for Workers and MQs”

Docker + Iron.io = Super Easy Batch Processing

lotsocontainers

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”

Shepherding Containers

Shepherding Containers

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”

Right-sizing with Docker Stats and cAdvisor

Right-sizing Docker

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”

Message Queues & Workers: the Heart of Modern Infrastructure

Message Queues + Workers

Thanks to Sonny Abesamis for the base image! CC BY 2.0

Increasingly, message queues and workers are intertwined with the language of modern infrastructure. You might rely on explicit solutions like IronMQ or IronWorker. You might not. Whether you do or don’t is irrelevant: MQs and workers are in everything these days.

MQs and workers are hidden heroes, quietly powering a lot of the technology that many of us rely on. They’re core components in programming languages, MVC frameworks, and even web servers.

As a result, when making infrastructure decisions a good understanding of both MQs and workers is essential. The white paper below will take you from a fuzzy understanding to a well-versed conceptualization for both MQs and workers.

Download the latest white paper from Iron.io: a Refresher on Message Queues & Workers.
Give it a read and let us know what you think!

Helpful hints: Pre-commit

Get going with pre-commit (video)

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”

Learning from Facebook’s Outage

Making the most of Facebook's outage 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”