While the Heroku platform can scale massively, you still need to design your app to scale efficiently. Join us as we show you how to apply good practices around Caching, Buildpack creation, Slug compilation optimization, environment management, multi-threading of API calls, API cache warming, and data replication. We'll also show you the tools for logging and monitoring services available on the Heroku platform so you can evaluate your app performance and resolve any challenges along the way.
Developer Data Modeling Mistakes: From Postgres to NoSQL
Best Practices for Creating Scalable Apps with Heroku
1. Heroku – Best Practices
for Creating Scalable Apps with Heroku
Vincent Spehner, Tquila, Heroku Practice Manager
@vzmind and @herokusalesforceplaybook
2. Safe harbor
Safe 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 uncertainties
materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results
expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be
deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other
financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any
statements 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 new
functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our
operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any
litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our
relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our
service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to
larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is
included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent
fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor
Information section of our Web site.
Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently
available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions
based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these
forward-looking statements.
3. Introduction
Last year at Dreamforce to discuss with speakers talking about
Heroku and meet early adopters of the Platform.
▪ Released the first version of Heroku Salesforce Playbook on Xmas
2012
• Heroku history
• Introduction to Heroku Toolbelt
• Java and Ruby tutorial to get started
▪ Next release available soon (Xmas 2013)
• Presenting 15+ detailed use cases
http://herokusalesforceplaybook.com
4. Introduction
Today the objective is to present some common mistakes done
when building Cloud app (including on Heroku) and learn how to
avoid them
▪ Platform / language neutral
▪ First we need to understand how Cloud Apps are different ?
• Heroku 12 factors
• Cloud App with remote Data/API
5. PaaS 12 factors
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing Services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
http://12factor.net/
7. The API latency syndrome
How to detect it ?
▪ Pages taking ages to display
▪ API Quota reached quickly (few hours)
▪ More than 5 API calls per action
▪ App not working at specific moment of the day
SOLUTION : CACHE EVERYWHERE IT’S REQUIRED !!
9. Understanding Caching options
Cache vs Data replication vs Data synchronization:
▪ Cache: store temporarily data locally to avoid further calls
▪ Data replication: copy remote data locally
▪ Data synchronization: best of both, local and synchronized
10. Understanding Caching options
Cache vs Data replication vs Data synchronization:
▪ Caching weakness: you need to sweep it regularly and automate it
▪ Data replication weakness: bi-directional update replication implies potential
conflict which need a proper management
▪ Data synchronization: most robust option, hard to implement
12. API cache warming
Principle
▪ You already know that your application need to get the list of remote
static objects
▪ Add a worker dedicated to Cache warming
▪ Store all remote Static records locally
▪ Define refreshing strategy on the worker itself
14. Salesforce custom APEX End Point
Objective:
▪ Reduce API calls
▪ Access Hidden Business Logic
Creating custom APEX endpoint:
▪ Group API calls
▪ Aggregate objects/records/business process results in ONE call
▪ Trigger complex Apex code from a REST endpoint
15. Environment management
Is your local machine the Test env ?
▪ Cloud app might behave differently than on your Local Machine or Test
Server
• Assets compilation failing
• Process running differently
• Static Configuration
• Memory management
• Remote API calls
16. Environment management
Solutions:
▪ Dev ENV as clause of Heroku PROD ENV than possible
▪ Duplicate your Production ENV for TEST
▪ Use Foreman locally
▪ Share Heroku config with your team and load it as part of your ENV
▪ Of course you can spin up and down Heroku TEST env
17. No clues on errors
Logplex principle
▪ Logs are an event Stream (12 Factor number XI)
Monitor early, drive safely:
▪ Start recording logs from the beginning with enough storage capacity
▪ Monitor your app
▪ Make sure your logs are relevant
20. Conclusion
▪ Cloud apps - Heroku apps - require specific care
▪ Caching, Log stream, Env management as described in 12 Factor-app
▪ Rethink data storage and data exchange as they are not local
▪ Check the playbook, share your ideas with Book authors
21. All about Tquila
Tquila is the main european Salesforce Partner specialized
on Salesforce implementation, Mobile and Social
applications with 250 consultants in Europe, Asia, Australia.
▪ 102 customers
▪ 304 projects
▪ 204 certifications