So as you can see we'll be kept too busy to check out the post-war architecture which makes Rotterdam such as fascinating place. Imagine for a moment rebuilding an entire city in the 3 decades of the 1950s-1970s. What would you come up with?

Pity we can't start building a modular cloud application architecture on such a green field site. Hybrid on-premises/off-premises applications architecture will forever be a reality for enterprises. Some organizations are unwilling or legally not permitted to host every application and its data in public or external clouds. The typical chaotic and brittle applications architecture found in most organizations means that a significant fraction of existing applications are not ready to move to the cloud.

We have a very limited number of free guest passes for the conferences still available, each valued at 1,090 Euro. If you’d like to attend the conference, leave a comment on the blog, and I'll get back to you. Once the passes are gone, we can still offer a 25% "friend of the speaker" discount.

August 13, 2009

When considering Cloud Computing’s impact on application development and architecture, I have continually asked my team the following questions:

What is unique?

What is new?

How does Cloud Computing change application development and application architecture?

Existing Cloud Computing's momentum is predominantly focused on hardware optimization (IaaS) or delivery of entire applications (SaaS).Building momentum for Platform as a Service (PaaS) has proven trickier because many 'old discarded practices' are being rejuvenated, skepticism abounds, and developers are focused elsewhere. Does current day technology, new products, and accepted culture mean that Rapid Application Development (RAD) environments and Fourth Generation Languages (4GL) will be accepted by mainstream developers? Some proponents think so, others feel like Bill Murray in ‘GroundHog Day’ and wonder ‘why will the concept work this time?’

Interest in Cloud is providing an opportunity to re-think the application platform, review vendor messages (e.g. Google, SalesForce.com, LongJump, Bungee), and determine how application development and application architecture should morph to support Cloud benefits and characteristics.

A recent newsgroup thread discussed how Cloud will impact programming models. A focus on 'programming models' is a red-herring.The best 'programming models' innovations are unseen and instead rely on inversion of control and/or container-based interception.Vendors are extending infrastructure containers and frameworks to transparently support improved dynamic virtualization and more flexible topology distribution (hopefully without new APIs and languages).

But what is new today? As Greg Pfister states in his post, technology concepts such as virtual containers (e.g. Java JVM and PHP interpreters) and decoupling from operating systems and hardware (e.g. java bytecode) have been around for quite some time. Additionally, 'inversion of control' (IoC), 'configurations instead of code' (EJB3.0 annotations instead of java interfaces), and declarative languages (e.g. XAML) are also well established.

But has the infrastructure evolved to transparently realize elastic scalability and optimize resource allocation? or, do developers need to program to the Globus toolkit, .NET WCF, or Force.com APEX?

A straw-man use case is "Can Cloud infrastructure inherently support elastic, scalable, and resource-friendly execution of Plain Old Code Object (e.g. Java POJO, C# class, Tcl script)?" GigaSpaces is a good example of a product enabling more seamless Java code scalability and lower resource footprints when compared to traditional application servers (e.g. IBM WebSphere, Oracle AquaLogic). Another example, code written in C++ which interfaces to the Win32 or LINUX internals is often tightly coupled to hardware, does not following 'service-oriented design principles' (i.e. loose coupling, separation of concerns, interoperability), and may contain single points of contention(e.g. synchronization points, resource locking). The application either doesn't support parallelism, or supports parallelism single machine specific manner.

A Cloud-friendly application supports dynamic deployment of modular components. Picking up and moving a C++/Win32 application to another machine requires moving several operating system resources (e.g. memory, file handles, threads, inter-process communication objects). Decoupling resources behind a service interface is a more Cloud-friendly best practice.

<>A few use case suggestions:

If end-users rely on Software as a Service, then their development environment must support service interactions and corporate infrastructure policies (e.g. security, reliability, availability, performance) should extend beyond their internal data center and span external service providers. WS-Policy based specification standards are a step in the right direction. Policies must be externalized from application code to enable more distributed infrastructure decisions. Following JSR250 and embedding security policy within Java code doesn't facilitate communicating the security policy statements beyond the JVM environment. You will find numerous examples of both .NET attributes and Java annotations which are deployment infrastructure descriptors. Embedding deployment details in code is an inefficient programming model and not Cloud-friendly. The application design technique often breaks the service-oriented concept of 'separation and concerns'.

If end-users rely on IaaS to deploy applications, then having more insight into the application footprint will enable more intelligent resource allocation decisions. Slimming down the application footprint to handle a single unit of work will enable more requests to be packed into a machine.

August 10, 2009

For the last year, the SpringSource team has been intently focused on bridging the gap between development and operations. The team has also been moving quickly to re-tool their platform to become a Cloud-native. Cloud-native platforms are built to exhibit cloud computing characteristics (i.e. self-service, elastic and scalable, virtualized, and dynamic) compared to the 'earthborn migrant' runtime stacks which are simply traditional application platforms hosted on cloud infrastructure without application container and framework modifications.

Cloud-native platforms enable users (including non-developers) to customize pre-built templates. They offer abstractions for workload granularity that lighten the developer’s burden for many scalability and operational concerns. While Cloud-native platforms will attempt to transparently address scalability and elastic provisioning/de-provisioning, the platform will assume that an application is already horizontally scalable, or can be redesigned to conform to Cloud application architecture restrictions that facilitate a scalable solution. Moving to Platform as a Service forces architects to fundamentally re-examine their application architectures. Tackling parallelism and single points of bottleneck (usually database access) will become paramount.

With a new programming model, developers can approach solving problems that are resistant to traditional application architecture practices. Democratizing the process of building massively scalable web applications and delivering high-quality applications in a superfast time to market are two examples that are becoming mainstream concerns. SpringSource, a framework innovator, is well-positioned to address the programming model evolution.

March 05, 2009

In the economic realm, economists often refer to 'structural change'. 'Structural change' is when long-term game rules have been fundamentally altered, and truisms based on the old model no longer apply (e.g. 'real estate value never decreases', 'over the long term, the stock market always rises in value', 'my children will experience more opportunity', 'owning is better than renting'). If I propose economic and cultural aspects underlying the world around us are radically changing and old models do not provide good guidance, you may not be surprised. Because underlying economic mechanics have changed (i.e. investment yield,counter party risk, credit liquidity, personal consumption habits) economic bailouts based on existing models are not as effective (much to everyone's chagrin). We are forced to re-build the economy and meet new long-term realities imposed by structural changes that occurred during the last twenty years (i.e. financial industry market participation, credit expansion, credit risk management and hedging, asset valuation). To be effective, participants must recognize a new model is in force.

Shouldn't a structural change within Information Technology be recognized today? Cloud computing proponents think so... Disruptive forces (i.e. commoditization, tightening economics, industrialization, business practice acceptance, and a resurgent desire for trust and credibility) are creating a new reality. Organizations can abide by old model rules or gain advantage by adapting.

The normal IT response is to adopt an 'architecture bailout' focusing on products and technology. But many 'architecture bailouts' (i.e. Object oriented programming, Component Based Design, Event Driven Architecture, and Service Oriented Architecture) are pursued as incremental, bolt-on practices. Rarely do organizations transform people, process, and technology to match realities imposed by structural change. But 'What is IT Transformation Really?', Brian Watson of 'CIO insight' furthers the discussion with this call to action: "[Position] your IT shop as the “internal consultant of choice,” versus available consulting or advisory services". How many of us know 'the cost of compute hour', 'the cost of storage per GB', 'the cost of web service development', 'the cost of our application platform'? To determine which aspects of IT to shift into Cloud, we need to fully understand the economics of IT instead of architecture and technology.

Many Cloud computing messages target IT business model adaptation (i.e. pay-as-you-go, externalizing IT services, service consumption) instead of another architecture bailout (i.e. grid, virtual machines, autonomic computing, SOA). The conversation is shifting in the right direction, and Chris Howard is leading with research proposing a process to determine when to engage internal resources (core) or disengage the task and rely on external service providers in the Cloud.

Today's economic players are proposing a transformational response and stepping out of their comfort zone to lead. Meeting structural changes imposed by Cloud computing will require significant action by IT leadership. A recent blog post by Mike Rollings states an incremental responses will often be ineffective and leadership is a critical. Jack Santos has an excellent blog entry on leadership and collaboration (the embedded 2 minute video is uplifting).

February 23, 2009

When enterprise customers negotiate license deals with software companies, source code escrow agreements are commonplace. These agreements are three-party contracts between the vendor, the purchaser and a 3rd party escrow agent in which the agent stores the licensed source code, to be released if the vendor goes bust, or otherwise fails explicitly in its maintenance obligations (many shades of grey here!) I've been at companies that have had to invoke escrow terms to recover and maintain source code from a failed vendor. Of course, it's painful, but it's not disastrous.

We learned last week that Coghead, a platform-as-a-service (PaaS) vendor, has collapsed, citing difficult economic and fundraising conditions. Coghead customers have no such escrow arrangements. Far from it.

Customers should download their data that is available through my.coghead.com before 3:00 p.m. Pacific time on April 30th. However, Customers should not attempt to copy, modify, reproduce or reverse engineer any portion of the software that is part of, or used in the delivery of, the service.

(Extract from Coghead's "you're dumped" letter to its customers)

So all that development time, spent customizing UI layouts, workflows, business rules, and making integration work vanishes in a "cloud" of smoke. It puts a whole new spin on Fred Brook's concept of "plan to throw one away". Some Coghead customers will create better applications with the experience they've gained. But learners were not Coghead's core market. They were the DIY business person, the overstretched IT folk needing a solution for a quick situational application.

This post by former Coghead partner, Michael Topolovich, is an extended but fascinating view on the promise and problems at Coghead, and required reading for anyone on either side of the PaaS business. Apart from business execution problems that can sink any company, what's highlighted by Topolovich's post is the crucial requirement for a platform to have a thriving ecosystem of developers and 3rd parties. Topolovich's company, Delivered Innovation, is now offering a Coghead to Force.com migration special offer.

SAP has picked over the entrails of Coghead, slurping up IP and staff, but:

Why not support those customers? There seemed to be magnetism between SAP and Coghead, for example SAP Ventures participated in the 2nd round of Coghead funding and the companies announced a partnership 9 months ago. If I were both an SAP and a Coghead customer, I would be looking to SAP to provide some level of support, or at least a transition plan to a new platform. SAP could grab this as an opportunity, and a cheap one I'm sure, to bootstrap a PaaS business with a ready-made customer base.

This post isn't intended to be schadenfruende laden; innovative companies go bust for many reasons, and I am an advocate of PaaS for the right situations (more on the right situations later). My overriding recommendation is that if you are going to use PaaS, make sure you have an exit strategy. Rob Styles has practical advice for mitigating the development risk, which I summarize here: 1. Keep the application URLs within your own domain. 2. Take regular exports of your data 3. Make sure you can export the application to run on-premise in some form.

This ability, or lack thereof, to "download your application" is the crux of the risk around completely proprietary off-premises PaaS approaches like Coghead, unlike hybrid open/on-premise/off-premise approaches such a Google AppEngine and Microsoft Azure.

January 14, 2009

It's really difficult to be objective about XaaS when it seems that no matter what technical argument you can make against it is ultimately trumped by cost. Yet, look at the success of companies like NetSuite and Salesforce.com; how can you argue against the model with so many customers reaping value?

It's probably unfair to lump all "as-a-Service" offerings together
in this way given that each has pros and cons that are distinct. But, I've discussed the concept of business having a Neanderthal brain, and XaaS is a great example of that brain at work. Great technical positions regarding trust, data ownership, availability issues are responded to with the equivalent of "I'm rubber, you're glue, anything you say bounces off of me and sticks to you!" Even worse is the vendors playing the parental role in this childish repertoire scolding the technologists for even raising these issues; admonishing them for restraining progress and being blind to the eventuality of life in the cloud. The hard-sell, if ever I've heard one.

The good news is that none of the technical arguments cannot be overcome. Indeed, most of them can be handled through service-level agreements, legal contracts and the rise of domain-specific XaaS environments. Still, I believe, the ardent pushback to raising technical issues stems from the fact that XaaS providers have yet to solidify the business models underlying XaaS and fear rejections at this point that may shut off avenues of funding before they even get a chance to figure out how to deliver value and protect the consumer all at a reasonable cost factor that still delivers profitability.

In this CNet piece, "The cost of cloud adoption", the author does a great job of explaining the misconceptions regarding the underlying accounting principles of XaaS, without losing the value for business or the impact of running a large data center. But, this blog posting applies primarily to IaaS (Infrastructure) more than PaaS (Platform) or SaaS (Software). However, buying compute time is not a new concept. It used to be the only way businesses could afford to own a computer. Now, it's a realization that the cost of running a data center for even slightly above average utilization is not cost-effective. Moreover, the ability to scale on demand is very useful in shops that see spikes related to specific business-oriented milestones, e.g. end of month reporting.

So, where's the catch? Personally, I practically live out in the cloud now. I can set up shop at pretty much any computer and get to my email, feeds (e.g. RSS, Twitter, etc.), social networks, instant messaging and business documents. With the exception of my business documents, which are hosted by my company, I realize that I don't pay anything for all the other services; they are supported primarily by advertising revenue or venture funding. In a recent dialogue with another analyst we both admitted, if these companies needed to charge to survive, would we pay for these services? Both of us admitted we would not. I suppose that means that I would revert to using desktop client applications and Microsoft Outlook as the primary means of communication. Sadly, if this did occur, I believe many recently rekindled friendships on Facebook would once again dissipate; collateral damage of a bad economy.

While there is a major difference between my personal life in the clouds and business in the cloud, I do believe the one attribute they share is the response to failure by XaaS providers ability to thrive. As I would be returned to using traditional desktop-oriented applications that I pay for once versus pay-by-use or pay-by-subscription, so would organizations that have made bets on the cloud be returned to alternative means of delivering IT functions. This does not have to be devastating, but it certainly can be disruptive and, for some, terminal. While fiscal responsibility is important to the lifeblood of business, betting on XaaS to save money now may mean paying more money in the future as you need to be rescued from a failing platform.

As my Uncle Louie liked to say, "There's no such thing as a free lunch ... unless you pull it out of the garbage can." ;-)