In other words, a scalable application is built such that it can grow grow as needed.
We’ll be covering both of these topics. Building a scalable app and integrating the application with Salesforce (and email?)
Daily deal site like one kings lane get vast majority oftraffic at 8am to noon.Most api’s have rate limits. If our lead gen app got 100,000 people one day, the system breaks.
There is a simple solution that can help with all of these problems. CLICKCheck out this Apple fan, he’s pumped, he got his iphone. Sure he had to wait a bit in the lineup around the block, but he got what he wanted without getting trampled.
Let’s dig a bit deeper into the first two.
This is a scene from the Matrix where they are standing in a huge white data center, they were about to launch their application, and Neo says “I need servers, lots of servers.” I think that’s how it happened anyways. Let me show you why.
The red part is the servers you’ll need to handle the spikes. As you can see, a lot of wasted capacity to handle a single spike.
Traffic spikes don’t matter. Queue soaks it up (orange) and with a bit of extra time, all the work is processed and we’re all good.
Maintain and find issues: code base is much smaller and isolated.Eg: your front end is taking orders, but your backend merchant system is down, it doesn’t matter.
Show workers/lead_worker.worker and lead_worker.rb. Can run it once or a million times with same worker. Show that it’s uploaded in hud. https://hud.iron.io/tq/projects/4f10ae4fb21c531b30001448/jobs
If you need to scale after all this…
And did you notice? NO SERVERS!
How to Create a Scalable System using Force.com, Heroku and Iron.io
Create a Massively Scalable Systemwith Force.com and HerokuTravis Reeder, Iron.io, CTO and Co-founder
Safe harborSafe harbor statement under the Private Securities Litigation Reform Act of 1995:This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertaintiesmaterialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the resultsexpressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could bedeemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or otherfinancial items and any statements regarding strategies or plans of management for future operations, statements of belief, anystatements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering newfunctionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in ouroperating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome ofintellectual property and other litigation, risks associated with possible mergers and acquisitions, the immature market in which weoperate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, newreleases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilizationand selling to larger enterprise customers. Further information on potential factors that could affect the financial results ofsalesforce.com, inc. is included in our annual report on Form 10-Q for the most recent fiscal quarter ended July 31, 2012. Thisdocuments and others containing important disclosures are available on the SEC Filings section of the Investor Information section ofour Web site.Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currentlyavailable and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions basedupon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
I amTravis ReederCTO and Co-Founder of Iron.ioIron.io provides massively scalable and elastic cloud infrastructureservices: IronWorker, IronMQ and IronCache.Building things to scale is our business.
ScalabilityScalability is the ability of a system, network, or process, to handlea growing amount of work in a capable manner or its ability to beenlarged to accommodate that growth.Source: Wikipedia
Systems integrationSystems integration is the process of linking together differentcomputing systems and software applications physically orfunctionally, to act as a coordinated whole.Source: Wikipedia
The example applicationLead gen form.User fills out form, stores the info, poststo Salesforce as a lead and sends useran email.Easy right?
Easy? Not at scale How do you keep your application responding fast at high load? How do you deal with spikes?• Daily deal Site at 8am• You get TechCrunched How do you deal with Rate Limits?• Rate limits at Salesforce– 5000 requests per day (208 per hour)– 5 concurrent requests
There is a simple solutionQueues Message Queues Task Queues
QueuesAn amazing developer tool, great for: Spikability Keeping database load consistent Decoupling parts of your application Improving application performance• If it doesn’t need to be done while user is waiting, then don’t do it, put it on aqueue Integrations / communication between systems
SpikabilityIf you do all your work in your application, you need servers... lotsof servers.
Spikability without queuesNeed enough servers to handle the maximum traffic you mightsee.
Spikability with queuesQueues soak up spikes with no performance or data loss.
Keeping database load consistentYou decide how fast you want to process, not your traffic.
Decoupling / integrationsUsing queues to communicate between parts of your system is agood idea. Splitting your application into smaller parts can also bea good idea. Loosely coupled If one part fails, the others don’t You can upgrade different parts separately Maintain and find issues much easier Oftentimes you have no control over it if it’s a third party
The Heroku appSimple form.The only thing the controller does is queue upa worker task.
IronWorker task queueCreate a worker and upload it once:ironworker.tasks.create(“lead_worker",config.merge(name: params[:name],email: params[:email],company: params[:company))iron_worker upload lead_workerThen queue up tasks for it:
IronMQ message queueVery simple to use. One side pushes messages onto a queue (inour example, this is our lead gen app):The other side pulls them off (Boomi in this case):A message can be any arbitrary data that both sides understand.ironmq.queue(“lead”).post(msg.to_json)ironmq.queue(“lead”).get()
BoomiBoomi enables drag and drop integrations between SaaS and On-Premise applications via its out of the box connectors.
Scaling• On the front end, we’ve offloaded most of the work and there is no databaseto worry about, but if you need to scale it, Heroku makes it easy:• IronWorker and IronMQ are fully elastic so no scaling required.• Boomi and Salesforce, the main things to consider are rate limits and otherlimits.heroku ps:scale web=20
Let’s Try It!Grab your phone and go to:http://ironforce.herokuapp.comThis demo is running on a single Heroku Dyno and its ready tohandle this room and then some.I promise I won’t spam you. But feel free to reply and contact me.
Travis ReederCTO and co-founderCode can be found at:https://github.com/treeder/ironforce