http://buildacloud.org/blog/278-on-fragility-and-deployment-in-the-cloud-the-shoe-maker-drives-an-f1.html
"I think that we can all admit that deploying a cloud infrastructure can be a complex endeavor. With so many moving parts, each with its own configuration not to mention limitations, so called fragility can become a central hurdle within the architectural blue prints of a cloud infrastructure.
Many in the DevOps space (infrastructure as software) prefer to use the tactic of loosely coupled software components when building out clouds. This is an architecture defined by an endless number of components that come together to create a unique cloud environment. I'm not saying this is wrong, in many cases this type of approach can lead to differentiation between you and your competition. But it doesn't necessarily make things easier, at least from the stand point of an easy to deploy and mange cloud infrastructure.
In my early exploration of CloudStack several analogies have been used to describe it to me. CloudStack has taken a much more structured approach to the packaging and deployment of a cloud platform where others in the industry have taken a much looser tact. One of my colleagues uses a shoe analogy to describe the differences saying "A loosely coupled architecture offers a seemingly endless variety of colors, sizes, and styles. When you order it, you receive a box with soles, fabric, scissors, and instructions how to measure your foot, how to choose which blueprint to follow, how to cut the fabric, how to stitch it so it looks good, etc. Most folks will need to engage a professional cobbler to assemble the shoe."
He points out that CloudStack offers fewer colors and styles, but when you receive the box, you spend a few moments lacing up the shoes and you're out running in short order.
Another colleague describes it a bit differently saying its much more like a F1 car. "You get to choose every single piece that goes into an F1 car, but it's inherently more temperamental and requires an entire team to keep it running smoothly. That said if you need the absolute best performance of flexibility that model is the way to go. The problem in a loosely coupled stack is the differing levels of maturity of mandatory pieces of the infrastructure. Some of those pieces are time/production tested, others not so much, yet. It's the equivalent of having awesome race tires that grip really well and a fuel pump that's a bit dodgy."
Some in the industry have called CloudStack's default deployment architecture 'monolithic ,' although I'm not sure I'd completely agree with this representation. Moreover; if it is, I'm not convinced that it is actually a bad thing. Today there are number important and commonly used services that we have broken out, such networking, secondary storage, and console proxy. These elements give our users the ability to pick and choose the components they prefer. I'm also told that we are actively working on breaking out other services, such as API endpoints which will further users choices. However that said, the default deployment that we ship will likely remain a singular package. This in my opinion will actually benefit the majority of our users from both a scalability perspective; we can handle around 10k physical nodes with a single management server as well as from a fragility perspective, less random breakage.
Maybe CloudStack should be described like a Toyota dealership, or Lexus if you prefer - yes we can let you have a Prius, a Camry, or a Tundra, or maybe even buy multiple cars – it's still cheaper than the F1 car, and we have a dealership garage for maintenance, but you don't need to travel with a team of mechanics."
Find Reuven on Twitter @rUv | Linkedin | Google+ | Facebook | Podcast
No comments:
Post a Comment