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

In it's most basic form, Utility Computing is yet another cost cutting measure of helping an IT reduce it's cost of service; both current and future, at today's scale and tomorrows. But, quite honestly, there's a top line benefit to go along with the bottom line benefit... the top line is represented by a utility community ... a Co-op in typical energy terms where a variety of participants can “add value” to the collective, and the collective is enriched by the the value of the collective whole.

I'm really excited about the opportunity for Sun Grid to establish a network where components representing Intellectual Capital can be established, to finally create a “capital market” for software..

Think about it, what represents a capital market:

1. There are instruments that have inherent and stable value
2. There is the enduring ability to exchange value for value across instruments
3. There is a permanent marketplace / exchange that is a designated place where people can go to exchange value.
4. There is sufficient fluidity in the market to allow the market to be established and maintained

(attrib: hal stern)

Recently (well in March), we established our intent to create Sun Grid Utility Compute and Storage cycles as instruments for exchange with our partner Archipelago Holdings, and this is massively exciting because it just breathes of transparency just like any other commodity market.

So back to Sun Grid, we were talking about Intellectual Capital, represented in components, stored in Sun Grid's asset manager, and properly meta tagged for use by developers. When these components finally become commonplace, I'd expect the best components float to the top and make a lot of $, and the worst components just sit gathering dust in the asset repository until they are aged out of the system. I can even see competitive exchanges for components at development time - finally compete on implementation vs. integration, and eventually even move the components upstream to include entire business micro-processes... things that vertical markets may need, to comply with specific state/local/federal/international laws, but for whom the market was to small for a “software company”; but with a fully automated exchange for value, these processes can afford to be maintained (I'll elaborate this more later because I think that it's potentially the most exciting paradigm shift enabled by the Sun Grid.

'Night!

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

Here are what a couple of sources say about “utility”:

Investopedia.com's definition of Utility

Textbook Definition

1. An economic term referring to the total satisfaction received from consuming a good or service.
2. A company that generates, transmits and/or distributes electricity, water and/or gas from facilities that it owns and/or operates.

Investor's Definition
1. A consumer's utility is hard to measure. However, we can determine it indirectly with consumer behavior theories, which assume that consumers will strive to maximize their utility. Utility is a concept that was introduced by Daniel Bernoulli. He believed that for the usual person, utility increased with wealth but at a decreasing rate.

Hushon's sidebar: actually Daniel Bernoulli is looked at as having provided some key risk management approaches still used in game theory today.

2. Since consumer demand for utilities does not change dramatically with a change in price, these companies are regulated by the state or provincial and federal governments.

So, you may ask, what does this mean to me, we'll let's just say that utility is a measure of the value that a given good yields upon consumption, sounds fuzzy - “I'll know it's valuable when I see it” kinda thing, but it's really moving back to a definition that reads something like “worth more than it costs”.

The only problem is the fact that most of our traditional utilities are regulated, whereas we look at commercial software and hardware vendors as an open capital system. Okay, but, isn't the open source / community source movement actually something of a regulatory movement? Is the term “commodity provider” actually one that denotes a high degree of standardization that resembles a regulated system - much like Bernoulli actually said that “people do not maximize expected returns, but expected utility”? Either way, I think that we all agree that IT's “utility” or “value add” will be hard to measure, and even harder as we WORK to actually standardize as much of our compute plant as possible.

I, personally, look at activities like ITIL as being very similar to what we are trying to achieve on the IT front, and what is most interesting is that movement of ITIL toward standard pattern based approaches to process architecture, much the same way that we are discussing pattern based approaches to service and system architecture. Also interesting is the fact that ITIL has been strongly embraced by both the technical staff ala. systems administrators to provide them a more consistent approach to building out and managing technology based systems, as well as by the business staff, for whom the vocabulary, standard definitions, and sequences provide a language through which the two often distinct camps can effectively collaborate. I elaborate a bit on these issues in this two part series 1 and 2.

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

The Graduate, 1967

“Mr. McGuire: There's a great future in plastics. Think about it. Will you think about it?
Ben: Yes I will.”

Now that I have introduced the terms (Grid and Utility) that I will attempt to use consistently; I would like to elaborate some of strategy for Sun's approach to Utility Computing. Namely, Sun Grid is a family of utility oriented offerings that enable consumption based charging with multi-tenant economics, on top of an infrastructure that uses automation instead of people to reduce operating expense.

It should be obvious to anyone who has read Greg P, or Jonathan's Blogs that Sun is a) pretty serious about utility and b) that we feel strongly that this approach to utility services offers some very exciting possibilities wrt. emerging new business models.

1. services augmented by utility delivery
2. services built for utility delivery
3. services made affordable, scalable, trustable through utility delivery

Overall, for the smaller developers, the underdogs, the use of utility scale with as-you-use-it pricing is a great leveling factor. In the world of Online Gaming, for example, how does a small “in our garage” shop possibly compete against the resources of Electronic Arts? Simple, build using open/community source codebases, leverage a ubiquitous client-side language like Java, and then target a expense oriented vs. capital oriented deployment scenario where commitments to acquire resources (incurring of expense) are aligned in a very fine grained way with the generation of revenue... in affect creating a near 0 capital investment model, while matching revenue to expense in a cash flow positive way.

The business models are quite exciting, and I'm very interested in your comments here.

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

For those of you that don't know me, I'm currently Chief Technologist for Sun's “New Economy” properties that include our website, developer/collaboration sites, the Sun Store, Sun Reman, Sun Grid, and our financing business.

One of my primary focusses, to date has been driving our Sun Grid program. And let me start by saying that the term “Grid” is as overloaded as the setDate() function around y2k... it means so many different things to different people.

Being an old Inmos Transputer guy, working in OCCAM building MPP systems for ASW work in the 80's, we built real “deterministic” processing grids then (the grids were largely an artifact of the fact that the processors of the day were so slow that we couldn't process the volume of data in real time). Now what we really have are computing farms which are tremendously performant, which differentially map compute, networking and storage resources, as dynamically bound entities(abstract or concrete), to provide optimal execution structures for business processes, and parallelized and/or serialized algorithms.

So let me take a quick moment to elaborate my definition of Grid and Utility that I will use moving forward:

Utility - largely a business/financial model based upon the notion of just in time shared demand/load aggregation model that allows a providing entity to deliver more compelling economics based upon multi-tenancy (dynamic capacity stacking) to allow more efficient use of capital assets. Specifically, a utility is marked by:

• Technologically complex but simple at point of use: plug & play
• Standard: you know what to expect
• Reliable: always available,
• Scalable: use as much as you want when you want
• Multi-Tenant: enabling demand aggregation for economic benefit
• Metered: transparent units of measured usage

Grid, on the other hand really represents the technical approach which allows for the pooling of resources in logical groups to enable the just in time connection of right-nodes in a way that composes systems based upon the systemic needs of an application (often marked by virtualization and abstraction of resources and then dynamic mapping, based upon a declarative model of the needs of software against the capabilities of a composed platform (attribution: Dennis Reedy, one of the founders of Project Rio).

I really like this definition of Grid:
“Resource sharing and coordinated problem solving in dynamic, multi-institutional virtual organizations” (Ian Foster)

In effect, Scott McNealy's Big Friggin Webtone Switch

Gotta like this picture of the BFWTS

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