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

(1)

Development Model for the

Cloud

Paradigm Shift of the Same Old Same Old?

Dr. Umit Yalcinalp, Salesforce.com

(2)

Computing History

Reduce Complexity, Do More

 

Turing Machines

 

Assembly code

 

Programming Languages

 

Application Frameworks

 

Application Platforms

 

Application Servers

 

Scripting and Dynamic Languages

(3)

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

(4)

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, …

(5)

(6)

(7)

(8)

(9)

(10)

(11)

(12)

(13)

(14)

(15)

(16)

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

(17)

(18)

Today Cloud Computing Platforms 1960’s Mainframe 1980’s Client/server

(19)

1980’s Work Group Computing 2000s Intranet Computing

Collaboration

Moving to the Cloud

(20)

Throw in a lot of new technologies …

Map reduce Column db Worker task Scheduler administration Data service

(21)

The Three AmigoS of Cloud Computing

Cloud Computing Platforms

 

Software

–  Hosted apps, abstracting APIs, OS, Data storage…

 

Platform

–  Hosted collection of APIs, abstracting OS, data storage, …

 

Infrastructure

–  Hosting virtual servers, OS and some kind of data store

DA

TA

(22)

(23)

Abstractions and Services

(24)

Cloud Developer Concerns:

Capabilities Managed Environment

 

Abstraction Level

–  Capabilities

–  Constraints

 

Managing the Managed Environment

(25)

Lets Look at these Cloud Computing Platforms

 

Amazon WS

 

Microsoft Azure

 

Google App Engine (GAE)

(26)

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)

(27)

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))

(28)

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

(29)

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

(30)

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

(31)

Where do the Application Requirements get

addressed?

Next Level in PaaS:

–  Infrastructure

–  Application Server Capabilities

Force.com Platform:

(32)

Quarterly Revenue ($M)

Revenue through fiscal quarter ended 10/31/09

FY2005 FY2006 FY2007 FY2008 FY2009 FY2010

First Cloud Company to Exceed:

Annual Revenue Run Rate

(33)

FY2006 FY2007 FY2008

FY2002 FY2003 FY2004 FY2005 FY2009 FY2010 Paying Customers

Strong Growth In New Customers

(34)

(35)

Three AmigoS and Force.com

 

Software: Applications on Salesforce.com Cloud

 

Platform

 

Infrastructure:

  Multitenant Kernel

  Data Storage

  ISO 20071 Certified Security

  Loan Balancing

  Replication & Recovery

  Transaction Management

  Sandboxed Application

  Trust (Status Monitoring

  Customizable

(36)

Integration Development Methodology Logic User Interface Analytics Distribution

Platform - Force.com Philosophy:

•  Common Things Simple Complex Things Possible •  Development Activity

• Declarative • Programmable

•  Metadata Driven with Shared Data Model

•  Built in: Customizable UI, Analytics, Distribution, Workflows

•  Iterative Development Paradigm: “See it as you build it”

•  Application Sharing/Exchange

•  Enforce Good Development Practices Development to Production: Testing

(37)

(38)

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

(39)

Two Development Approaches:

 

Web Interface

–  What you build is what you see

–  Rapid Prototyping

 

Eclipse Plugin

(40)

Application

Data Model

LineItem Invoice Merchandise Name IsDeleted … • Text • LongText • RichText • Boolean • Number • Picklist (single or Multivalue) • … • Computed Fields • Formula • Rollup • Lookup: 1-m • Master-Detail: Hierarchical

(41)

Business Logic

Field Requiredness/Uniqueness Audit History Tracking

Workflows Rules & Approval Processes

Declarative Logic (point and click)

Formula-Based Logic (spreadsheet-like)

Procedural Logic (code)

Formula Fields

Data Validation Rules

Workflows Rules & Approval Processes

(42)

(43)

(44)

(45)

(46)

(47)

(48)

(49)

(50)

(51)

(52)

(53)

(54)

Next Stop Wonderland:

Collaboration for the Enterprise

(55)

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

(56)

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

–  Mobile development

–  Search

(57)

Application Development: 5X Faster

At half the cost

(58)

(59)

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

(60)

(61)

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

  Testing

  Versioning

  Monitoring

(62)

(63)

(64)

Conclusion:

 

Choose Your Abstraction Level Wisely:

–  Flexibility(Roll Your Own) vs. Time to Develop(Managed)

–  Think long term

(65)