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.
How would you like to view the presentation?
Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns
Agile Development: A Manager's Roadmap for Success
Taming HTML5 and JS: High Performance Mobile, WebKit, FireFox Dev Tools @QCon New York
- just do not make the OO model too complex
- strive for readability, because beauty is in the eye of the next programmer who needs to change your code.
- generics can be hard.
- OO beauty should not get in the way of performance
More one liners that can be taken from this trial? So far Like thumbs up.
Code Reuse is an illusion - Pattern Reuse is more practical
There are several reason OO has not lived up to its promises and none of those are due to the approach. We still teach our CompSci students in a functional manner. They then use object oriented programming languages to do modular programming and not OO systems development. This is the most pervasive approaches out there. Those that succeed in OO develop an analysis model of the problem domain as perceived by the humans working in that domain. You can do this in small pieces or all at once. It does not matter as the whole is a sum of the parts. Then you teach the computer to understand the world the same way the humans understand it to be. “Data” in Startrek understands the world the same way as the humans in each episode – I believe anyway. His world model is gathered in pieces just like the crews’. Thus this approach works perfectly for waterfall or any of the agile approaches. No refactoring - as the world does not change just because you look at small pieces of it, one at a time. The problem that you first encountere when you try to teach the world model to the computer is that the OO languages do NOT support describing such a model. They have no formal relationship construct nor state transition capability (as a start). So you have to start to make these constructs up yourself and this means there are a huge number of ways of doing it leading to you never being able to re-use code from other developers. You can form components by grouping together classes but how big is a component?? This latter question sinks the approach as no two developers agree on the size. As I said above, functional development is the norm today using OO languages. More and more features are added to support this approach – most of which are not needed for OO. Unless training changes OO never will reach its promised level.
The community reuses a ton of libraries daily ('java.*', "org.apache.*') very successfully. In the companies I have worked for we have been quite successful at reuse in our frameworks. The problem is poor designs. Embrace immutability and prefer composition over inheritance. I haven't seen a third party application framework that doesn't encourage the opposite, so write your own -- it doesn't have to be J2EE.
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