Delivery strategies: Apps don't deploy themselves

Delivery Strategies From idea to delivery: apps don’t deploy themselves Thursday, June 17, 2010

So you have a new app. Thursday, June 17, 2010

Julien Smith, Bitnorth09 Thursday, June 17, 2010 It’s going to make everything better.

Thursday, June 17, 2010 You’ll collaborate! http://www.ﬂickr.com/photos/pagedooley/2811157950/

http://www.ﬂickr.com/photos/adamkr/4650637393/ Thursday, June 17, 2010 You’ll be more productive, leaping over obstacles easily.

http://www.ﬂickr.com/photos/joleson/1215644931/ Thursday, June 17, 2010 The road ahead will be clear; you’ll make better decisions.

Photo by Alan Cleaver from his Flicker Freestock set. Thanks, Alan! http://www.ﬂickr.com/photos/alancleaver/2638883650/ Thursday, June 17, 2010 You’ll save money!

http://www.ﬂickr.com/photos/ashevillein/2421648773/ Thursday, June 17, 2010 Revenues will soar!

Thursday, June 17, 2010 ...so why are you so nervous?

What we’ll cover The democratization of IT Understanding your constraints and goals Possible delivery strategies Thursday, June 17, 2010

1950 1960 1970 1980 1990 2000 2010 Government Military Business Hobbyist Consumer Internet Consumer lifestyle Media Thursday, June 17, 2010 Think about the evolution of computing.

Where’s the risk? 1970: 1980: 1990: 2000: The right The right The right The right hardware application integration adoption Client-server Vendor Web, SaaS, XML architectures dominance Enterprise application adoption is the new frontier Thursday, June 17, 2010

Why this happened Disruption and the democratization of IT Thursday, June 17, 2010

http://www.ﬂickr.com/photos/harshlight/3235469361 Thursday, June 17, 2010 Once, IT was a monopoly.

http://www.ﬂickr.com/photos/theclevelandkid24/4251408727/ Thursday, June 17, 2010 Today, it’s a free market. The line of business has tremendous choice in what it owns, runs, and uses.

http://www.ﬂickr.com/photos/hyku/2039448524/ Thursday, June 17, 2010 The boardroom loves this: instead of managing machines, they manage services.

http://www.ﬂickr.com/photos/ukanda/4455286483/ Thursday, June 17, 2010 But enterprise IT doesn’t like it much, because it forces them to compete, and puts them side-by-side with organizations that spend their entire day doing detailed usage and billing.

http://en.wikipedia.org/wiki/Adam_Smith Thursday, June 17, 2010 It’s not all bad, though. There’s a lot to be learned from a transition from monopoly to a free market.

Two reasons. Thursday, June 17, 2010 There were a couple of reasons IT was a monopoly for so long.

http://www.ﬂickr.com/photos/brewbooks/3319730327/ (16MB) Thursday, June 17, 2010 First, the machines were expensive. That meant they were a scarce resource, and someone had to control what we could do with them.

http://www.ﬂickr.com/photos/argonne/4563394851/ Thursday, June 17, 2010 Second, they were complicated. It took a very strange sect of experts to understand them. AVIDAC, Argonne's ﬁrst digital computer, began operation in January 1953. It was built by the Physics Division for $250,000. Pictured is pioneer Argonne computer scientist Jean F. Hall. AVIDAC stands for "Argonne Version of the Institute's Digital Automatic Computer" and was based on the IAS architecture developed by John von Neumann.

http://www.ﬂickr.com/photos/ebeam/3586287989/ Thursday, June 17, 2010 This was also a result of scarcity. When computers and humans interact, they need to meet each other halfway. But it takes a lot of computing power to make something that’s easy to use;

http://www.ﬂickr.com/photos/ecastro/3053916892/ Thursday, June 17, 2010 in the early days of computing, humans were cheap and machines weren’t

http://www.ﬂickr.com/photos/binaryape/458758810/ Thursday, June 17, 2010 So we used punched cards,

http://50ans.imag.fr/images/galerie/Source/IBM-1130-1.jpg Thursday, June 17, 2010 and switches,

http://honeynet.onofri.org/scans/scan22/sol/submission/reverse.jpg Thursday, June 17, 2010 and esoteric programming languages like assembler.

http://www.ﬂickr.com/photos/ﬂem007_uk/4211743886/ Thursday, June 17, 2010 Think about what a monopoly means.

http://www.ﬂickr.com/photos/caveman_92223/3531128799/ Thursday, June 17, 2010 A monopoly was once awarded for a big project beyond the scope of any one organization, but needed for the public good.

http://www.ﬂickr.com/photos/athomeinscottsdale/2850893998/ Thursday, June 17, 2010 Sometimes, nobody wants the monopoly—like building the roads.

Thursday, June 17, 2010 For the most part, governments have a monopoly on roadwork, because it’s something we need, but the beneﬁts are hard to quantify or charge back for.

http://www.ﬂickr.com/photos/leokoivulehto/2257818167/ Thursday, June 17, 2010 (IT’s been handed many of these thankless tasks over the years, and the business has never complained.)

http://www.ﬂickr.com/photos/crobj/4148482980/ Thursday, June 17, 2010 The only time we can charge back for roads are when the resource is speciﬁc and billable: a toll highway, a bridge.

http://en.wikipedia.org/wiki/File:Bell_System_hires_1900_logo.PNG Thursday, June 17, 2010 Sometimes, we form a company with a monopoly, or allow one to operate, in order to build something or allow an inventor to recoup investment. This is how we got the telephone system, or railways.

For much of its history, AT&T and its Bell System functioned as a legally sanctioned, regulated monopoly. The US accepted this principle, initially in a 1913 agreement known as the Kingsbury Commitment. Anti-trust suit ﬁled in 1949 led in 1956 to a consent decree whereby AT&T agreed to restrict its activities to the regulated business of the national telephone system and government work. Changes in telecommunications led to a U.S. government antitrust suit in 1974. In 1982 when AT&T agreed to divest itself of the wholly owned Bell operating companies that provided local exchange service. In 1984 Bell was dead. In its place was a new AT&T and seven regional Bell operating companies (collectively, the RBOCs.) http://www.corp.att.com/history/history3.html Thursday, June 17, 2010 When monopolies are created with a speciﬁc purpose, that’s good. But when they start to stagnate and restrict competition, we break them apart.

http://www.ﬂickr.com/photos/ktylerconk/4096965228/ Thursday, June 17, 2010 In fact, there’s a lot of antitrust regulation that prevents companies from controlling too much of something because they can stiﬂe innovation and charge whatever they want. That’s one of the things the DOJ does.

First: Monopoly good. Thursday, June 17, 2010 In other words, early on monopolies are good because they let us undertake hugely beneﬁcial, but largely unbillable, tasks.

Then: Monopoly bad. Thursday, June 17, 2010 Later, however, they’re bad because they reduce the level of creativity and experimentation.

http://www.ﬂickr.com/photos/wikidave/2867257631/ Thursday, June 17, 2010 Today, computing is cheap. We can buy many times the compute power of the Apollo missions with a swipe of a credit card.

http://www.ﬂickr.com/photos/mbrubeck/4460320021/ Thursday, June 17, 2010 It’s also not complicated. Everyone can use a computer. Because today, the computer is cheap and the human’s expensive we spend so much time on user interfaces, from GUIs to augmented reality to touchscreens to voice control to geopresence.

http://www.ﬂickr.com/photos/raneko/4203965136/ Thursday, June 17, 2010 What used to take a long time to procure, conﬁgure, and deploy is now a mouseclick.

http://www.ﬂickr.com/photos/ﬂem007_uk/4211743434/ Thursday, June 17, 2010 The lesson of monopolies is an important one. When a monopoly set out to build a railroad, it didn’t spend a lot of time asking potential travelers what they wanted.

http://www.ﬂickr.com/photos/dok1/4547024596/ Thursday, June 17, 2010 When you’re building something huge and expensive, you build what you want, and expect people to be grateful for it.

http://www.ﬂickr.com/photos/mmbrown/3102707594/ Thursday, June 17, 2010 But today’s IT user is driving IT requirements.

Thursday, June 17, 2010 They can shop around—choosing SaaS, clouds, and internal IT according to their business requirements.

http://www.codeproject.com/KB/miscctrl/ScriptStudio.aspx Wufoo.com Thursday, June 17, 2010 They’re increasingly able to build the applications themselves, but expect IT to deliver smooth, fast platforms on which to experiment.

USERS APPS PLATFORMS HARDWARE Thursday, June 17, 2010 It’s an inversion of the traditional IT “pyramid”, where the hardware dictates the platforms, which in turn dictates, the apps, which dictates what users can do.

USERS APPS PLATFORMS HARDWARE Thursday, June 17, 2010 Today, what users want to do drives the apps they use, which drives the platforms and the hardware.

Three really big changes. Thursday, June 17, 2010 We’ve had big changes since that time. The ﬁrst was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the ﬁrst spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.

http://www.flickr.com/photos/scriptingnews/3471500626/ Thursday, June 17, 2010 We’ve had big changes since that time. The first was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the first spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.

http://en.wikipedia.org/wiki/File:NCSA_Mosaic.PNG Thursday, June 17, 2010 A second big change was the Web. This browser-based model made computing accessible to the masses. As a result, it became part of society, and everyone knew how to work it. These days, you don’t have to teach a new hire how to use a web browser: they know what links do; what the back button is; and so on.

!"#$%%&&&'()*+,'*-.%#!-/-0%#)1234566)*/%789:;7<=>%? Thursday, June 17, 2010 A third change is the move to mobility. This has been bigger overseas, where the mobile phone is the dominant way of accessing the Internet, but it’s still a shift to the always- connected, always-on lifestyles we lead today.

Now here come clouds Thursday, June 17, 2010 We’ve had big changes since that time. The ﬁrst was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the ﬁrst spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.

http://www.ﬂickr.com/photos/jamesjordan/2751393381/ Thursday, June 17, 2010 Cloud computing is an approach to computing that’s more ﬂexible and lets organizations focus on their core business by insulating them from much of the underlying IT work.

http://www.ﬂickr.com/photos/juniorvelo/3577399832/ Thursday, June 17, 2010 At its most basic, it’s computing as a utility – pay for what you need, when you need it, rather than paying for it all up front.

Picking a delivery strategy Identifying your constraints Thursday, June 17, 2010

Square pegs Does how your app will be used match the goals you have for it? Thursday, June 17, 2010

One to one One to many http://exzanian.blogspot.com/2009/04/zuma-news-only-blip-on-world-radar.html http://www.scottpargettphotography.com/images/photos/crowd.jpg Thursday, June 17, 2010 First, think about the ﬂow of communication and process. Is your intended use one-to-one, or one-to-many?

! Simple Detailed Thursday, June 17, 2010 Then think about message complexity. Are you sending quick, brief information; or very detailed data?

Community Detailed Email Article Blog Private post wiki Forum Google comment group Forum Linkedin post IRC proﬁle change Blog comment Complexity Facebook status update IM Twitter Simple One to one One to many Thursday, June 17, 2010 Form follows function: The dimensions of enterprise software. The reality is that every kind of interaction is unique. Some are private, one-to-one; others are open to everyone. Some are brief snippets; others, detailed prose. Different apps are better for different kinds of interaction; others won’t feel natural.

Operational constraints What are the rules and limitations to consider? Thursday, June 17, 2010

Is performance acceptable? Thursday, June 17, 2010

Figure 3 Interactive user productivity versus computer response time for human-intensive interactions for system A E 600 - 3 T -" INTERACTIVE USER PRODUCTIVITY (IUP) w -HUMAN-INTENSIVE COMPONENT OF IUP 7 MEASURED DATA (HUMAN-INTENSIVE E 500 - A z " COMPONENT) U E - w E 0 > - > - - 400 3 n F 2 0 0 300 - 200 - 100 - 0 0- I 1 I I I 0 1 2 3 4 5 COMPUTER RESPONSE TIME (SI (1981) A. J. Thadhani, IBM Systems Journal, Volume 20, number 4 Thursday, June 17, 2010 There’s a study fromThe human-intensive component of IUP is computed by using between IBM in 1981 that shows strong evidence of the relationship performance and productivity.period 1 interactions, instead of all TSO interactions in more completed As systems get faster, users get EXPONENTIALLY productive. Equation 1. When the number of logged-on users on the systemis small, it is possible for afew users to have aninordinately large effect on the aggregate user work, and hence bias theresults.To minimize bias, all data with fewer than twenty-five logged-on users were excluded from the analysis. Furthermore, to minimize the effect of changes in the aggregate user work at different times of the

http://www.ﬂickr.com/photos/billselak/366692332/ Thursday, June 17, 2010 How fast can you afford? Sure, instantaneous is good, but it also costs an inﬁnite amount.

Customization Thursday, June 17, 2010 How many people want to customize their word processor?

http://www.codeproject.com/KB/miscctrl/ScriptStudio.aspx Wufoo.com Thursday, June 17, 2010 Remember those drag-and-drop, parametric screens?

Thursday, June 17, 2010 Many SaaS providers are adding customization and scripting that blurs the lines of what’s a cloud, and what’s an app, and what’s a programming language. Now that you can write code for Google Apps -- as in this example of a script that sends custom driving directions to everyone in a spreadsheet -- the distinction is less and less clear.

The turnkey/tuning tradeoff. Thursday, June 17, 2010

Standardized Easy Impossible Sloppy Easy Tailored Slow, Fast/lean, with inefﬁcient economies of scale Thursday, June 17, 2010 Unfortunately, there’s a tradeoff here -- everyone wants fast, cheap, and customized. You can only have two. The more tailored your IT systems are, the more you’ll be paying for them and the slower they’ll be. At the same time, if you use the same applications and processes as everyone else you may sacriﬁce important differentiators.

http://www.ﬂickr.com/photos/andrewparnell/2738598951/ Thursday, June 17, 2010 An increasingly important criteria is the ability to connect existing systems to new ones. Whether this is legacy applications (for authentication, data exchange, or single sign-on); or to third-party customers and partners, the ability to link your systems to others is a huge deal.

Thursday, June 17, 2010 This is one of the reasons a thriving ecosystem around a platform is so important -- because it’s an indicator of ability to develop to the platform, as well as a starting point for integration and extension.

http://www.ﬂickr.com/photos/oobrien/7597395/ Thursday, June 17, 2010 Then there’s compliance and security. This may include geographic and legislative issues (where you can put your data) as well as auditing and logging (some industries require physical collection by a separate system.)

Security is a... Reason to avoid clouds 23% Reason to move to clouds 43% No opinion 34% http://www.thewhir.com/web-hosting-news/102309_IT_Firms_Skeptical_About_Cloud_PEER_1_Study Thursday, June 17, 2010 This isn’t just about avoiding on-demand systems. The odds are good that many cloud providers are better at security than you are.

Budget & operating constraints What can you afford to take on? Thursday, June 17, 2010

Airfare DNS Cloud Public transit Important research Hotel Thursday, June 17, 2010 Aﬀordability

Money spent Point at which it’s cheaper to buy than rent Time (years) Thursday, June 17, 2010 The economics of renting versus buying apply here, too, since the investment is approaching zero. The traditional way of looking at this is to compare an upfront investment to the rental model of a lesser investment (integration, training) and a pay-as-you-go cost.

Money spent Cheaper to rent for longer Time (years) Thursday, June 17, 2010 Several things have changed in recent years in this respect. First, the upfront investment of a pay-as-you-go model has dropped: everyone knows how to use a browser; everyone can access things remotely; vendors have trial models; and so on. So it takes longer to get to the point where it’s cheaper to run your own thing.

Unforeseen costs of owning Money spent Time (years) Thursday, June 17, 2010 There’s also the impact of owning things. Often, IT is a distraction; we make decisions based on existing investments, which means we don’t change things when we can, which means we become less agile.

Money spent Efﬁciencies from economies of scale passed on to customers Time (years) Thursday, June 17, 2010 There’s also the impact of owning things. Often, IT is a distraction; we make decisions based on existing investments, which means we don’t change things when we can, which means we become less agile.

5 year planning horizon 6 months Money spent Payoff time Time (years) Thursday, June 17, 2010 But even if you ignore all of these, here’s why pay-as-you-go wins more and more often: Your time horizon isn’t what it used to be. By the time you’ve paid off your in-house investment, your business will have changed in order to adapt, and you’ll be after something else.

Ease of adoption How readily will your users take to it? Thursday, June 17, 2010

Thursday, June 17, 2010 Existing standards: why do you know what to do here?

Thursday, June 17, 2010 Learning curve is okay; in fact, it’s recommended. Think what it would be like to have to use a wizard every time you wanted to do something.

Thursday, June 17, 2010 Consider Excel: most beginners can grasp it easily; but it’s designed to allow experts to be more productive. This is essential when evaluating how readily your user base will adopt something -- not just on day one, but on day ﬁfty, when they’re expected to be fast and error-free.

http://www.ﬂickr.com/photos/farhannasir/4577508824/ Thursday, June 17, 2010 Also consider the impact of mobility, and new platforms. Will your users be able to adopt the application in all the places they work?

App/usage fit: Does app function match planned use? Is the flow of information the right degree of open? Do users work at the right degree of information detail? Operational constraints Will it perform fast enough to make users productive? Can I customize it to my business without making it suck? Can I connect it to myself and my partners? Does it comply with legal, privacy, security requirements? Budget & operating constraints How does it embody new payment models (freemium, etc.)? Do I understand the ROI & TCO of my chosen approach? Ease of adoption Does it use existing standards & conventions my users know? Can first-timers use it, but experts be fast & efficient? Will it work in mobile, disconnected, touch UI, etc.? Thursday, June 17, 2010 Here’s a quick recap of the criteria we just saw.

Possible delivery strategies Platforms & business models to choose from. Thursday, June 17, 2010 Okay, now let’s look at some of the platforms and business models you can use for this.

Dedicated On-premise Virtual Third-party hardware private clouds private clouds public clouds Thursday, June 17, 2010 There’s a spectrum of platforms out there on which you can run an application.

Bare metal (this is your computer) Thursday, June 17, 2010 First, there’s bare metal.

http://techyshit.com/15-computer-ads-from-the-past-1950-1980/ Thursday, June 17, 2010 It’s pretty cheap. The vast majority of costs -- sometimes as much as ﬁve times the cost of the hardware -- come from operating it, powering it, cooling it, and so on.

Virtual machines Still yours... Thursday, June 17, 2010 Then there’s virtualization.

http://www.ﬂickr.com/photos/mynameisharsha/4092086880 Thursday, June 17, 2010 The step-‐func7on nature of bare-‐metal dedicated machines doesn’t distribute workload very eﬃciently.

http://www.ﬂickr.com/photos/h4ck/2413562108/ Thursday, June 17, 2010 Virtualization lets us put many workloads on a single machine

http://www.ﬂickr.com/photos/stawarz/3538910787/ Thursday, June 17, 2010 Once workloads are virtualized, several things happen. First, they’re portable

http://www.ﬂickr.com/photos/swimparallel/3391592144/ Thursday, June 17, 2010 Second, they’re ephemeral. That is, they’re short-‐lived: Once people realize that they don’t have to hoard machines, they spin them up and down a lot more.

http://www.ﬂickr.com/photos/genewolf/147722350 Thursday, June 17, 2010 Which inevitably leads to automa3on and scrip3ng: We need to spin up and down machines, and move them from place to place. This is hard, error-‐prone work for humans, but perfect for automa3on now that rack-‐and-‐stack has been replaced by point-‐and-‐click

http://www.ﬂickr.com/photos/pinkmoose/3278324276/ Thursday, June 17, 2010 Automa7on, once in place, can have a front end put on it. That leads to self service.

Virtualization divorces the app from the machine. One on many (or) Many on one Physical machine Virtual machine Virtual Virtual Virtual Physical Physical Physical machine machine machine machine machine machine Virtual Virtual Virtual Physical Physical Physical machine machine machine machine machine machine Thursday, June 17, 2010 Okay, so these things mean we have applications that run “virtually” – that is, they’re divorced from the underlying hardware. One machine can do ten things; ten machines can do one thing.

“Cloudy” tech. Thursday, June 17, 2010 These are the founda7ons on which new IT is being built. Taken together, they’re a big part of the movement towards cloud compu7ng, whether that’s in house or on-‐demand. If you do all these things, you’re running what many people call a “private cloud”

Virtual private clouds (feels like yours) Thursday, June 17, 2010 If you like the virtualization, but don’t like having to carry a screwdriver around, virtual private clouds may be right for you.

http://nature.wallpaperme.com/Nature-Historical-Buildings/Fairy+Tale+Fantasy_ +Neuschwanstein+Castle_+Bavaria_+Germany.jpg.html?g2_imageViewsIndex=1 Thursday, June 17, 2010 In this approach, you have a machine that feels like it’s your own -- complete with a private IP address and so on. If you want to connect it to the Internet, you do so yourself; it’s just like virtual infrastructure, but someone else is running it.

Infrastructure as a Service Amazon EC2, Rackspace Cloud, Terremark, Gogrid, Joyent (and nearly every private cloud built on Zenserver or VMWare.) Thursday, June 17, 2010 When IT people talk about cloud computing, they usually mean something called IaaS.

http://aws.amazon.com/ec2/pricing/ Thursday, June 17, 2010 These are really just virtual machines I can use for just an hour, already connected to the Internet. Here’s Amazon’s “menu” of machines.

• 60 seconds per page Desktop EC2 • 200 machine Pages 17,481 17,481 instances Minutes/page 1 1 • 1,407 hours of virtual # of machines 1 200 machine time Total minutes 17,481 • Searchable database Total hours 291.4 26.0 available 26 hours Total days 12.1 1.1 later • $144.62 total cost Thursday, June 17, 2010 A great example of these clouds in action is what the Washington Post did with Hillarly Clinton’s diaries during her campaign. They needed to get all 17,481 pages of Hillary Clinton’s White House schedule scanned and searchable quickly. Using 200 machines, the Post was able to get the data to reporters in only 26 hours. In fact, the experiment is even more compelling: Desktop OCR took about 30 minutes per page to properly scan, read, resize, and format each page – which means that it would have taken nearly a year, and cost $123 in power, to do the work on a single machine.

Machine Web Image server Machine instance Thursday, June 17, 2010 In an IaaS model, you’re getting computers as a utility. The unit of the transaction is a virtual machine. It’s still up to you to install an operating system, and software, or at least to choose it from a list. You don’t really have a machine -- you have an image of one, and when you stop the machine, it vanishes.

DB Machine Storage server Image Machine instance App Machine Server Image Machine instance Web Machine server Image Machine instance Thursday, June 17, 2010 Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk

DB Storage server Machine instance Bigger App machine instance Server Machine instance Web server Machine instance Thursday, June 17, 2010 If you run out of capacity, you can upgrade to a bigger machine (which is called “scaling vertically.”)

DB Storage server Machine instance App Server Machine instance Web server Machine instance Load balancer Machine instance Thursday, June 17, 2010 Or you can create several machines at each tier, and use a load balancer to share traffic between them. These kinds of scalable, redundant architectures are common -- nay, recommended -- in a cloud computing world where everything is uncertain.

Platform as a Service Google App Engine, Salesforce Force.com, Rackspace Cloud Sites, Joyent Smart Platform, (and nearly every enterprise mainframe.) Thursday, June 17, 2010 The second kind of cloud is called Platform as a Service. In this model, you don’t think about the individual machines—instead, you just copy your code to a cloud, and run it. You never see the machines. In a PaaS cloud, things are very different.

Shared components Data Processing platform Storage API Others’ Others’ code code User Auth database API Your Others’ code code Image Image functions API Others’ Others’ code code ... Big Blob Governor Console Schedule objects API Thursday, June 17, 2010 - You write your code; often it needs some customization. - That code runs on a share processing platform - Along with other people’s code - The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN - To keep everything running smoothly (and bill you) the platform has a scheduler (ﬁguring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.

http://code.google.com/appengine/articles/load_test_screenshot.jpg Thursday, June 17, 2010 Here’s a shot of some code running in Google App Engine. I only know that I’m paying by CPU-hour, or for units like bandwidth, email, or storage. This could be one machine whose CPU was used 8%, or a hundred, or a thousand. I don’t know.

http://code.google.com/appengine/articles/logs_admin.png Thursday, June 17, 2010 I can see the logs for my application. But these aren’t for a single machine -- they’re for the application itself, everywhere.

http://googleappengine.blogspot.com/2010/03/easy-performance-proﬁling-with.html Thursday, June 17, 2010 I can even ﬁnd out what parts of my code are consuming the most CPU, across all machines.

Thursday, June 17, 2010 And even their latency when served to people.

http://www.computerhok.nl/JSPWiki/attach/GoogleAppEngine/GAEQuota.png Thursday, June 17, 2010 It’s a true, pure utility because you pay for what you use.

http://www.ﬂickr.com/photos/olitaillon/3354855989/ Thursday, June 17, 2010 This is a very different model from IaaS. On the one hand, it’s more liberating, because you don’t have to worry about managing the machines. On the other hand, it’s more restrictive, because you can only do what the PaaS lets you.

IaaS and PaaS differences IaaS PaaS Any operating system you Use only selected want languages and built-in APIs Limited by capacity of Limited by governors to virtual machine avoid overloading Scale by adding more Scaling is automatic machines Use built-in storage Many storage options (ﬁle (Bigtable, etc.) system, object, key-value) Thursday, June 17, 2010 In the case of Google’s App Engine, you have to use their functions and store things in the way they want you to. You get great performance from doing so, but it probably means rewriting your code a bit.

Quota Limit Governor Apps per developer 10 (usage cap) Time per request 30s Blobstore (total ﬁle size) 1GB Maximum HTTP response size 10MB Datastore item size 1MB Application code size 150MB Daily cap Emails per day 1,500 (free quota) Bandwidth in per day 1 GB Bandwidth out per day 1GB CPU time per day 6.5h HTTP requests per day 1,300,000 Datastore API calls per day 10,000,000 URLFetch API calls per day 657,084 http://en.wikipedia.org/wiki/Google_App_Engine Thursday, June 17, 2010 PaaS platforms impose usage caps and billing tiers. Here’s Google App Engine’s set of quotas and free caps.

i.developerforce.com/index.php/Apex_Code:_The_World%27s_First_On-Demand_Programming_Language Thursday, June 17, 2010 In the case of Salesforce’s Force.com, you have to use an entirely new programming language, called Apex.

Software as a Service Salesforce.com, Google Apps, Microsoft Ofﬁce Live, pretty much any ISV still around today. Thursday, June 17, 2010 The third kind of “cloud” app is really just a new software delivery model; I hesitate to call them clouds at all, actually. It’s SaaS. And it’s what most people outside of IT think of as “cloud computing.”

Thursday, June 17, 2010 The third kind of cloud is called Software as a Service, or SaaS. Some people argue that this isn’t a cloud at all, just a new way of delivering software. But it’s also what the masses—the non-technologists—think cloud computing means. The problem is that SaaS is pretty much synonymous with “dynamic website” or “the Internet” these days. Nevertheless, if an ISV is shipping software on discs still, their days are numbered.

How you pay for it Lots of business models Thursday, June 17, 2010

DIY You can always write your own stuff. Thursday, June 17, 2010

Open source Standing on the shoulders of giants Thursday, June 17, 2010

Github analysis by Franck Cuny: http://www.ﬂickr.com/photos/franck_/sets/72157623447857405/ Thursday, June 17, 2010 Github is a great example of how social coding has transformed and revitalized the open source world, particularly for high-level languages like Rails and Python.

Thursday, June 17, 2010 One last thought about building your own, rather than building it as part of a bigger platform: Adoption is what matters. There’s a build-your-own dilemma: If you create a new environment, you need to change users’ patterns.

Licensed software Oh, how quaint. http://www.penneydesign.com/ folio_IM_retrogamesmodernthemes.html Thursday, June 17, 2010

Freemium And other sad, bad portmanteaux Thursday, June 17, 2010

Collaborative Transactional business business model User creates model content Free Paid Content becomes Content remains part of template private library Engagement, Eventual Revenues SEO ranking conversion Thursday, June 17, 2010 New freemium models for SaaS blend transactional and collaborative revenue approaches. In this model, “free” users help build the corpus of templates, contributing to SEO ranking and the richness of the offering; while paying users can keep their work private.

Composed application Stitching together loosely coupled pieces Thursday, June 17, 2010

Thursday, June 17, 2010

SaaS Pay as you go. Thursday, June 17, 2010

Thursday, June 17, 2010 Whether it’s PaaS, SaaS, or IaaS, the model is the same: Sell IT on demand, rather than as software or machines.

Adoption The real risk when the app is a utility Thursday, June 17, 2010

Thursday, June 17, 2010 The whole reason you deploy apps is so that you can focus on the things you do best: whatever adds the most value to your business.

Thursday, June 17, 2010 You also deploy apps to handle processes you didn’t want to do yourself anyway.

“What information consumes is rather obvious: it consumes the attention of its recipients. Hence, a wealth of information creates a poverty of attention and a need to allocate that attention efﬁciently among the overabundance of information sources that might consume it.” Herbert Simon Thursday, June 17, 2010 The problem isn’t delivery: we have plenty of options for that. It’s adoption.

http://www.ﬂickr.com/photos/gideon/6582069/ Thursday, June 17, 2010 But your users might well not adopt the app despite your best efforts, because they don’t like it, or don’t notice it, or aren’t adopting it in the way you’d hoped.

http://www.ﬂickr.com/photos/roebot/4271975019/ Thursday, June 17, 2010 At the same time, you’re seeing what tools and processes are getting adopted -- what’s working? what’s popular? -- and doubling down on those things.

How do you ﬁx this? Thursday, June 17, 2010

Analytics. Thursday, June 17, 2010

ATTENTION ENGAGEMENT CONVERSION NEW VISITORS SEARCHES GROWTH CONVERSION PAGES TIME RATE TWEETS NUMBER OF VISITS PER ON x MENTIONS VISIT SITE GOAL ADS SEEN LOSS VALUE BOUNCE RATE Thursday, June 17, 2010 Here’s the simplest possible analytics model.

For transactional sites Can people buy things? Thursday, June 17, 2010 Remember the four kinds of sites? You need to analyze and optimize the app you’re delivering in the same way. A site that wants visitors to complete a transaction—normally a purchase—is transactional. There’s an “ideal path” through the site that its designers intended, resulting in a goal or outcome of some kind. The goal isn’t always a purchase; it can also be enrollment (signing up for email) or lead generation (asking salespeople to contact them), and can happen either online or off. For e-commerce, that’s whatever your transaction consists of.

For media sites Are ads loading quickly and successfully clicked through? Is content loading fast enough for visitors? Thursday, June 17, 2010 These sites offer content that attracts and retains an audience. They make money from that content through sponsorship, advertising, or affiliate referrals. Search engines, Adwords- backed sites, newspapers, and well-known bloggers are media properties. For media sites, that’s making money from ads.

For collaboration sites Can visitors contribute (posting content, voting?) Is bad content being mitigated (trolling, spam)? Thursday, June 17, 2010 On these sites, visitors generate the content themselves. Wikis, news aggregators, user groups, classiﬁed ad listings, and other web properties in which the value of the site is largely derived from things created by others are all collaborative. For collaboration, that’s creating and curating content.

For SaaS sites Are your end users productive? Are they making fewer mistakes? Is the site working during customers’ business hours? Thursday, June 17, 2010 These sites are hosted versions of software someone might buy. SaaS subscribers expect reliability and may pay a monthly per-seat fee for employees to use the service. Revenues come from subscriptions, and a single subscriber may have many user accounts. On some SaaS sites, users are logged in for hours every day. For SaaS sites, that’s productivity and an error-free experience.

Enterprise subscriber $ 1 End user (employee) $ Refund $ 2 Renewal, upsell, SLA reference SaaS site violation Performance Good Bad 3 Helpdesk Support 5 $ Usability escalation costs 7 4 Good Bad Productivity Good Bad 6 Churn $ Impact on site $ Positive $ Negative Thursday, June 17, 2010 The closest your app will be to one of the four “public” websites is a SaaS site. Here’s the business model for a SaaS site.

(Insert your app here) ? Are they adopting the app at the rate you expect? Are they abandoning the old ways? What are they using most or neglecting? How productive are they? Where are they making mistakes? Thursday, June 17, 2010 What does your adoption and usage map look like?

The cycle of optimization Metrics & strategy Optimization Collection & change Link to KPI/ Reporting ROI Institutionalizing the results Thursday, June 17, 2010 Optimization involves a constant cycle of collection, reporting, communicating and sharing the data, tying it to business processes, changing the system, and repeating.

The good news: you can experiment easily We stop worrying about ROI when I is zero. Thursday, June 17, 2010

http://www.ﬂickr.com/photos/steven_wong/2440355239/ Thursday, June 17, 2010 They’re not dictating and restricting; rather, they’re regulating usage to ensure a good balance of risk and experimentation

Beyond adoption: outcomes Business Deployment Awareness Adoption outcomes Thursday, June 17, 2010 Once you’ve got adoption, you’re not done: the same tools will let you measure the outcomes: - More productivity - Abandonment of old/bad methods - More leads - Lower cost - Fewer errors - Etc.

One ﬁnal thought Paving the cowpaths Thursday, June 17, 2010

http://www.ﬂickr.com/photos/jelles/2902422030/ Thursday, June 17, 2010 One approach is to “pave the cowpaths.”

http://www.ﬂickr.com/photos/32314864@N02/3253051215/ Thursday, June 17, 2010 This is an old civil engineering trick: Watch where people walk, then put paths there.

The next 3 days The inside-out organization: Connecting to Tuesday customers and markets Mobile Platforms and Enterprise Agility The Politics of Delivery: Compliance and Wednesday Governance Platform Options in the New IT Landscape Social Behavior, Usage Patterns, and Adoption Can IT Lead the Social Business Strategy Thursday Formulation Process? Delivery Strategies: The Road Ahead Thursday, June 17, 2010

Thanks! @acroll alistair@bitcurrent.com Thursday, June 17, 2010

Delivery strategies: Apps don't deploy themselves

by Alistair Croll on Jun 17, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 72

Statistics

Delivery strategies: Apps don’t deploy themselves — Document Transcript

http://www.bitcurrent.com	68
http://www.lmodules.com	4