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 Vikas Hazrati on Oct 06, 2010
Building software is closely associated with managing a lot of constraints. These constraints might be in terms of time, money, technology, decisions, compatibility, regulatory, people, process or all of the above. Jim Bird discussed the constraints imposed by Scrum, XP and how they help in fostering creativity and building the right software.
Jim mentioned an interesting observation about constraints.
But there’s a wonderful paradox in constraints and limits that I enjoy thinking about:
Constraints take control away from you: by dictating, by forcing you to think and work a certain way, by limiting your options.
But…
Constraints help you to take control: by dictating, by forcing you to think and work a certain way, by limiting your options.
Jim suggested that XP and Scrum force the team to work in fixed, short time boxes hence limiting the amount of work that you can take in a sprint. The solution might not be perfect but there would be a good chance to get feedback and enhance it in the following iterations. Timeboxes serve as the perfect hedge against perfectionism, gold plating and procrastination. Working with the timebox constraint also helps in managing the risk, since you would not be building too much which would be difficult to throw away.
With time boxes you are forced to work "in the small”, to think, really think, about how to get work done. It’s all about execution: who, what, when, what happens first, second. It creates a sense of urgency. And a sense of satisfaction, in seeing work done, in the feedback that you get.
Likewise, Jim mentioned that the constraint of planning just in time helps eradicate wasteful exercise of making huge plans which are outdated as soon as they are done.
The book “Getting Real” by 37signals suggested that limitations guide to creative solutions. A team should embrace constraints rather than despise them.
There's never enough to go around. Not enough time. Not enough money. Not enough people.That's a good thing.
According to 37signals, the constraints helped them to come up with creative solutions.
We lowered our cost of change by always building less software. We gave people just enough features to solve their own problems their own way — and then we got out of the way.
Marissa Ann Mayer from Google had a similar story to share. According to her, constraints shape and focus problems, and provide clear challenges to overcome. Constraints also lead to creativity at its best.
Constraints can give you speed and momentum. In shaping the process used to design a product, constraints can actually speed up development.
However, Marissa cautioned that constraints should be balanced with a healthy disregard for the impossible. This fine balance leads to innovations which can help a team either deliver an idea which changes the world or allows them to fail fast.
Ethan Zuckerman mentioned that some of the best creativity came to light when work was done in constrained conditions. He quoted the example of Picasso.
It turns out that great artists choose to constrain themselves all the time. Some of Picasso’s most moving works were made in his blue period, when he constrained himself – consciously or otherwise – to a limited, stark color palette.
Thus, constraints mostly lead to innovation and creativity. The key to be at the creative best when working with the constraint and turn it to an advantage. As 37signals put it,
Constraints are often advantages in disguise. Forget about venture capital, long release cycles, and quick hires. Instead, work with what you have.
Five Key Practices to Agile ALM
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Cool article! Off the top of my head, I can think of two other things that give you constraints in a "good way":
- Design principles - I.e. define rules for your product/website/... to help guide implementation decisions.
- DSLs - A good DSL will let developers focus on the problem, rather than the technology, even if it narrows the number of dev possibilities.
I'm sure there's a bunch of other constraints that can help (would love to see more on the comments!), but the part I think needs a lot of highlighting is the quote from Marissa Ann Mayer: Constraints must be balanced with a healthy disregard for the impossible.
Looking at a problem and dropping the constraints that limit the solution can lead to very surprising results. Not only in terms of alternate solutions, but also in terms of finding out what the team perceives as constraints. These constraints are not always real, and challenging them can lead the team, and the solution, to a totally different path.
Right constraints have advantages in Disguise and A true agile team prove that "Constraints help you to take control: by dictating, by forcing you to think and work a certain way, by limiting your options.".
With constraints in place forces every team member (Product Owner, Scrum Master and team members) to think and decide what can be delivered best in the provided situations. The Agile Mentor/ Scrum Master should see that team always has control and challenges don't take them in wrong direction.
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.
2 comments
Watch Thread Reply