Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Miko Matsumura on May 23, 2006
"Some of the naysayers are no doubt experiencing implementation pain. It turns out that while SOA pilots are easy and incremental, serious enterprise scale SOA requires planning, governance, organizational change, cultural change and real budgets."
I think this is an interesting statement. But take away SOA and what are enterprises going to need to do to integrate their business proceses/systems. How do the ERP, HRMS, B2B, SCMS, etc. going to work together? This will require planning, governance, organizational change, cultural change and real budgets. SOA is just a solution, when the problem changes or more viable solutions are introduced then I'll worry.
Nice writeup, interesting links.
The basic problem is that for five years, we've seen desperate enterprise software vendors take a simple set of architectural principles and try to market them as silver bullets. As you note, folks are now finally figuring out that at the end of the day, when it comes to getting complex systems up and running, there's no substitute for old-fashioned elbow grease.
I think that's where the naysaying comes from. It's not directed at SOA per se, but rather at the vendors' SOA 'products' that were supposed to make everything easy. The basic SOA principles are always going to be useful: break your app into functional chunks that expose well-defined, coarse-grained contracts and talk to each other with XML. Those are pretty old ideas for the most part, and I don't think they're going anywhere.
The vendor-fueled hype, however, is hopefully dying a well-deserved death.
Isn't it pretty obvious where the split between blog chatter and CIO decisions come from? CIOs compare SOA to their status quo. They see that it's a big step forward, that it is supported by the big vendors, so it's only rational to jump on it. Bloggers don't compare SOA ( WS-*) to the messy integration picture that is the status quo in the enterprise. They compare to their visions of what could be. So I think both are right in what they say and do.
There's no bubble that is going to burst because SOA has materialised on the ground. I was there when CORBA was talked up as the choice for distributed integration. 10 years of CORBA talking, teaching and preaching never led to the kind of actual adoption that SOA already has. The need for distributed integration clearly exists and there are no credible alternatives to WS-* at this time when it comes to integrating systems that need security, transactions and support for complex business processes.
Also, I wonder when the bubble bubble bursts. Since the dot com bubble burst in 2000, we keep looking for tech bubbles and we forget that not every hype or fashion is a bubble in the same economic sense as the dot com bubble. Let's look at the economic fundamentals. A bubble is when huge amounts of money feed the supply side and it later turns out that there is not enough demand to ever recoup that money. Is that the case with SOA? I think not. There's no sign of that whatsoever.
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
3 comments
Watch Thread Reply