Cloud computing is no longer just a buzzword, it is here to stay. Companies should prepare by looking into cloud technology and getting their cloud strategy sorted out. If you look at cloud computing in its most basic form, you could simply call it store stuff on the internet. Although this is partially true, the cloud has much more to offer.
Preparing for the cloud means a fundamental change of perspective on computer technology, especially on how we use computing power. The cloud’s main advantage is that it has the ability to turn software into a service. Customers only pay for what they actually need, turning computing power and storage space into a parameter that you can buy when you need it, and be scaled up when necessary.
Let’s talk about OPEX and CAPEX
What most people miss out on is the cloud’s ability to shift your IT expense from CAPEX to OPEX. Evenly important and often overlooked is how the price of a 1U server is compared to an Azure server. Usually the average selling price is divided by the number of months of the server’s typical expected service life (36 or 48 months), showing that the total cost per month is lower than the same server from Azure. People tend to conclude that cloud computing is bound to be more expensive than self-owned and therefore the cloud is considered inappropriate for typical corporate apps that require round-the-clock availability. This line of thought, however, completely overlooks the fact that the real cost of hosting a server consists of immediately paying for the foreseen overhead in three to four years. You risk throwing away even more money if you make a mistake in either direction during the sizing phase.
Allow me to explain
Assume the sizing is done correctly and the estimates predict that you will need a €25,000 server with 8 cores and 48 GB ram, costing you €100,000 on licenses. Because of the predictable growth of the application this means that:
– This server is running on average on 20% during the first year
– Then the server is running on average on 30% during the second year
– Then the server is running on average on 65% during the third year
– Then the server is running on average on 85% during the fourth year
What does this tell you about your TCO?
So your TCO for 4 years is (excluding interest, various overhead factors, maintenance and electricity) €125,000 or bluntly put €2,605/month. The same server in Azure cists €2,736/month. The quick and dirty conclusion is that cloud is ± 5% more expensive, which to critics is the proof they need that internal servers are cheaper. Unfortunately, this conclusion is a losing strategy because it fails to incorporate the cloud’s greatest power: flexibility.
We paid too much now, didn’t we?
– The first year, you could have done with 2 cores -> 80% overpowered
– The second year, 3 cores would have been enough -> 50% overpowered
– The third year, 6 cores would have done the trick -> 20% overpowered
– Only the fourth year you would have needed 8 cores -> well-sized
Let’s use the cloud to recalculate the Azure TCO
– The first year we can use an A5 Server (2 cores, 14GB Ram) -> €1,155/month
– The second year we use an A6 Server (4 cores, 28GB Ram) -> €1,137/month
– The third and fourth year we’ll need a A7 server (8 cores, 56GB Ram) -> €2,736/month
This brings your TCO to €93,168 instead of €125,000, which is 25% cheaper than previous calculations, simply by using the cloud in its simplest form. Even greater profits are possible by changing the way we think about IT assets.
The cloud may be more economical, but this doesn’t mean that you should switch just like that. Moving to the cloud requires a certain level of self-examination, because one size won’t fit all.
Some important examples are:
– How much management do your data or applications need?
– What’s the right measure of security for your company?
– Where is the workload?
– Which data are sensitive, which are not?
– Do you have specific regulatory issues like audits, compliance and privacy?
– Is your organization ready for a service based approach?
In short, you’ll need to map your company’s and business units’ IT needs to decide on the right cloud strategy. For example, if you’re hosting your own applications, the source code might be really sensitive. For others, such as servicing hospitals, the data itself is really sensitive. This is why you shouldn’t just ask yourself what you should put in the cloud, but also how and where.
The cloud should never be seen as a goal on itself. It is a tool, enabling you to achieve your goals, targets or SLA’s. Going to the cloud often means that you’ll need to release some flexibility and control, but you will get scalability and power in return. If you look at the cloud in that way, the questions you should ask yourself are easier to answer.
When going to the cloud always make sure you are able to describe how data or assets will need to be secured. After creating this security mapping, start to investigate how you can achieve this. Divided security into two solid blocks; one being access security ─ encryption/passwords/access control/auditing─, and the other one being the storage and protection of data itself ─ backups/retention/storage location/storage type).
Try to avoid thinking in terms of servers and start thinking in term of individual services. You don’t actually need a full database server running in the cloud when you can do with just a database, or even smaller, a table. By allowing this kind of granularity, you will be able to harness the true power of the cloud. A database server only becomes needed if you need several databases, facilitating the business decision when to use what kind of service you actually need (for example IAAS vs. PAAS).
The easiest way to learn about how the cloud performs, is to start using it in Dev and/or test it. This allows you to start your cloud adventure without having to worry about confidential data or mission-critical systems, building confidence and experience. If the service works, you can expand with peace of heart and confidence. After all, this is what Gartner experts advise to their customers: first put a small [cloud service] in place and see what unexpected behaviors happen.