The cloud : Basic definition
The cloud is very trendy these days. It can be seen as a marketing tool to somehow revamp the Software as a service industry. This of course also evolves from simple "SaAS" to different levels of service, namely infrastructure as a service (think amazon EC2, etc.) , platforms as a service (think Google app engine, etc.) and of course the good old "Software as a service" (think SugarCRM, etc.).
Given the broad definition of the cloud, almost any IT company can say "this is what we've been doing since 200_" (insert your favourite digit here!)
When trying to sell these funny things, vendors encounter a major difficulty : many corporations/organizations are used to the so called "firewall principle" and don't trust anything outside their firewall for so-called critical applications and also for serious red-tapping (our internal policy prevents us from ..., we can not do this because of ..., etc.).
One can argue that security and IT management is way better for major cloud providers (Amazon, Google, etc.) than it is for most of us so-called "small scale" organizations ( compared to 1 Million+ servers , many organizations are "small scale" according to this definition!). Even if this is true from a technical and processing aspect , this does nothing to ease the pain and allow the cloud to be used by these organizations.
Ladies and Gentlemen : Here comes the private cloud !
In the past , vendors adapted their marketing and sales pitch by creating a new marketing term : the so called "private cloud" that refers to the re-branded "public cloud" offered by major hosting providers (Rackspace, etc.), web 2.0+ major actors (Amazon, Google).
In a way, a private cloud is the answer for vendors to somehow respect the "behind the firewall rules". It provides access to a cloud platform inside your organization. Also, it implicitly solves the "privacy/security" issue with a saying that says it all : private is private after all !
I believe this is highly misleading because it implies that everything on the public cloud is ... public. This is clearly not the case. Even if any given "public" cloud provider is so-called "multi-tenant" (meaning that different customers can share for a period of time the same hardware), if you use secure protocols and encryption, you can be pretty certain that everything you send is private and only seen by you . The only risk added being the one of the virtualization layer itself , are all virtual machines really isolated when sharing the same hardware ?
Most of the time, a choice has already been made : most of us have already been using virtualized servers in a production environment in the past .
For the "very secure" few that don't allow virtualization for security reasons , this is not the subject of this post ;-) therefore, you have two choices : Change your policy or stay away from virtualization and cloud technology...
My proposal is to drop the "public/private" cloud definition in favor of a more precise definition in order to define where the cloud is located in terms of network topology, whether the cloud is shared or dedicated and who managed the cloud (you or a cloud provider).
In front of your firewall or not ?
More precise classification means, is the cloud behind your firewall or in front of your firewall ?
If you manage your cloud, lets call this a self-managed cloud.
If you outsource the management of your cloud, lets call this an outsourced cloud.
Is it dedicated or shared ?
A dedicated cloud is used only by you. You are the sole user of the resources (servers, network equipment, storage, etc.) that provides the cloud services.
A shared cloud is multi-tenant : several users share resources (CPU, RAM, storage space, etc...).
Often times , dedicated means more expensive : as the sole user of the infrastructure provided by the cloud, you have to assume all the costs.
However, given the "pay as you go" principle of the external shared clouds, it can be less expensive to run your own cloud for the regular load of your organization and to use the public cloud only for specific workloads/peaks.
3 major types of clouds :
Internal dedicated cloud : self managed or outsourced ?
This is the closest to virtualization as we know it. Most of the time , you own the data, the servers and need to manage everything : the hardware, cloud software and the operating system. The main difference is that you use a cloud stack (open source or not...) consequently , you need to standardize your workload.
The main advantage of doing this is you benefit from an external cloud (managed or outsourced) and tap into external resources when you need it. This allows the IT department to offer a common platform to each internal customer. This is especially interesting for large organizations and can be much more economical than a public cloud.
Instead of a "pay as you go" way of billing, you can fit this type of cloud into a classic budget : capital investment for the initial deployment, fixed price for the management of the cloud. In practice, one can argue that this is not really "the cloud" as you still have to manage "scarcity" (i.e.: a fixed amount of resources) instead of ubiquity (a somehow "infinite" computing power, bandwidth and storage capacity). It is said that constraint generates innovation , therefore this type of constraint is not necessarily bad per say .
If you self-manage your cloud, you are in charge of all the stacks and regular IT processes : provisioning, capacity planning, etc. You can manage a fixed budget : a capital budget needed with a fixed operation budget (power, staff, etc.). You can manage scarcity (the actual amount of resources you have).
If you outsource the management, you are a user of your cloud and can decide to scale up based on pre-agreed fees, per server or per-storage nodes.
This model fits nicely into an existing infrastructure and acquisition process : you can really benefit from this model as you are able to leverage the somehow "standardization" of the workload management while you remain completely in sync with your organization's acquisition policy and budget.
External dedicated : self-managed or outsourced
External dedicated is an extension of the preceding category: you can use a hosting provider to own your own cloud. In this case, the cloud is clearly in front of your firewall. On the other hand , the cloud is not shared. Servers are only used by you and no one else. You can even re-sell your spare cycles ;-)
You can also self-manage or even outsource the management of the cloud.
This model requests only minor updates to your security policy. This is very similar to hosting your public services at a data centre , can become an easy sell and an easy way to start implementing a cloud strategy.
External shared and outsourced
This is the "classical cloud", the one offered by Google, Amazon, Rackspace, etc. This infrastructure management is outsourced to the cloud provider and the cloud is therefore multi-tenant : various users share various physical resources.
Conclusion
We defined different ways a cloud can be deployed into an organization and used some more precise terms to define where the cloud is located (topology), who managed it (you or somebody else) and if the cloud's resources are shared or dedicated.
These definitions clearly overlap the traditional marketing and trendy "public/private" cloud approach and this is why the public/private vocable seems inappropriate due to its lack of precision.
In terms of IT governance and acquisition processes, the internal dedicated self-managed cloud is the easiest to sell/deploy, even for a very conservative organization. Benefits from the cloud could be very important even in this context, especially if you have developers and the need for development, staging and production environment.
The cloud is very trendy these days. It can be seen as a marketing tool to somehow revamp the Software as a service industry. This of course also evolves from simple "SaAS" to different levels of service, namely infrastructure as a service (think amazon EC2, etc.) , platforms as a service (think Google app engine, etc.) and of course the good old "Software as a service" (think SugarCRM, etc.).
Given the broad definition of the cloud, almost any IT company can say "this is what we've been doing since 200_" (insert your favourite digit here!)
When trying to sell these funny things, vendors encounter a major difficulty : many corporations/organizations are used to the so called "firewall principle" and don't trust anything outside their firewall for so-called critical applications and also for serious red-tapping (our internal policy prevents us from ..., we can not do this because of ..., etc.).
One can argue that security and IT management is way better for major cloud providers (Amazon, Google, etc.) than it is for most of us so-called "small scale" organizations ( compared to 1 Million+ servers , many organizations are "small scale" according to this definition!). Even if this is true from a technical and processing aspect , this does nothing to ease the pain and allow the cloud to be used by these organizations.
Ladies and Gentlemen : Here comes the private cloud !
In the past , vendors adapted their marketing and sales pitch by creating a new marketing term : the so called "private cloud" that refers to the re-branded "public cloud" offered by major hosting providers (Rackspace, etc.), web 2.0+ major actors (Amazon, Google).
In a way, a private cloud is the answer for vendors to somehow respect the "behind the firewall rules". It provides access to a cloud platform inside your organization. Also, it implicitly solves the "privacy/security" issue with a saying that says it all : private is private after all !
I believe this is highly misleading because it implies that everything on the public cloud is ... public. This is clearly not the case. Even if any given "public" cloud provider is so-called "multi-tenant" (meaning that different customers can share for a period of time the same hardware), if you use secure protocols and encryption, you can be pretty certain that everything you send is private and only seen by you . The only risk added being the one of the virtualization layer itself , are all virtual machines really isolated when sharing the same hardware ?
Most of the time, a choice has already been made : most of us have already been using virtualized servers in a production environment in the past .
For the "very secure" few that don't allow virtualization for security reasons , this is not the subject of this post ;-) therefore, you have two choices : Change your policy or stay away from virtualization and cloud technology...
My proposal is to drop the "public/private" cloud definition in favor of a more precise definition in order to define where the cloud is located in terms of network topology, whether the cloud is shared or dedicated and who managed the cloud (you or a cloud provider).
In front of your firewall or not ?
More precise classification means, is the cloud behind your firewall or in front of your firewall ?
- An internal cloud is behind your firewall
- An external cloud is "in front" of your firewall, on the Internet
If you manage your cloud, lets call this a self-managed cloud.
If you outsource the management of your cloud, lets call this an outsourced cloud.
Is it dedicated or shared ?
A dedicated cloud is used only by you. You are the sole user of the resources (servers, network equipment, storage, etc.) that provides the cloud services.
A shared cloud is multi-tenant : several users share resources (CPU, RAM, storage space, etc...).
Often times , dedicated means more expensive : as the sole user of the infrastructure provided by the cloud, you have to assume all the costs.
However, given the "pay as you go" principle of the external shared clouds, it can be less expensive to run your own cloud for the regular load of your organization and to use the public cloud only for specific workloads/peaks.
3 major types of clouds :
Internal dedicated cloud : self managed or outsourced ?
This is the closest to virtualization as we know it. Most of the time , you own the data, the servers and need to manage everything : the hardware, cloud software and the operating system. The main difference is that you use a cloud stack (open source or not...) consequently , you need to standardize your workload.
The main advantage of doing this is you benefit from an external cloud (managed or outsourced) and tap into external resources when you need it. This allows the IT department to offer a common platform to each internal customer. This is especially interesting for large organizations and can be much more economical than a public cloud.
Instead of a "pay as you go" way of billing, you can fit this type of cloud into a classic budget : capital investment for the initial deployment, fixed price for the management of the cloud. In practice, one can argue that this is not really "the cloud" as you still have to manage "scarcity" (i.e.: a fixed amount of resources) instead of ubiquity (a somehow "infinite" computing power, bandwidth and storage capacity). It is said that constraint generates innovation , therefore this type of constraint is not necessarily bad per say .
If you self-manage your cloud, you are in charge of all the stacks and regular IT processes : provisioning, capacity planning, etc. You can manage a fixed budget : a capital budget needed with a fixed operation budget (power, staff, etc.). You can manage scarcity (the actual amount of resources you have).
If you outsource the management, you are a user of your cloud and can decide to scale up based on pre-agreed fees, per server or per-storage nodes.
This model fits nicely into an existing infrastructure and acquisition process : you can really benefit from this model as you are able to leverage the somehow "standardization" of the workload management while you remain completely in sync with your organization's acquisition policy and budget.
External dedicated : self-managed or outsourced
External dedicated is an extension of the preceding category: you can use a hosting provider to own your own cloud. In this case, the cloud is clearly in front of your firewall. On the other hand , the cloud is not shared. Servers are only used by you and no one else. You can even re-sell your spare cycles ;-)
You can also self-manage or even outsource the management of the cloud.
This model requests only minor updates to your security policy. This is very similar to hosting your public services at a data centre , can become an easy sell and an easy way to start implementing a cloud strategy.
External shared and outsourced
This is the "classical cloud", the one offered by Google, Amazon, Rackspace, etc. This infrastructure management is outsourced to the cloud provider and the cloud is therefore multi-tenant : various users share various physical resources.
Conclusion
We defined different ways a cloud can be deployed into an organization and used some more precise terms to define where the cloud is located (topology), who managed it (you or somebody else) and if the cloud's resources are shared or dedicated.
These definitions clearly overlap the traditional marketing and trendy "public/private" cloud approach and this is why the public/private vocable seems inappropriate due to its lack of precision.
In terms of IT governance and acquisition processes, the internal dedicated self-managed cloud is the easiest to sell/deploy, even for a very conservative organization. Benefits from the cloud could be very important even in this context, especially if you have developers and the need for development, staging and production environment.
Of course, to be able to really tap into the ubiquity of the cloud and its potentially unlimited (but billed!) resources, one will need to extend its comfort zone and somehow connect to a shared external and outsourced cloud. This disruptive innovation is only available for organizations that have completely revamped their development process, their security policy, as well as their acquisition mechanism.
Start-ups don't have any legacy and can start right away without any capital expenditures , this said , Cloud and its operational costs is directly based on usage : this is not something every organization is ready to deal with.
Other organizations will need to compromise and can do so by using any of the mentioned cloud deployment models that provide various levels of flexibility in terms of :
- capital vs operational budget (private -> shared)
- outsourcing or not (self-managed -> outsourced)
- firewall position (internal->external)
No comments:
Post a Comment