As of today, Iron.io formally joined the Cloud Foundry Foundation, the community behind the rapidly growing open source Platform-as-a-Service (PaaS). With this exciting news, I wanted to take a quick moment to reflect on what brought us here, and where we see ourselves moving towards.
As a follow up to my previous post, The Workloads of the Internet of Things, I wanted to walk through a real world example that fully captures the principles of event-driven computing put forth.
Let’s set the stage first… imagine we operate a windmill farm and want to continually track optimal weather conditions to maximize energy output. What basic steps need to be taken?
- Sensors capture surrounding weather conditions
- Captured data is delivered to a backend service
- The service calculates the expected power generation
- Calculated data is delivered to an analytics system
- Data is presented in a variety of charts and maps
This process flow sounds similar to the common Extract, Transform, Load (ETL) pattern, however the distinction to make here is that data is pushed from the source to the backend service instead of pulled. This means we need to update our pipeline to be more reactive.
The rise of the API economy in recent years has also given the integration economy a much needed breath of new life. What was once a painful process of dealing with proprietary formats and clunky middleware, has now become a streamlined process via openly consumable cloud-native REST APIs. As such, a new breed of services such as Zapier and IFTTT have come along to make API integrations as simple as a few clicks, while other products such as Slack have made integrations a first class citizen feature of the product itself.
The technology that powers many of these integrations behind the scenes is webhooks, essentially an event-driven callback – when this happens, notify that via HTTP POST. Webhooks are an incredibly useful feature with many services, however as developers, we’ll always find a scenario that’s beyond what’s provided out of the box. With service integrations, this often means performing custom data translations such as field mappings, or additional business logic such as filtering and tagging.
We see a lot of our customers bridge services together using IronWorker because of its direct webhook support, flexibility to run any custom logic in any language, ability to scale concurrently behind the scenes, and “serverless” environment. We say “serverless” in quotes because to a developer, there’s never a need to think or worry about provisioning resources to run and manage tasks at scale. When one of our users shared his custom integration using IronWorker on Twitter, I got in touch to hear more and share his story.
I must say my favorite part about researching the Internet of Things has to be the mind blowing stats. Just a couple from the arsenal… we already have more connected devices on the planet than humans, and every two days we create more data than all of human history up to 2003. The predictions are wild too… Intel predicts that there will be 200 billion connected devices by 2020, and Cisco predicts the market size to reach $14.4 Trillion by 2022. It’s hard to really wrap your head around numbers like that, but there was one that really jumped out at me – IDC predicts that Internet of Things workloads will increase approximately 750% by 2019. Why that really matters: how on earth are we going to handle that level of scale?
Bleacher Report (B/R) is one of the leading sports news sources in the country. Second only to ESPN, Bleacher Report is a growing force for team-specific sports content, commentary, and real-time event coverage. B/R’s goal is to deliver a comprehensive experience for sports fans and foster engagement with favorite teams and topics across all major sports. The content that B/R delivers includes curated content originating from featured columnists and external sources, all pushed to fans in real-time. They provide timely and relevant news to sports fans keeping them informed and ahead of the game.
Today, Iron.io announced Project Thor, which is developing the world’s first hybrid job processing system. This is unlike anything we’ve done to date. Unlike previous IronWorker technology, Project Thor is architected to deliver the power of Iron.io to any server in the world in minutes.
With Project Thor, the Iron.io IronWorker Docker container is deployed on a company’s own servers, which then communicates with the Iron.io API. This brings the power of Iron.io’s event-driven computing service to the Enterprise in just a few easy steps. Project Thor seamlessly integrates with existing solutions for container deployment, such as OpenShift by Red Hat, Cloud Foundry, OpenStack and Kubernetes.
Flexibility and the freedom to choose are among the core tenets at Iron.io. For those who have been following Iron.io posts for some time, we’re sure you’ve read a number of the Docker-related developments we released over the past year, including the previous blog post that IronWorker supports custom Docker images. This is awesome not only for many reasons from a workflow perspective, it also means there’s no lock in.
Our friends at Treasure Data wrote a blog post about data collection in Ruby and how to run multiple data collection tasks in parallel (or scheduled) using IronWorker. The example from Treasure Data demonstrates what it takes to build a simple logging application in Ruby with IronWorker to manage and log the output to Treasure Data, which can then perform queries.
As noted in the blog, this example is not a complete solution but an illustration to show users what’s possible when combining Iron.io and Treasure Data. Big thanks to John Hammink and the Treasure Data team for their work to educate the community.
Here’s an excerpt from the original post:
Blow Sh*t Up with Arnold Schwarzenegger … Be Drawn Into an Episode of the Simpsons … Celebrate the Patriots Victory with Rob Gronkowski.
These aren’t even bucket list items, these are unattainable items. That is, until Omaze gets involved. Omaze is an organization that was founded to drive significantly more money and awareness for deserving causes through the chance to live out dream experiences.
Charities offer up personalized events with their celebrity partners where everyone has the chance to win by donating to the cause. Each experience offers a range of reward levels from signed t-shirts to personalized Skype sessions to Twitter mentions, and once the experience is placed up on the Omaze site, the countdown begins to the winner of the grand prize. The growing number of high profile celebrities participating to provide such unique opportunities begs the question – what’s your dream experience?
A couple of months ago, we announced a new workflow for IronWorker based on Docker that enabled you to test your worker code locally on the exact same environment as it is when running on the IronWorker cloud. The initial feedback we received was pretty consistent: “This is great, but can you make it more flexible when it comes to using images?”
Up until now, you had to use one of our predefined Iron.io images (or stacks as we used to call them). Although these images cover most major languages and OS packages that you might want, that didn’t match the needs of all users. At Iron.io, we know empowering the developer is key. That includes enabling developers to make choices about how they use Docker.
Today, we’re announcing full Docker support allowing you to use any Docker image, including your own custom images. This feature is in beta and is only available on dedicated accounts to begin with, please contact us if you’d like to try it out.