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 Stefan Tilkov on Oct 12, 2007
Hi,
The software providers confuse "Cosmetic SOA" (adding services to existing systems such as a revamping) with restructuring the existing system (Overhaul SOA). In each case, governance is very different:
"Cosmetic SOA" governance is not strategic. In essence, service agility depends on the quality of the patrimony and it should be said that there isn't much to govern. Because we don't conceive of a new system, the UML modeling is limited and meta-data very limited, except those which are already recognized in the ESB-type intermediation layers and some SLA in the exposed services.
"Overhaul SOA" governance supports modeling of the future system and should integrate UML CASE. Unfortunately, this is not the case if you hear how software vendors describe SOA governance.
Indeed, most meta-data comes from UML modeling. The remainder comes essentially from the SLA concerns. Thus, the repository described by SOA software vendors (design time governance) is not strategic because knowledge of the architecture is already fixed upstream in the UML modeling, then recaptured in the IDE. The repository would be usefull if there were perfect integration in the UML CASE and in the IDE but this is not possible: a new generation of CASE and IDE would be created! The only possible scenario would be the creation of complete connectors between all tools, each with their own repository. They also would need to be synchronized.
The challenge of SOA governance is not only the meta-data which remains a modeling concerns and interface with IDE. Real governance refers to functional and technical data management that will react to the internal behavior of each service : functional parameters, reference table filtering, multilingualism, technical infrastructure parameters, etc. This configuration time governance – oriented toward reference data and parameters management – leads us to the MDM (Master Data Management) component in the ACMS agility chain. It should be in the hands of the business team because they are affected by the services' functional configuration. The technicians (development and production) also use MDM, in this case, to value technical data, particularly configurations of the SOA platform, such as ESB, mapping and transcodification tables.
The services' execution contexts are then managed by MDM. These contexts do not only concern the services directly exposed to the user (coarse grained), and those present in the registry (SLA), but also all services (meduim and fine grained) that require execution variants be taken into consideration.
See more on my web site : www.sustainableitarchitecture.com
Pierre Bonnet
pierre.bonnet@orchestranetworks.com
This is beautiful...
Most of the stuff I find online on SOA and SOA governance is marketing crap and I always love to read something meaningful. And for this article - Hats off!!!
Long bck I tried my hand explaining SOA Governance in short and sweet newbies language.
mytechrantings.blogspot.com/2007/07/soa-governa...
But this article here takes an A++ for newbies as well as experts it'll definitely be very useful!!!
Rohit, Pierre:
thanks for commenting on the article. The goal of the article was to help people jump start their "Service Governance" effort. As Rohit points out, this is different from "SOA Governance". IMHO, a lot of governance organizations are formed because someone said so. Right-sizing governance is critical in the beginning because could quickly lose interest if the pipeline of services to govern is weak. The other important aspect of this paper is that it focuses on "reuse" because we need to show benefits as quickly as possible to keep expanding the SOA initiative.
This paper provides a model for Maturity Level 1 (on a scale of 4). It is agile (build only what you need) and requires only two main roles: governance lead and librarian who should really be knowledgeable about the process and the technologies and guide the council towards producing meaningful recommendations.
The distinction between "Cosmetic" and "Overhaul" is important to understand and I would never argue that this paper represents a governance organization at a level of maturity higher than 1. Again, I think the modeling efforts should be adapted to the amount of governance required.
SOA is complicated, and needs to be simplified. Right-sizing (don’t do more than you need), Prioritization (do only what you need) and Vision (align the benefits of SOA with your organization strategy) are key success factors of any SOA initiative. It is very difficult to succeed without keeping these recommendations in mind.
JJ-
The article is fundamental I do like it. However, I have a few comments on
"SOA is complicated, and needs to be simplified. Right-sizing (don’t do more than you need), Prioritization (do only what you need) and Vision (align the benefits of SOA with your organization strategy) are key success factors of any SOA initiative. It is very difficult to succeed without keeping these recommendations in mind."
1)Why SOA has to be simple? Are we considering a business as simple? What is a simple business?
2) to me, articulated Vision rule - align the benefits of SOA with your organization strategy - gets into a very strong boundle with Right-sizing (don’t do more than you need) and Prioritization (do only what you need). The question on the surface is: What do you need? If you concern with your organization strategy, your needs are strategical in addition to today needs, right? Otherwise, how SOA might be aligned with your organization strategy...
I would like to outline that traditional SW development, especially, traditional PM, which deals with requirement for today only and requests don’t do more than "required" and do only what is "required", is a bad advisor for SOA development because SOA must look into the future flexibility. SOA Governance has to set special development and execution policies to promote SOA capability of adopting to the frequently changing business market; this may be achived not necessary via "as-is" reuse but via smarter design for changes (this is what is you need in SOA in reality)
- M.P.
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.
4 comments
Watch Thread Reply