As a team we were joking around the other day looking for new naming models that could properly reflect the self-managing, self-repairing nature of our Grid environment. And what became very clear was that we needed to create a new term that reflected the higher order policies associated with resource management - like financial/revenue arbitrage.

It’s one thing to talk about automated, lights out management, in which most if not all of the precipitating events are well known, and appropriate reactions coded in scripts. Further, you could allow for cascading events, and policy based (weighted) rules tied to a federating paradigm - btw, this is really starting to really reflect the state of the art here (fair harbour clause). But what happens when you actually bring financial/market driven rules and experiences into the solving of these problems? You get utility value optimizing automation… or the “Free Market Utilimatic” (there's a reason I'm not in branding)

Back in February we (Sun and Archipelago Holdings) described the potential of developing a commodity exchange for more traditional Data Center capabilities: network, compute and storage as they really are beginning to become commodities. We know that they’re commodities because of the competition across specific platforms that Sun and it’s competitors always face: it’s not a battle of speeds, feeds or features, but rather price that differentiates - in fact, that compute products are increasingly interchangeable, has been driven by buyers, our customers who wanted choice. As such, it’s fully appropriate that these commodity elements have a market derived value, and we all know that where there are free markets, there are people who trade in their futures. So if spot commodities and futures both have inherent value, then why cannot we leverage this value information to help us prioritize tasking (distributed scheduling), direct our resources (straight thru provisioning) and even help to plan the “onlining” of capacity (resource planning).

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/utilimatic_it_s_autonomic_on

In a recent Information Week article by Darrell Dunn, he tells of a survey by AFCOM:

This is well and good, customers are seeing the utility in using someone else's capital to run their businesses. The problem is that so long as IBM's David Gelardi continues to say:

We have to ask ourselves, so what's the holdup... could it be IBM's “Customization” business, that sustains complexity within a customer's processes and systems to drive revenue? Where is that customization.... Power vs. x64, AIX vs. Linux (which distribution), and the ever increasing complexity of the Globus Toolkit target?

BTW: is this transparent to you? Also, AFCOM has a really interesting article on the importance of workflow as a utility enabler.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/are_you_locked_in

Gotta love the Register with it's vulture logo. But I came across this headline, “Itanic sinks at Lloyds Register” and just had to laugh...

As most of you know, we have been proceeding to build out Sun Grid with a focus on Opteron based processors. What is becoming increasingly clear is that there is a cost of power - namely that power efficiencies will be a critical element of any utility offering. We really notice this when we try and power cycle quite a few racks (32 nodes x ~350W = ~11kW/rack) at the same time and recognize that instantaneous power-on spikes (booting every node at once) could cause us to blow circuits. In fact, where we used to pay “per circuit” for power, many of our co-lo partners are now moving to metered power just like we do at home. This really makes some sense because power in = heat out, which is really a recognition that though floor space is expensive, that power density is a very large contributing factor to overall cost.

This makes me double excited about our Niagra based processors which are expected to provide 8 cores at < 60W:

“Imagine the potential impact to IT operations: a single blade shelf designed to do the work of 32 of today's 4-way servers; eight rack units instead of 160; less than 3 kilowatts of power versus 38; one blade system to manage instead of 32 servers.”

and I haven't even started to talk about the relative balance in performance that Concurrent Multi-Threading (CMT) provides in beginning to address the growing gap in cpu clocking vs. memory latency in which traditional processor designs are frequently waiting for the data that they need to perform useful work to become available.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/too_risky_even_for_lloyds

Sorry for my week long hiatus,

Last week I attended a telematics conference in Detroit MI (Telematics Update). One of the things that I realized, once there, is that telematics, something that I have been working on since 2000, still hasn't reached the status of mainstream, in fact, far from it. Furthest along is Onstar, but even they haven't been able to do something that I think is critical: to develop a community of value around a technology platform.

It seems to me that in everyone's attempt to “own” the customer - and by doing so, justify the expense of the infotronics gateway for telematics delivery through directed revenue, that people have kind of ignored the business models of very successful companies like DoCoMo, where a bet was made that the platform would take off when a suitably rich community existed.

I talked briefly with Scott McCormick, President of the Connected Vehicle Trade Association and he agrees that we need a cross-industry community, that he is trying to form. But, to me at least, it seems a chicken-or-egg situation persuant to this community. One of the big problems is obviously that the auto makers want to enforce both a standard look and feel, and in doing so ensure compliance with “distracted driver” rules - who can blame them, but also they are concerned that they could shoulder the $100-$300/car burden for the inter-vehicular gateway and not be able to properly capitalize on their investment. Gee, this is starting to sound a good bit like the challenges that we had with the J2ME handset profiles ;)

Anyways, after reading Ron Goldman and Richard Gabriel's excellent book, Innovation Happens Elsewhere, which i HIGHLY recommend, it became fantastically clear - to me, at least. The automotive community must establish a community effort to standardize an appropriate interface for the developers to be able to build against, in a suitable community, or risk having a consumer platform become the defacto candidate wresting all control from this community (auto-TiVO(sm) anyone?)

Anyways, I'm pretty passionate about telematics because I think that this is one remaining untapped market that can drive business productivity, drives mobility interfaces (identity and contexts), and lastly could serve to improve my life balance...

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/telematics_update_detroit

I recently came across this analysis from Thom Hickey, with whom I have absolutely no relationship: so his analysis is totally his own, [but I have taken the liberty to restructure]

So, let's take some of Thom's #'s:

Now this doesn't look that high (though I'd suggest that these economics are akin to measuring the cost to produce energy using a home generator vs. an efficient commercial gas turbine), but when we really dig into how he is using his Grid, we can begin to see the real benefit of utility business model:

which isn't an efficient use of capital by any measure.

As Thom states: “Even if you throw in the occasional run-away process that burns up cpu time for a weekend, out-of-pocket costs should be under $30,000/year.”

In fact, even at 4x the apparent /cpu-hr cost, to do testing, having error prone jobs, and even scaling up the jobs, we're still well under 50% of the cost of maintaining your own cluster.

Furthermore, we still haven't looked at the networking costs, the job management/operational costs and other burdens. Sun Grid, for example has an Infiniband option which provides a 4xIB non-blocking fabric. For those of you who haven't been watching Infiniband, it is quite different than the bussed fabric's like Ethernet and has performance that increases as nodes are added vs. the reverse for Ethernet. This provides a very interesting extra-chassis backplane-like technology and is roughly 1/2 the cost of a 10GbE equivalent (per port cost). Ask other competitors how their grids are architected, I'll be that you'll see that not only is our business model unique, but so is our architecture.

A: it's not that SunGrid is necessarily cheaper, pre-se, but that multi-tenancy and sharing expenses can make Sun's $1/cpu-hr a bargain; depending on your utilization. The value is only further bolstered by a substantial investment in high performance infrastructure like the IB network.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/q_sungrid_cheaper_than_beowulf

At Sun, we have long predicted the impending doom for systems that are often termed Generation 1 (G1), or as I call them, “linear architectures”.... systems that are wholey built from a traditional 2/3-tier architectural approach, in which all elements of the presentation, business and data management layers are solely constructed for a single application, not built for “sharing”.

For many reasons, G1 systems and approaches, have continued to have longevity, why won't they continue? For we have been using the same system paradigm since the mid-70's, a continual drive towards commoditization and manufacturing has thus far survived major disruptions.

The shear speed and power provided by the network of connected computing resources is seeing a shift in the paradigm from the network as a data transfer media, to the network as a fabric for the execution of complex distributed services. This is perhaps arguably one of the challenges facing our large scale SMP product line (but we're not alone in this challenge - IBM's Mainframe line is really having some challenges).

The problem that is becoming more apparent is the exponential complexity introduced by a complex Service Oriented Architecture (loosely coupled coarse/medium grain just in time compositional systems) when architected using the mechanisms traditional to G1 systems.

An example of this fractal complexity:

Company A including a service from company B in their SOA. Company B then compositionally includes services from C to complete, perhaps w/o A's knowledge, what happens if C uses the same service from A...

At best this means that identity and privacy need to be further protected, at worst we may have a re-entrant/recursive execution problem (yeah single box threading can be hard, but network threaded apps where you don't have control of the components or sourcecode?), or “ilities” problems as the G1 paradigm typically does not find the need to elaborate security, scalability, availability, manageability models as part of the core design since each “tier” is typically fully characterized only for use by the preceding component: “the EJB's only get called through OUR Servlets” or “the DB is only accessed through OUR EJB's”.

With the movement toward component compositional models, SOA's, and Grid computing we begin to realize that a new paradigm is afoot - both with it's challenges and advantages:

What are G.next's core challenges:

• fallacies of networking
• network “enforced” isolation through distribution
• contiguous system memory vs. distributed memory
• service operation model & recognition of partial failure
• federation of core “identity services” including identity, context/role, entitlement

But it carries substantial advantages:

• differentially granular and dynamically scaled systems
• ability to take advantage of locality / proximity in execution
• dynamic parallelization of workflow
• ability to version/add functionality (carefully) in-vivo
• declarative security levels and well known enforcement models
• enforce isolation rules / best practices through interface “encapsulation”, resource management and controlled access

What are some of the major trends that I forsee needing in the construction of G.next based systems:

1. Majority of time in planning and assembly vs. iterative contstruction
2. Improvements in model annotation to capture systemic qualities and referential patterns (micro-architectures) so that non-functional behaviors can be better understood
3. Declarative models vs. code (though pseudo code could be used for declaration for rich syntax)
4. Federation of core services ( a core tenant of SOA that many forget!)
5. Ability to deal with distributed & distributable data
6. Append only / constant query data models (fail in place, recover from clone)
7. Omnipotent debugging, AOP and debugging languages like “D”
8. Systemic (compositional) SLA managment ... what is possible & what is desired
9. Micropayment environment to allow for “for fee” SOA services
10. Fine grained identity & entitlements to allow for security level agreements w/ tooling

More later!

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/requirements_for_architecture_next

I've been sitting on an article for a little while (4/18). I just found it refreshing that a journalist finally said something that made sense in explaining today's corporate buying & investor strategies.

“the industry is on the cusp of a sweeping change to new information technologies such as true mainframes-on-a-chip, Web services, and open-source software... Everything we talked about in the '70s, '80s, and '90s -- putting together clusters of PCs to replace big machines -- is finally happening.”

And finally a statement that I fully support...

“The fact that the next generation is less expensive does not mean that growth disappears. If you wind up uncovering significant new ranges of applications and you end up deploying them far more widely, you're going to dramatically expand digital services.”

Permalink Comments [1]
Trackback: http://blogs.sun.com/dhushon/entry/the_old_it_is_dead

A large number of people have been telling me over the past weeks that they cannot see their workloads shifting outside the “protected” four walls of a corporate data center. To that I respond, are your four walls really that protected, I mean most corporate Intranets are little more secure than the social engineering that continually compromises them; take the ChoicePoint incident for example, which had no hacking involved.

The question I really ask: are you so sure that you cannot better manage corporate/state/local/federal policy through contracts? to companies who make isolation, and enforcement a priority because of their multi-tenant nature? Just take for example an apartment building, where the common areas are secured to protect the dwellers despite the fact that some dwellers may not lock their own doors. For tenants who do lock their doors, the exterior doors add an additional layer of protection, under specific contract with the condo association. - Just a thought!

I then moved on to a review of Tom Friedman's new book “The World Is Flat': The Wealth of Yet More Nations” In this review by Zakaria he relates a section of the book that really typified why I think that multi-tenant utilities, like Sun Grid will inevitably have the loads to make them work:

Jerry Rao [an Indian entrepreneur], explained to [Tom] Friedman why his accounting firm in Bangalore was able to prepare tax returns for Americans. (In 2005, an estimated 400,000 American I.R.S. returns were prepared in India.) ''Any activity where we can digitize and decompose the value chain, and move the work around, will get moved around.

specifically that where there is a need which cannot be met with existing resources: financial, staff or other, then innovation will naturally fill the demand. These disruptions/discontinuities where new processes so fundamentally shift the economics vs. the old businesses, it becomes easier for people to recognize that changing, and in some cases standardizing is worth it!

My copy is on order, can't wait.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/disruptions_and_discontinuities

I'm beginning to think that the software development community can benefit strongly from the innovations that have taken place in the Electronic Design Automation (EDA) world over the past 10+ years - specifically in re-use, process and in declarative models like VHDL (including a repository for free componentry). What is very interesting is the strong use of meta-models, very UML like, but obviously inclusive of systemic models/annotation - in the case of EDA, thinks like heat, power, timing that translate well into enterprise development to systemic characteristics like security, availaiblity, scalability which allow us to take micro-architectural patterns an annotate them as componentry which can then be assembled, verified, synthesized and planned.

Another interesting element, that most monitoring this community have seen is an increasing recognition that IP not invented within corporate 4 walls is okay, so long as it can be successfully integrated - which at times can be challenging:

EETimes.com - IP assembly represents a sea change in the design of ASICs :

“This has led to the rise of a new term to describe ASIC design: IP assembly. The suggestion is that ASIC design now is different in kind from the days when we wrote new register transfer level for everything. Instead of designing, we are assembling prefabricated blocks into new configurations.

Somehow, the word doesn't match reality, though. A lot more goes into producing a working, yielding SoC than just putting things together. Not the least of the efforts is in creating new blocks to implement functions that aren't available as needed from the internal and external IP worlds. But the amount of work in ”just“ connecting the dots-floor planning, interconnecting the blocks correctly, placement and routing, timing, signal integrity and power closure and rule checking-can be huge. It can also require considerable creativity. And no one, other than an IP vendor, has suggested that employing existing IP reduces the verification task in the least.”

That aside, I think that SaaS and modular software approaches are following this trend, especially with the move to virtualized infrastructures and utility models. I have spoken before on Intellectual Capital marketplaces for software components, and think that we should look to the IP foundries, communities for IP sharing, and customizability for IC componentry as we as a software IC cottage industry execute on our plans for SaaS on a Sun Grid substrate.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/software_development_process_parallels_in

I was sent a presentation this morning outlining some of the various approaches proposed within the WS-I community for Service Oriented Architecture (SOA) service interaction. And a few of the graphics just jumped out at me:

I find it remarkably amusing that the notions of “registration”, “discovery” and “binding” are so challenging for the industry... we were doing this with CORBA 10+ years ago and a full 7 years ago with Jini. What am I missing, is it just the need by competitive marketing groups/pre-IPO's to re-name things just to get funding? I just feel like this is a NIH problem, or worse that some competitors wanted to introduce discontinuous technologies so that they could fill the void. Even Adam Bosworth , who ran in that crowd for a while, points out here: (thanks Simon)

'Vendors such as IBM and Microsoft, in proposing the standards, were big, institutionalized companies trying to protect themselves, [Adam] Bosworth (formerly of BEA and now a VP at Google) said. “They were deliberately, in my opinion, making something hard,” he said, citing specifications such as Web Services Reliable Messaging.' InfoWorld

With the simple use of proxies/stubs (which of course, can be dynamically generated) we eliminate the need for intermediate message formats, with leasing we pick up dynamic binding and as a plus, can get resource management, and with Jini Transactions and Spaces, I get the ACID properties... and put the control of recovery back where it should be, with the calling (initiating) service, and without a “required” coordinator I can drive to distributed/peer oriented scale. What the heck am I missing, except the fact that everyone thinks that Jini, by default = Java and RMI?

And now let me really get up on my stump... language neutrality vs. platform/protocol neutrality.... why the heck should we use a description language to write code... even business code. There are terrific code generators for Java, moving from UML! Do Microsoft and IBM think that we, as a developer community, are that nieve?

A colleague of mine, Murali pointed out there there is little new ground in the WS space, but it's still popular because, let's face it Java isn't interoperable. I suggest that there are people who didn't want to be wrong in their dismissal of Java and Jini who now must invent their own “versions” of this venerable technology... let's just take a look at a problem decomposition solved by WS and by Jini:

So what's the hitch... Murali suggests “The fundamental thing we need to do is to externalize Java objects into a compactly encoded binary XML, through serializers with FastInfosets and JAX-FAST implementations. We then need to implement SOAP messaging within JERI, to provide pluggable transport. Then it doesn't matter what platform the service-endpoint is or how services are invoked. You have the best of both worlds: JINI and WS.”

We can soon prove to the WS-I community, neigh, the developer community at large, that its a lot easier to discover and reuse interesting services within this platform as opposed to wasting time in politicized standardization efforts. Furthermore, recognizing that more homogeneous environments wouldn't have to take the lowest common denominator approach; would allow us, as a community, to create hugely performant and well behaved service oriented networks.

Oh well, Tim, count me into the Illuminati, the Loyal Opposition!

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/like_old_wine_in_a

We are now experiencing a drive toward a commodity “Network Operating System”, the next step in technology assisted computing environments. The knowledge that we have driven a huge amount of cost out of the hardware puzzle through a market move to commodity x86 based systems, but what is really next, it's gotta be the Operating System, and the software to manage a cluster of systems, what I'm calling the NOS.

So I talk about the need for a Network Operating System, what do I mean... we'll let's look at what kernels typically do: Process Provisioning (in isolation) and Management, System Resource Management, Inter-process communication enablement, Fault Management and Recovery (abstraction for user level processes).

Some in the Jini community like Gigaspaces (where my good friend Dennis Reedy has just taken a leadership role), Paremus, Intamission, and even open source projects from the community itself like Project Rio and even these tutorials on JavaSpace based worker patterns attrib. Tom White

are working on workflow scheduling & distribution models, and more dynamic resource management techniques. By and large these companies have been relatively successful, but still lack the excitement that I think that they deserve. Causes of the lack of excitement/broad adotpion can be traced back to a couple of things (misconceptions and misgivings):

Misconception #1: “Jini, isn't that a technology to connect networks of devices”
Yes, sure, but what is it about networks of devices that are shared in a global computing grid... Peter Deutsch's fallacies, and a intrinsic knowledge that the network will change, participants in the network will change/fail, and that the environment must tolerate these failures in a consistent and graceful way.

Misconception #2: “Jini is reliant on RMI/JRMP as it's protocol and RMI/JRMP has problems in big networks, across firewalls, etc...”
I'm first going to point you at this article by an esteemed colleague, Dr. Jim Waldo, basically any Java system can use RMI/JRMP for Remote (to the current VM) Method Invocation, but, and a big BUT, Jini uses proxies & proxy code to interface between services, and the interface/protocol that the proxy exposes is up to the developer. Sure, it's easy to allow the proxies to rely on RMI, but it's not required. I've seen proxies that leverage JXTA, I've seen CORBA bindings using IIOP, and of course there is a cottage industry in over HTTP/SOAP and WS interfaces across the Jini community. Besides there are existing capabilities that enable tunneling of core Jini services across firewalls and networks: Lincoln Tunnel.

Misgiving #1: “Jini is a technology that Sun has abandoned?”
Hunh Scooby. Okay so Jini hasn't become a mainline infrastructure, yet, but it's darn sure getting there. Jini is the core backplane for our RFID event manager (graci Larry Mitchell), it's been furthermore re-released under the Apache License v2.0, we continue to actively support a large community of developers, and there's more that I cannot talk about ;).

Misgiving #2: “Most of the companies with commercial projects are small, and require substantial changes to existing infrastructure to implement”
Yes, BUT the value of re-factoring the problem impacts the scalability, availability, developer productivity and other aspects of the core - I hate this term - middleware infrastructure for segments of the system. Most companies that I have consulted with are incrementally phasing in Jini, and others like Orbitz are moving business critical functions.

So what is it specific to Jini that get's me going?

Lookup and Discovery

• allows for decentralized lookup, and ability to provide federations of federations in order to help with “local maters” and provide for “best fit” resource management and scheduling.
• Leasing Models match very cleanly with resource management
• cancellation of Leases aligns well with both prioritization, graceful degradation, contention and distributed partial failure

Distributed Transaction support

• most people today rely on Message Oriented Middleware (MOMS) to provide reliable workflow despite the penalties paid for normalization, bussing, queuing, etc... obviously new breeds of MOMS are emerging with peer messaging, but still these mechanisms rely on the message or infrastructure to cleanup when there are problems rather than the calling service - where the failure recovery models are more appropriately managed.

JavaSpaces

• when we do need a shared memory space for optimal information distribution (as many Highly Parallel Application Grids do) JavaSpaces provides a very simple distributed worker model (see Tom White's article above).
• Javaspaces furthermore scale extremely well, and the pattern is quite fault tolerant

I just want to wrap up with an interesting and yet older article by Peter Coffee on the need for distributed control within IT.

Mark my words, Jini's day will come!

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/jini_and_the_nos

Obviously critical to Sun Grid's success is the ability to support transactional applications on the compute farm. Though the core economics of a Solaris 10 cpu at $1/cpu-hr are best in class (versus $7-$14/cpu-hr for many self hosted enterprise environments), who would have thought that the economics could get even better so quickly. Today, Sun announced couple that with some recent performance benchmark figures from our Java Application Platform:

“The benchmark configuration was comprised of 13 Sun Fire V20z servers, each equipped with two AMD Opteron processors Model 248 and running the Sun Java System Application Server 8.1 Standard Edition. In addition, a Sun Fire E2900 server, equipped with 12 UltraSPARC IV 1.35 GHz processors, ran the latest version of the Oracle 10g Enterprise Edition Database.

The benchmark delivered a class leading price / performance of $164/JOPS in the application tier (combined software / hardware and support cost) versus IBM's best submission of $504/JOPS(3). This translates to 90% of the performance for 33% of the total application tier cost.

The benchmark also demonstrated Java System Application Server's ability to handle complex workloads under very heavy load. During the benchmark, the Application Server supported over 9400 concurrent clients, and processed over 4.3 million complex transactions per hour.”

Wow! combine this with the reduced cost and complexity associated with a unified development, test to deployment model in which the integrity of the “digital runbook” is maintained, and people should start to ask not IF but WHEN refactoring for Sun Grid should occur.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/application_containers_cost_per_transaction

In the past I've talked about the need to enable a new development model... something in which the agility is shared between the developers and the IT department. Recently I read this article on a move toward ASP's and the inherent pace that can be achieved where an ASP is the software companies primary target:

BeyondVC: ASPs/Service Providers:

“In the time it takes Microsoft to deliver an application (went from 1 year to 5 years), a company delivering software as a service can deliver 60 iterations of its product. As Adam points out, ”things that breed rapidly more quickly adopt through natural selection to a changing environment.“ I have never thought about software in evolutionary terms, but it certainly makes sense.”

This really brings home some of the key points around the ability to create agile business processes, through an evolutionary approach and constant refinement. One thing that I think that a utility centric approach to development in which the develop->deploy paradigm is both iterative and shares a common runbook is the ability to “try things out” and have the digital runbook (the functional and systemic design for a production system - like our N1 technology enables) become aware of successes and failures. This builds upon the patterns and micro-architecture work done by the patterns community, but adds a learning path which allows knowledge/experiences to be documented and preserved - not in the developers per-se, but in their annotations within the design.

I think that one of the things that may be holding some developers back is the fact that their development environments are frequently substantially different from their deployed environments... something that I think Sun Grid has the opportunity to change... why not instantiate a developers instance(s) of a web server (ours, theirs, open - whichever containers have deployment plans for the Sun Grid), app server (ours, theirs, open...) and db container(s) on the grid, attach to it from Java Studio Creator... do intial development, and gather statistics. Begin to instantiate additional elements of infrastructure: identity, entitlements, logging, firewalls/packet filters as development progresses using your corporate runbooks to find deployment errors early, gather statistics, fix incompatibilities and re-factor as necessary to make optimal use of environment... and so on until you have a system.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/evolutionary_software

I found this really interesting article on Software as a Service (Saas) and how enterprises are adopting Utility (standardized software for whose demand is aggregated by a service provider for economic efficiencies):

A field guide to software as a service | InfoWorld | Analysis | 2005-04-18 | By Eric Knorr,Leon Erlanger,James R. Borck:

“But an urgent need to stop piling cost and complexity on IT is sowing the seeds of change. Although enterprises may not be replacing effective, large-scale systems with SaaS alternatives, the SaaS option suddenly becomes perfectly viable when it comes to adding new functionality. And, as Salesforce.com discovered, SaaS can be particularly successful at replacing in-house or off-the-shelf software that has failed miserably.”

What is exceedingly interesting to me is that there is a continuum that I have been experiencing over the past couple of years:

Round 1/Year 1: “Time to cut costs”

Customer recognizes reduced budgets and begins process of reducing costs

• Path 1: Outsource non-critical/ segmentable application to outsourcing provider
• Path 2: Move toward consolidation (simple) of compute and storage resources within similar classes of applications starting with non-business critical applications

Outsourcing works for first year (the true benefit year) and then change costs, and delivery cycles which although contractually committed/agreed become to stiff to allow for business agility for certain business functions
Initial consolidation does reduce costs from operations / expense from acquisition by 15+%, and outsourcing benefits are realized for most customers

Round 2/Year 2: “Time to re-evaluate strategy”

New controls negotiated into existing outsource contracts Consolidation recognizes need for improved Operational Readiness / ITIL / Process & approach standardization and moves forward only with support of business customers
In return for standards based approaches business customers begin to demand detailed metering to better understand the true cost of IT to their business
Business and IT collaborate on approach to decrease variability and the huge costs associated with customization

Round 3/Year 3: “Increased appetite for standardization”

Businesses recognize that their highly customized business processes come at a price both real (time-to-market, expense, and revenue) and regulatory pressures force upgrades ? “is the time right to re-factor our business?”
Anicdotally: in a recent meeting between a handfull of CIO's, one brought up “has anyone been able to implement XYZ - large enterprise package here- on time and on budget?” “nope”, “nope”, “nope” so what are we doing wrong?

• “Meta Group claims failure rates [for CRM projects] of 55% to 70%; studies show that customers don't want more choices.”

SaaS seems to be taking off if you look at the growth of ASP's like Salesforce, Oracle-On-Demand, and other ASPs
Elaborate a strategy taxonomy for enterprise applications based upon a basic taxonomy: Custom Apps, Custom applications on compute/net/store consolidated platforms, Standard apps on fully virtualized platforms, Standard apps on utility models.
Start talking to IBM, HP and Sun about their Utility models, and Business Grid technical approaches...

One big question invariably arises: “How do we keep from doing this to ourselves again?”... answer of the day seems to be SOA, yet another acronym to solve all ails, but to me this just addresses a part of the problem... like saying that “standards will enable a complete solution to interoperability”. I think that there is actually an ecosystem change / play afoot which is very interesting... similar to the well recognized “getting Amazoned” moving toward “getting googled” (becoming inadvertently marginalized through a loss of direct relationship with a customer because of a competitors ability to offer aggregation and mass-customization at scale) we begin to see defensive plays being forced on businesses to enable improved agility only afforded by economies of scale. I've got some ideas in this space because in fact explicit collaboration between developer/BU and IT becomes a key factor in success. And I'll elaborate some of my ideas around the role that a properly architected utility ecosystem can play in bridging the gap in the next couple of days.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/trend_toward_software_as_a

So this recent article on how Outsourcing is changing got me thinking about how different utility computing is from outsourcing - though many try to place them in the same buckets.

Financial Differences:

1. Transparent usage based pricing (come on Sam P.)
2. $0 commit contracts - Incurred business/financial liabilities
3. Shortened cash conversion cycles if expense can be directly tied to produced revenue in same period...
4. No pre-provisioned assets which whether in-house or outsourced drives some expense back to business
5. EA Sports launches new game, typically ramps up infrastructure 6mo ahead to ensure that it run's at scale, they then incur the expense no matter the revenue. With Sun Grid, they incur some cost to test at scale, develop performance policies, and then as load ramps up = expense, so does revenue.
6. Economic advantages can be re-invested for application re-factoring/tuning for improved out term (based upon term of ROI) advantage.
7. The same is true for outsourcing, but change fees and potential for penalties typically make this model substantially less attractive
8. Fine grained financial control (over time to the transaction level); which allows better accounting - is this business worth doing based upon cost vs. margin? most IT departments and Outsourced contracts are too coarse grained to provide this information back to BU.
9. (scary) futures markets, hedging/speculation

Business Models Enabled:

1. New business opportunities emerge around “intermediation” - disinterested 3rd parties that clear transactions = “market makers” in areas of healthcare txn clearing, intelligence sharing, transaction aggregators
2. Subscription based software (software as a services - saas) - digital business processes monetization e.g. Salesforce.com and Salesforce.com.next where the process owners may not own the data, but the processes (see ILM below). This, by the way, is estimated to be an $8B business by '07 per IDC.
3. ILM, leverage shared global namespaces and meta-tagging to evolve a HSM strategy inclusive with archival partners (best in class) - potentially allow users to “own” their own data... e.g. I want to have control of my own financial, healthcare records, and don't trust my doctor/healthcare payor to do it on my behalf. And what about “personal archival storage” - identities, licenses, photo's, videos, music, critical digital documents.
4. Make money from contributed IC... component ecosystem
5. Make MORE money from invested capital (power production) or invested intellectual capital (harnessing produced power with know how) due to multi-tenancy = volume/scale

Operational Efficiencies:

1. Multi-source, contingency/DR planned across multiple sites
2. Servicable within an existing data center - take our Sun Grid patterns, become certified, offer excess to community for profit (improved cost profile)
3. access to IC/best practices and core facilities around both the standard offers, and through CSO for custom implementations
4. customer has ability to build a site/pod to our specification and “sell” unused cycles back to the grid once “certified”
5. increased ability to apply policies to workload management
6. customer can scale internal workloads to the grid (peaking capacity)
7. Choice with control - can engage on grid at multiple levels depending on appetite for management and standards, can furthermore extend telemetry and control differentially to feed back management information to end customer for management purposes.
8. Can be used by CFO/CIO as drivers to a consistent enterprise architecture w/in a company
9. Fine grained metering can help BU's better control costs... if I know the cost of a txn, can I better judge whether this transaction is worth tuning or even doing?

Developmental Improvements:

1. Perfect platform for open source development and support of developer communities (keep each developer's environment consistent) = lower complexity, inc. productivity.
2. Collaboration network to allow for shared code development (e.g. outsourced development) using a “dis-interested 3rd party” to host the environment
3. Have platform for systemic test at scale (ability to leverage deployment plans vs. pulling cable to re-factor core infrastructure)
4. Multi-tenant basis of Sun Grid is equivalent to isolation being looked for within Corporate BU's for next step in consolidation
5. Secure platform for SOA provided by Sun Grid Federated Identity, and Entitlements systems - choice with control
6. Access to tools such as SALSA for improved architectural control in development projects (SALSA is a pattern recognition and enforcement tool that helps to ensure consistent enterprise architecture pretenses are maintained, but it takes substantial resources to run) - yet another development service on Sun Grid.
7. Component ecosystem - free/fee componentry from base services, to service aggregates - creates “market” for components and business processes that are orchestration models through a component “vending machine”.
8. Tooling for business developers including “wiring” tools to orchestrate business processes across an Adaptive SOA
9. Tooling for workload analysis to allow for “best” provisioned resource(s) - splitting job flow across pods of different types e.g.Niagra(tm), Opteron(tm), SPARC based upon “best executor” and interconnected by high-speed mesh (NUMA backplane). Check outAndy Ingram's work on workload analysis

IMO, we just cannot get away from the fact that outsourcing contracts & providers will typically invest in the lowest cost of service to enable an SLA (whether it's well written by the customer or not because tradeoffs cannot be made accurately a priori (see JPMC and my response - “yeah right”)). Benefits to outsourcing, typically financial contribution in year 1 with downstream being less lucrative for the business - after all, someone does have to pay. Benefits for Sun Grid, typically start in out months/year due to start up/Non-Recurring Engineering costs, but downstream can be substantial -> small depending on customer choice to re-invest dividends and cost of their IT today. Outsourcing seems to be a CAPEX/OPEX driver, but Sun Grid can also drive revenue opportunities because of open-market & community nature of ecosystem that we need to construct. Will there be a market for highly tuned financial instruments that an individual/company can use to offset development/support costs? can you do that with outsourcing? Here's for cheap, with choice, and control!

In short:

Outsourcing.isVeryDifferent(new SunGrid()) == true;

Permalink Comments [1]
Trackback: http://blogs.sun.com/dhushon/entry/sun_grid_outsourcing