This is a slide deck of the presentation given in QCon London 2010

1. Development Model for the
Cloud
Paradigm Shift of the Same Old Same Old?
Dr. Umit Yalcinalp,
Salesforce.com
Developer Evangelist

2. Computing History
Reduce Complexity, Do More
 Turing Machines
 Assembly code
 Programming Languages
 Application Frameworks
 Application Platforms
 Application Servers
 Scripting and Dynamic Languages
 …

3. Striving Towards Less Complexity
 Punch Cards
 Cobol
 C++
 Platforms
 Application Servers
 Scripting and Dynamic Languages
 …

4. Take Application Servers as an Example…
 Essential Built in services
– Load Balancing
– Memory Cache
– Transaction Management
– Connection management
 Packaging a full app (war, ear, …)
 Security/Authentication
 Messaging Infrastructure simplifies tasks
 User management
 Monitoring and Management of Apps
 Versioning
 Tooling and Composition
 Integration APIs (WS, REST, …)

5. However
Business App Dev Requirements stayed similar…
 Develop an application that has m abstract entities. Define relationship between
entities.
 Display data subset j in a page and update data set if x is true.
 Implement and Deploy an application that has n users where a user can belong to
one of k different roles
 Restrict access of data subset j to user role i
when x is true.
 If user role has made change p, notify user roles s.
 Do {x, y, z, send email, fax, ….to m users}
when f happens.
 Do f every {day, week, …} when s …
 Generate report on … organized by …
 Make the application extensible, customizable…
 Deploy mobile client for app that maintain disconnected data for user using dataset
x.
 Integrate app with Twitter, feed, …
 Integrate app with Payment System, …

6. Challenges in traditional way of developing
apps remained…

7. Infrastructure Services: Hardware

8. Infrastructure Services: Operating System

9. Infrastructure Services: Database

10. Infrastructure Services: App Server

11. Application Services

12. Operational Services

13. Business Services

14. How do many developers make this happen?

15. Putting it together: Duct Tape!

16. Complexities Abound
to Final Destination
Final
Application Infrastructure Application Operational Business App
Ideas Services Services Services Services
Network Security Authentication
Ordering
Storage Sharing Availability
Provisioning
Operating System Integration Monitoring
Licensing
Database Customization Patch Mgmt
Billing
App Server Web Services Upgrades
Renewal
Web Server API Backup
Upgrades
Data Center Multi-Language NOC
Marketing
Disaster Recovery Multi-Currency
Sales
Integrated Workflow
Analytics
Multi-Device
Messaging
Search

17. Now comes along Cloud Computing Paradigm
The chatter and buzz on the street…
 About developing services, platforms and applications
 Don’t host but use hosted resources elsewhere
 Develop with hosted services, software, platforms
 Pay as you go
 Consume as you go
 Monitor and adopt

18. Applications Moving to the Cloud
1960’s 1980’s Today
Mainframe Client/server Cloud Computing
Applications

19. Platforms Moving to the Cloud
1960’s 1980’s Today
Mainframe Client/server Cloud Computing
Platforms

20. Collaboration Moving to the Cloud
Lotus Notes SharePoint
Novell GroupWise Groove
File Sharing
1980’s 2000s Today
Work Group Intranet Social
Computing Computing Computing

21. Throw in a lot of new technologies …
Map reduce
Column db
Data service
Worker task
administration
Scheduler
What does this new paradigm offer to app
developers?…

22. The Three AmigoS of Cloud Computing
Cloud Computing Platforms
 Software
?!
– Hosted apps, abstracting APIs, OS, Data storage…
 Platform
DATA
– Hosted collection of APIs, abstracting OS, data storage, …
 Infrastructure
– Hosting virtual servers, OS and some kind of data store

23. ?!

24. Abstractions and Services
They are all over the Map

25. Cloud Developer Concerns:
Capabilities Managed Environment
 Abstraction Level
– Capabilities
– Constraints
 Managing the Managed Environment
 Cost Indirectly Affecting Development

26. Lets Look at these Cloud Computing Platforms
 Amazon WS
 Microsoft Azure
 Google App Engine (GAE)
 Force.com

27. Services Available:
 Virtual OS instances EC2
 Data Services
– S3
– RDS
 Additional Services:
– Load Balancing Servers
– Simple Queue Service
– Elastic MapReduce
Processing Large Data Sets
• Job Flows on top of Hadoop
– Different granularity of accessing data (i.e. Pig)
• Monitoring Individual Task Progress
…

28. Developer Perspective
 Hosting Locally Built Infrastructure Deployed Elsewhere
 Hosting Locally Built Apps
 Building Data Management Platform
 Testing/Monitoring
– Great Console for Infrastructure Monitoring
– Deployed app still responsibility of developer

29. Amazon AWS Activity:
 Not about OS and simple data store anymore
 Hosting
– Existing Infrastructure Components: JEE, DB2, …(composed images)
– Traditionally built apps
 What do you build with it
– More infrastructure: DIY app server functions for scalability & composition
• Load Balancing
• Deciding when to take resources offline (in development testing)
– Low Level Data Services
• Large Data Processing (must understand Hadoop…)
– Infrastructure Management Logic
 Development Methodology: It Depends!
 Managing/Debugging Your App:
– Console (monitoring, debugging, management (upgrades, shutdown))
– Remote scripts managing specific to installed components

30. Microsoft Azure Platform:
 Hosting Azure applications on Microsoft Cloud
 Services for backend development (Old and New)
– Table (Data Storage)
– Asynchronous Worker Tasks
– SQL Azure
 Develop/Deploy
– Requires OS+Long list of Packages Installation Locally
– Built/Test on local development environment
 Entry Point for developers is Visual Studio
– .NET libraries
– Local debugging
– Local packaging(.cspkg)/Manual deployment to location based Microsoft cloud
 Management of Remote Servers/Services
– Requires Server Logs Messages for managing
 Very tailored to existing Microsoft developers
– Java developer targeted with Third Party tools porting APIs

31. Google App Engine
 Services: Lean App Server Features
– JPA API for hiding BigTable
– Connection support, Cron like jobs
– User Administration (Google accounts/Roll your own)
 Backend development Basics
– BigTable/GFS
– Tasks Queues (experimental)
 Built/Test on local development environment
– Naturally independent of OS
– JRE + GAE
 Managed Environment Limits
 Entry Point: Eclipse
– Develop Locally/Deploy war file Remotely
 Remote Monitoring
– System Logs
 Multilanguage (Java/PHP)

32. Commonalities & Differences Emerge
 Abstracted Large Data Set or SQL
 Managed Environment Limits
 Asynchronous Task/Process Management
– Deal with Data Sets
– Working with Managed Environment Limits
 Delineation of Development & Production
 Art of “System Log” Recording and Monitoring

33. App Services and Application Requirements?

34. Where do the Application Requirements get
addressed?
Next Level in PaaS:
– Infrastructure
– Application Server Capabilities
Force.com Platform:
Application Services + Integrated End2End Framework

35. First Cloud Company to Exceed:
$1.3 Billion +
Annual Revenue Run Rate
Quarterly Revenue ($M)
FY2005 FY2006 FY2007 FY2008 FY2009 FY2010
Revenue through fiscal quarter ended 10/31/09

36. Strong Growth In New Customers
67,900+
Paying Customers
FY2002 FY2003 FY2004 FY2005 FY2006 FY2007 FY2008 FY2009 FY2010

37. The Cloud Computing Model
Multi-tenant
Automatic Upgrades
Pay-as-you-go
Elastic
Application Development:
5X Faster
At half the cost

38. Force.com Platform for Building Applications

39. Three AmigoS and Force.com
 Software: Applications on Salesforce.com Cloud
 Customizable
 Extensible
 Platform
 Infrastructure:
 Multitenant Kernel
 Data Storage
 ISO 20071 Certified Security
 Loan Balancing
 Replication & Recovery
 Transaction Management
 Sandboxed Application
 Trust (Status Monitoring

40. Platform - Force.com Philosophy:
• Common Things Simple
Complex Things Possible
• Development Activity
Distribution • Declarative
Development Methodology
• Programmable
Analytics
User Interface • Metadata Driven with
Shared Data Model
Logic
• Built in: Customizable UI, Analytics,
Integration
Distribution, Workflows
Data Model
• Iterative Development Paradigm:
“See it as you build it”
• Application Sharing/Exchange
• Enforce Good Development Practices
Development to Production: Testing

41. Hello World?

42. Development Process
 Create an “org”: Private on SFDC cluster
– A collection of applications
– Built on top of shared metadata
– Every org becomes live and pre-populated with metadata
– Can accommodate > 1 developers depending on license
 Develop/Test
 If Sandbox, Complete Tests to Production
 Register Custom URL/Expose as Website
 “Package” specific app for AppExchange

43. Two Development Approaches:
 Web Interface
– What you build is what you see
– Rapid Prototyping
 Eclipse Plugin
The App is alive on the cloud

44. Application
Data Model
Name
Merchandise LineItem Invoice IsDeleted
…
• Text • Lookup: 1-m
• LongText • Master-Detail:
• RichText Hierarchical
• Boolean
• Number
• Picklist (single or SOQL: Object Oriented Query Language
Multivalue) Metadata
• …
• Computed Fields
• Formula
• Rollup

45. Business Logic
Declarative Logic (point and click)
Field Requiredness/Uniqueness
Audit History Tracking
Workflows Rules & Approval Processes
Formula-Based Logic (spreadsheet-like)
Formula Fields
Data Validation Rules
Workflows Rules & Approval Processes
Procedural Logic (code)
Apex Triggers
Apex Classes

46. Declarative Workflow: Visual Process Manager

47. Data Model Realized in Default UI Unlimited Real-Time
Customization

48. Custom Pages

49. Sites

50. Saw that even BigFoot is moving to the
Cloud…

51. Next Stop Wonderland:
Collaboration for the Enterprise
• One can follow any Entity just like a User
• Same Development Paradigm with Any
Entity in the platform

52. Developer’s Toolbox
 Language Runtime: Apex: Java, C# like language
– For creating CRUD Logic on Data Model (triggers)
– Executing Queries (SOQL and SOSL)
– Developing Controllers in conjunction with VF Pages
– Background Process Management
• Scheduled Tasks
• Batch Processes for handling large data sets
 Eclipse Plugin
– Developed using WS APIs
– Retains only metadata locally
– Allows browsing metadata, dynamic SQL and code execution
– Remote execution, commit of metadata, dynamic code blocks
– Synchronizes live development with an org on the cloud
– Enables versioning locally with external tools

53. Developer
 Integration Toolkits:
– Force.com WS API language bindings in target
languages, environments
 Packaging Apps for Distribution
– Within an org selecting an app
– Requires Test Implementation
 Sandboxing
– A snapshot of metadata (and data) of an existing org
– Requires testing to move to production
 Integral Part of Development Process:
– Testing Framework
– Governance Limits

54. Differences in Platforms
 Degrees of Abstraction and Tight Integration with Data
Model
 Abstraction of Application Server Capabilities
 Exposing Application Framework Capabilities
 Data Model & Handling and Managing Large Data
 Background Process & Task/Queue
 Governance Limits
 Level of Integration Support
 Level of Management Needed from Developer
 Tangible and Intangible Cost of using a platform

55. The Duct Tape Index for Cloud Platforms

56. Cloud Development Landscape
 Levels of Abstraction
 Application Composition
 Development Environment (local, remote, mixed)
 Workflow
 Development and Deployment Cycles
 Customizability / Extensibility
 Integration
 Being a Good Citizen
 Versioning
 Monitoring
 Cost of Trying out a Platform

57. The confusion should not be cloud developer’s
epitaph

58. Where a developer wants to get…

59. Conclusion:
 Choose Your Abstraction Level Wisely:
– Flexibility(Roll Your Own) vs. Time to Develop(Managed)
– Think long term
 Being a Good Citizen is Not Optional
 Logs and Monitoring Rules in Clouds

60. Q & A!
http://developer.force.com!
Twitter: umityalcinalp !

61. Typical Development Cycle
 Create your own image/Packaging
– Bundle App Server/Application
 Install/Manage Remotely
 Monitor Deployed Services to scale and use
– Are more servers needed?
– Is a bigger database needed?
– Do I need to shut down my servers during development?
 Manual Redeployment

62. User Interface: MVC Model Programmable
User Interface