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.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Tight Coupling and its Unintended Consequences
Posted by Mark Figley on Nov 13, 2007
Neal Ford has an interesting post about high coupling and it's unintended consequences. He uses Windows PowerShell and it's necessary exclusion from the headless Windows Server as an example of the evils of tight coupling:
... they have built a new batch language for Windows called Windows Power Shell (nee Monad), which is simply brilliant. They have raised the bar on what a shell language can be... Only one small problem. They want to make the footprint of the headless version of Windows Server smaller than the footprint of Vista (currently about 8 Gb, and that's just for the OS). The problem is that the headless version won't include .NET 2, because the .NET framework and libraries are coupled to just about every nook and cranny of Windows. If you include .NET 2, you pretty much include all of Windows. And there's the rub: Windows Power Shell is written on top of .NET 2. Which means that this brilliant tool for managing tasks, services, and general scripting of the operating system won't be available for the one system that could benefit from it the most.
Reusing the foundational assets provided by the windows operating system instead of redeveloping those components probably made sense to the design team when .NET was being developed. And talking to those assets through optimized direct invocation instead of decoupled messages might have made sense as well. It was, if nothing else, expedient. And that's the tension point - especially as we transition from component architectures to service oriented architectures, the balance between natural, efficient asset reuse and independent, decoupled systems is a real battleground. And the battleground is multifaceted: WS-* vs. REST, synchronous vs. asynchronous communication models, etc. Jim Webber addresses coupling as it applies to service architectures in this InfoQ interview with Stefan Tilkov. From the interview:
We like to keep each process that we are implementing relatively isolated so that then the service ecosystem grows and can be reused. It has this emergent behavior that we never expected. On the other hand if we allow everything to bleed together in a big SOA platform you tend to get tight coupling and that restricts your options for evolution further down the line and it restricts your options for this kind of interesting emergent behavior ... We saw this back in the day with CORBA applications where we tightly coupled through IDL and we see it today in Web services where we tightly couple through another IDL called WSDL. If we are sharing type systems and I want to change my type system in my program that can have a ripple-through effect which is going to hurt you. So when I come to you and say "I'm going to make changes" your first reaction is "No, because you're going to break me!" and then we get into this paralysis, where neither of us can make progress because we're so scared of damaging each other.
Watch the interview with Jim Webber for more.
RelatedVendorContent
Introducing SQLFire: a memory-optimized, high performance SQL database
Automating Error Reporting for .NET Applications
App Server Evolution: REST, Cloud, and DevOps Support in Resin 4
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
No comments
Watch Thread Reply