How Do These Two Compare?
In Boy Scouts, I learned how to tie knots. The quickest knot you can tie is the slipknot. It’s very effective for connecting one thing to another via the rope you have. It was used in setting up tents, mooring boats to docks temporarily and lifting your food up into the air to prevent wild animals from eating your camp dinner (otherwise you went hungry).
What do slipknots have to do with clouds? A lot more than you would think. First off, the concept of picking a cloud service provider is a lot like picking a knot. The goal of a knot is to connect something to something else. Which, by the way, is why people pick cloud service providers. They want to connect an internal business application to the cloud for a variety of purposes. The similarity is that if you pick the wrong knot you end up with a problem. Slipknots are aptly named, they slip as they tighten. You wouldn’t want your cloud selected to be different after selection than during the selection.
The other thing about knots that you have to be careful about is the form of the knot and the function of the knot. A square knot or reef knot as it is sometimes called it a very strong knot that connects two ropes together firmly. But you have to have two ropes for a square knot to be effective. The same is true of picking a cloud service provider (CSP). What does the CSP do? How does the CSP do it? Those are the two easy question you need to pick the right CSP that does things the way you need them done for your solution.
Simple right? Never fails. Easy to do.
Not always. In fact if you consider knot selection as a process you evaluate not only what you initially need from the knot but also what you will need from that knot over time. A secure long term connection is better serviced by a reef knot then it would be by a slip knot. A quick and simple connection that is short term in nature is better served by a slip knot.
We can say the same thing for cloud service providers. What do we need from the cloud service? If we need high performance that will limit the CSP’s we consider. If we need massive amounts of storage that will limit the CSP’s we consider. If we have an existing technology solution that will change the CSP’s we consider.
Then into that initial bucket of providers we have to consider what the solution does and how that will work in the CSP’s solution set. A performance model that supports not seasonality, which is a fairly standard cloud term that describes when a solution needs more processing power. Rather does our CSP support the concept of intelligent seasonality?
Intelligent seasonality is a new term. It’s not in wiki or I would give you a link. It’s a term that supports the concept of not just bursting, but bursting intelligently. It’s the concept of looking at the entire process I am running and determining if, in fact, bursting even makes sense. A great example of this is found in the kitchen (a common theme of mine). As you cook you add things in a specific order. Adding them early or speeding up one process at times is more detrimental than useful. It’s a balancing act. That balancing act in the end is intelligent seasonality. Speed the process as a whole and things work. Speed up only one part of the process and you may end up with something that doesn’t work.
In the end, that is why CSP selection and knot selection are critical and similar. Pick the wrong CSP or the wrong knot and you will end up with something that works but is not optimal. Pick the right CSP and the right knot – and you have a fully functional success.
By Scott Andersen