handling asynchronous workloads with openshift and iron.io
Post on 14-Aug-2015
370 Views
Preview:
TRANSCRIPT
Ivan Dwyer | Business Development | Iron.io
ivan@iron.io | @fortyfivan
Handling Asynchronous Workloads in OpenShift with Iron.ioEvent-Driven Computing for the Modern Cloud Era
Agenda
➔ The Modern Cloud
➔ Event-Driven Computing
➔ Where Iron.io Fits
➔ Live Demo
➔ Iron.io and OpenShift
Evolution
Server VM Container
Monolith N-Tiered Microservices
Major Release Software Updates Continuous Delivery
DIY Software Defined API-Driven
Unit of Scale
Application Architecture
Deployment Model
Async Workloads
The Modern Cloud Stack
IaaSOn-demand compute, storage, and networking
resources
PaaSApplication configuration, management, and
deployment
SaaSAPIs and services to build and extend
applications
➔ Developers want to innovate
➔ Developers want abstraction
➔ Developers want self-service
➔ Developers want freedom
➔ Developers want consistency
➔ Developers want to write code!
Developer Empowerment
The modern cloud provides developers everything needed to build, deploy, and scale applications.
But what about the workloads that happen in the background?
“GitHub is 50% background work”
Making a Distinction
Applications Tasks
Hosted
Load Balanced
Elastic
Orchestrated
Realtime
Ephemeral
Queued
Concurrent
Choreographed
Asynchronous
Identify the Right Pieces
➔ Outside of user response loop
➔ 3rd party service API calls
➔ Long running processes
➔ Transaction Processing
➔ Scale-out / burst processing
➔ Scheduled jobs
IndependentSingle Responsibility
StatelessInterchangeable
Loosely CoupledAsynchronous
Email & Notifications Multimedia Encoding Transactions Web Crawling
Data Transfer Data Crunching 3rd Party API Calls Scheduled Jobs
Common Tasks
Event-Driven Workflows
Webhook Callback
API Call Stream
Transaction Schedule
Queue Queue
Database AnalyticsSystem
API App UI
Notification Log
Event Trigger Task Execution Results Delivered
New Goals
➔ Build highly scalable and reactive backend systems
➔ Respond to events and changing environments automatically
➔ Run processes at scale without managing infrastructure
➔ Distribute workloads without configuration management
➔ Collect, deliver, and transform data seamlessly
➔ Integrate components into a unified platform
The Challenge
➔ Building functionality for async concurrency is extremely complex
➔ More moving parts means more components to keep track of and configure properly
➔ Loosely coupled services means steps must be taken to keep data consistent
➔ Distributed services creates more API traffic and communication layers
➔ Keeping applications and task workloads in sync is challenging
Building and maintaining a reliable environment for handling asynchronous workloads within distributed
applications is extremely challenging.
There is a need for a task-centric platform to handle the inner working of these workloads, while remaining tightly
integrated with the app-centric platform.
This is what Iron.io aims to solve.
What We DoWe build technology to power asynchronous workloads at scale
for distributed applications of all kinds
Decouple Components
Treat your applications as a collection of microservices that scale up and down
independently.
Respond to Events
Trigger workloads on-demand based on events that happen in the lifecycle of your
systems and applications.
Choreograph Workflows
Chain together previously complex process flows with ease by setting endpoints and
triggers.
Message Queue Job Scheduler Task Environment
How It Works
Build Upload Run Scale
➔ Build lightweight tasks
➔ Use any language
➔ Containerize with Docker
➔ Commit to a repo
➔ Package as a container
➔ Upload to Iron.io
➔ Set event triggers
➔ Create schedules
➔ Queue tasks on-demand
➔ Set concurrency levels
➔ Scales automatically
➔ No provisioning needed
Iron.io Concepts
➔ Workers: The task code and our unit of containerized compute.
➔ Runners: The runtime agent that spins up containers for workload processing.
➔ Stacks: Docker images that provide basic language and library dependencies.
➔ Queues: Method of dispatching workloads through a persistent message queue.
➔ Schedules: Regular occurring tasks much like cron jobs, but managed.
➔ Concurrency: Number of tasks run at the same time and our unit of scale.
➔ Clusters: Location and environment for runner deployment and workload processing.
Under the Hood: Features
API
Code History Dashboard Monitoring Task Queue Priorities Schedules Auto Retry Auth Encryption Audit Trail
Management Choreography Security
Under the Hood: Components
API
PriorityManager
TaskScheduler
Public Cloud
On-Premises
TaskQueues
CustomerCode
DockerImages
When To Use Iron.io
Microservices
Decouple application components as independently developed and deployed services that are choreographed by Iron.io.
Internet of Things
Choreograph machine generated workloads asynchronously with Iron.io’s reliable data transport and task-centric runtime.
Mobile Compute
Run a “serverless” backend that doesn’t interfere with the user experience by triggering workers to run in the background.
Hybrid Cloud
Offload individual workloads to Iron.io while maintaining secure in-house systems using the same APIs across all environments.
Why Choose Iron.io
“Serverless” EnvironmentPower large-scale workloads without
the need to provision and manage infrastructure.
No Ops NeededCreate complex workflows without
configuration scripts or complex async/concurrent code.
Workload ScalabilityScale effectively and efficiently at the
task level through lightweight and loosely coupled containers.
Developer FriendlyCloud-native API-driven feature set with
client libraries across all major languages.
Speed to MarketComprehensive environment that gets
up and running in minutes with seamless platform integrations.
Hybrid CapableDeploy the service and distribute
workloads to any cloud environment, public or private.
Case Study: Bleacher Report
1. Sports story breaks
2. Event trigger spins up thousands of tasks in IronWorker
3. Each concurrent task sends thousands of push notifications
Result: Bleacher Report can send millions of push notifications in under a minute
Case Study: Hotel Tonight
1. Scheduled IronWorker pulls data from a variety of sources
2. Data is pipelined into IronWorker for transformation
3. Data is pipelined to destination data warehouse
Result: Hotel Tonight has dozens of sources syncing 24/7
Case Study: Untappd
1. Mobile user “checks in” a beer
2. Background tasks are kicked off to run concurrently
3. App is refreshed with data results
Result: Untappd cut its event response time from 7 seconds to 500 milliseconds
“Speed of delivery is a constant focus for us. No longer worrying about infrastructure allows us to focus on
delivering new features and optimizing existing ones.”
“IronWorker’s modularity allows for persistent points along the lifetime of the pipeline. Each worker in the
pipeline is responsible for its own unit of work and has the ability to kick off the next task in the pipeline.”
“I like that I don't have to worry about whether to scale more servers. It's done automatically by Iron.io, which is
key for us and obviously why we love the platform."
Iron.io Deployment Models
Public CloudElastic scalabilityNo MaintenanceRich feature set
DedicatedSecure gateway
Managed serviceHigh performance
.
On-PremisesMulti-site deploymentFlexible configuration
Safe and secure
OpenShift Enterprise Integration➔ Docker service packaging
◆ Both IronMQ and IronWorker are packaged via container◆ IronMQ passed certification, IronWorker up next
➔ Kubernetes HA deployment◆ Each service can be deployed as pods◆ The task runtime can be deployed as pods
➔ Scale via replication controller◆ Simply add nodes for more service instances◆ Simply add nodes for more workload capacity
➔ Service broker API◆ SSO and service binding to applications◆ Supports multitenancy
"Vendors that embrace the concept of public and private PaaS are also in favor of hybrid PaaS models where
workloads can be directed to either public or private instances depending on how an enterprise sets
application policy. Hybrid models provide the most flexibility where the private and public PaaS components are the same or have been specifically designed to work
together.”
top related