Comparison of Private and Public clouds

So, you’ve decided to move some of your apps to the cloud. The next question that you need to answer is “public or private?”. Each direction has its pros and cons and you’d better look at all possible Performance Indicators before you decide where to lean. Every problem has its solution and every solution has its cost. The term “cost” is usually translated in monetary terms but this is not the whole truth. The “cost” can be compromises that you are willing (or not) to make in terms of security, availability, scalability etc. The “cost” can also be the downside of what today seems inexpensive (for example, the cost of a SaaS application that is quite low to begin with, but requires extensive customization on your existing software to integrate).

In the following table, I have compiled a list of issues that one should consider or address when having reached the crossroads “public vs private”. You see, the cloud has reshaped Information Technology but the very basics of the I.T. realm have not lost their significance: deployment, cost of ownership, knowledge capital costs etc. are some of the issues that have been troubling CIOs across the globe and will surely continue to do so for the foreseeable future. Let’s have a look at them:

Private Cloud
Public Cloud
Security can be designed and implemented according to your needs and corporate policy. Also, it can be revisited, anytime the business requirements change. Obviously, you are free to select the level of security and find the balance between that level and the cost of implementation and maintenance.
You have to follow the provider’s security guidelines. Customization in that area is not very probable or – if it is – it will come for a high price.
Sure, security is an issue that you will examine before you make your vendor selection; but things can get tricky when you find the SaaS application that best suit your needs, but the security level does not live up to your expectations.
Availability is entirely up to you. You can set very high standards but you are the only one who can make sure that these specifications are met. You have to deploy your own resources and controlling mechanisms and you have to periodically revisit the issue and probably budget for new costs.
The positive side is that you don’t have to rely on the “open internet” connection speeds. If you choose to build your private cloud on the backbone of a guaranteed internet service (such as VPN) you can stay relaxed about the throughput of your connected points.
It is not you that is troubled with that headache. As long as you have set your standards beforehand and your vendor can live up to these expectations (through a signed SLA, of course), you can rest assured that the availability will be what you expect.
Of course, high availability comes for a price and you should definitely set the roof to your expectations. The fact that the headache is not yours to handle does not mean that you should go ahead and ask more than you actually need.
You have better visibility over the various cloud components, such as computation resources, storage, network devices and the corresponding bottlenecks.
Your vendor is the one that handles and nurtures, so to speak, the entire infrastructure. They may be extra careful and professional in what they do but they can’t be as time-sensitive as you, running your own business. If, for example, you know that you have increased computation requirements from 19:00 to 23:00, you can plan for it better and more accurately, if you run your private cloud. And if worse comes to worse you are free to select services that will be downgraded in favor of the more important ones.
Because you provide service to only one set of users, the actions for orchestration and planning of the resources can be faster since complexity is lower and bottlenecks are more predictable.
A good cloud provider can perform just as well. They may also have deployed automated load balancing and other resource-planning systems. But it is a question of how fast can they respond and how accurate the can be in their “fine tunings”
Update process
The update process, pushing new releases or bug fixes to your users is entirely in your hands to plan.
Testing of new releases can be planned and executed according to your standards and take as much time as you need to ensure good results.
Also, the implementation of a separate test environment is probably a very easy thing to do and maintain.
In many cases, upgrades are pushed from the vendor with just a small notice (if any).
Also, test environments are not available or, if they are, the test planning cannot fit to your exact schedule. If every customer of that public cloud service was asked when it would be the best time for the test to start and end, it would most probably never be executed.
Finally, it is possible that separate test environments are available by the vendor, for an additional fee.
As in the update and testing process, customization is yours to decide, plan and execute.
In fact, if your governance includes a great deal of “customization” (instead of deploying “best of breed” or “off-the-shelf” products), a private cloud may be your only option.
Customization may be impossible, that’s the worst case scenario.
Customization may be possible but it will surely be implemented by vendor staff, which automatically sets the issue of “additional fees” on the table. Even if your I.T. staff was as capable as the vendor’s, the cost of customization in a public service would be so much more expensive as to cover the vendor’s profit margin, per work hour.
If your enterprise operates under a strict legal framework, then implications in terms of security, availability or other issues may be such that cannot be easily met by the average public provider. Then, the implementation of a private cloud may be the only way forward.
Assuming that your operation framework entails several strict guidelines, you may have a hard time finding a public provider that abides by these guidelines. If you find them, the additional “level of service” (which is translated into additional technical clauses in your SLA) may significantly increase start-up and/or recurring costs.
Take banks for example: how many of them operate in a public cloud?
On the other hand, for SMEs of typical nature (such as service providers, stock movers, retailers etc.) there is no question of “governance”. I.T. function may be totally absent in such small businesses and therefore the Public Cloud may be their best option for deploying almost-zero-headache top-of-the-line applications.

You may get the feeling that Private Cloud wins over Public in all of the above performance indicators. This is a generalization that is not at all true. As always, you have to carefully put down your requirements (both business and technical ones) and see how far you need to go. Then put these requirements on the balance with the budgeted costs. Finally, make your market research and find out if there are public services able to meet your standards and a cost that you can take today (and also with some buffer for the near future). Then, the answer to the “private or public” dilemma will start to be made clear…


Post a Comment

Popular posts from this blog

Reverse SLA

Data migration to SaaS

How can a web-based ERP boost your invoicing process