Saturday, 6 November 2021

Data Center to Cloud- Move into the Cloud

The fact that virtual data centers in the cloud can be provisioned or scaled down with just a few mouse clicks is part of the reason for moving to the cloud. In the modern data center, software-defined networking (SDN) manages traffic flows via software. Infrastructure as a Service (IaaS) from public and private clouds spins up whole systems on-demand. When new applications are needed, Platform as a Service (PaaS) and container technologies are available in an instant.

While many organizations have already made the jump to the cloud, others are less certain. The cloud provides a number of advantages, but many companies are concerned about the cost and the lack of visibility, accountability, and transparency of public cloud infrastructure.

Data Center vs. The Cloud: Which is Best for Your Organization?

There is no “one-size-fits-all” solution for every organization. Ultimately, the decision to use a public cloud, private cloud, hybrid cloud, or traditional data center depends on the degree of privacy and control needed, as well as the pressure to curb costs and increase transparency. The following chart summarizes the benefits and drawbacks of each approach:

Traditional Data Center

Cloud Computing

Hybrid Cloud

Benefits:Owner has complete control over hardware

Cost of use is slightly easier to understand

Privacy can be maintained in industries where it is required

Little in the way of up-front costs

Resources are scalable with use and need

Pay for what you use

Requires little knowledge or manpower to get started

Rapid implementation

Platform independent

Easy to access remotely

Automatically updated

Ongoing security

Opportunity to try out the cloud without a full commitment (or full migration)

All benefits of a cloud platform are available for use

Cloud can serve as a backup for on-prem data centers and vice versa

Can operate behind a firewall (good for added security)

Allows more control over some parts of the cloud

Disadvantages:High up-front capital cost

Takes up space, uses power whether used or not

Requires a dedicated team to maintain

Hard to access remotely

Security solely dependent on local team

Updates are not automatic; again rely on local team

Less control over the actual hardware and operating system

Services offerings and cost structures can be hard to understand at times

Privacy and access must be monitored closely

Keeping track of multiple clouds can be tricky; might require a third party dashboard



Good for:Smaller organizations that already have a heavy capital investment in IT

Organizations that need to be excessively cautious about data privacy

Most organizations of any sizeLarger organizations with existing IT infrastructure, but who also want to start their cloud journey



Know Your Software Licenses - The right for every user

 With many cloud environments in operation today, you pay for resources by the CPU-hour. The cheapest virtual machine in the Amazon Cloud, for example, costs $0.10 for each hour you leave the instance in operation. If it is up for 10 hours and then shut down, you pay just $1.00—even if that is the only use you make of the Amazon cloud for that month.

In a real world, you might have the following operating scenario:

  • From midnight to 9 a.m., run your application on two application servers for redundancy’s sake.
  • From 9 a.m. to 5 p.m., launch six additional application servers to support business-hour demand.
  • For the evening hours through midnight, reduce the system down to four application servers.

Adding all that up, you pay for 110 hours of computing time. If you were using physical servers, you would have to purchase and run eight servers the entire time.

Unfortunately, not all software vendors offer licensing terms that match how you pay for the cloud. Traditional software licenses are often based on the number of CPUs. An organization that uses 10 application servers must pay for 10 application server licenses—even if 5 of them are shut down during the late night hours.

So, when moving to the cloud, you must understand your licensing terms and, in particular:

  1.     Does the software license support usage-based costs (CPU-hour, user, etc.)?
  2.     Does the software allow operation in virtualized environments?

Because the cloud makes it so easy to launch new instances, you can readily find yourself in a situation in which a lower-level staff member has launched instances of software for which you don’t have the proper licensing and, as a result, has violated your license agreements.

The ideal cloud-licensing model is open source. In fact, the flexibility of open source licensing has made the Amazon cloud possible.

 If you can remove licensing concerns altogether from your cloud deployments, you are free to focus on the other challenges of moving to the cloud. Although some open source solutions (such as Apache and most Linux distributions) let you do whatever you want, you may have to deal with licenses if you get supported versions of open source software, such as Red Hat Enterprise Linux or MySQL Enterprise. Luckily, these licensed offerings tend to be cloud-friendly.

Beyond pure open source, the best licensing model for the cloud is one that charges by the CPU-hour. As the cloud catches on, more and more software vendors are offering terms that support hourly license charges. Microsoft, Valtira, Red Hat, Vertica, Sun, and many other companies have adopted per-CPU-hour terms to support cloud computing. Oracle promotes their availability in the cloud but unfortunately retains traditional licensing terms.

Software that offers per-user licensing can work adequately in the cloud as well. The challenge with such software is often how it audits your licensing. You may run the risk of violating your terms, the license may be tied to a specific MAC or IP address, or the software license management system may not be smart enough to support a cloud environment and unreasonably prevent you from scaling it in the cloud.

The worst-case scenario in the cloud is software that offers per-CPU licensing terms. As with some per-user systems, such software may come with license management tools that make life difficult. For example, you may have to create a custom install for each instance of the software. Doing that impairs the flexibility that the cloud offers.

Some CPU-based software licenses require validation against a licensing server. Any software with this requirement may ultimately be inoperable in the cloud if it is not smart enough to recognize replacement virtual servers on the fly. Even if it can recognize replacements, you’ll have to make sure that the license server allows you to start the number of servers you need.

Unless a license server is going to be an impediment, however, the result is no worse than a physical infrastructure. If all of your software fits into this model, the benefits of the cloud may be small to nonexistent.

The Shift to a Cloud Cost Model - A money saving approach

As you know, you pay for resources in the cloud as you use them. For Amazon, that model is by the CPU-hour. For other clouds, such as GoGrid, it’s by the RAM hour. Let’s look at how you can anticipate costs using the example resource demands by using (two application servers from midnight until 9 a.m., eight from 9 a.m. until 5 p.m., and four from 5 p.m. until midnight)
Suppose your core infrastructure is:
  • $0.10/CPU-hour: one load balancer
  • $0.40/CPU-hour: two application servers
  • $0.80/CPU-hour: two database servers

Each day you would pay:

$2.40 + $44.00 + $38.40 = $84.80

Your annual hosting costs would come to $30,952.00—not including software licensing fees, cloud infrastructure management tools, or labor.

How to Approach Cost Comparisons

The best way to compare costs in the cloud to other models is to determine the total cost of ownership over the course of your hardware depreciation period. Depending on the organization, a hardware depreciation period is generally two or three years. To get an accurate picture of your total cost of ownership for a cloud environment, you must consider the following cost elements:

  •  Estimated costs of virtual server usage over three years.
  •  Estimated licensing fees to support virtual server usage over three years.
  •  Estimated costs for cloud infrastructure management tools, if any, over three years.
  •   Estimated labor costs for creating machine images, managing the infrastructure, and responding to issues over three years.
  •  Any third-party setup costs for the environment.

If you want a truly accurate assessment of the three-year cost, you will need to take into account when the costs are incurred during the three-year period and adjust using your organization’s cost of capital. This financial mumbo jumbo is necessary only if you are comparing cloud costs against a substantial up-front investment in a purchased infrastructure, but if you understand it, it’s still a good idea.

In comparison, you must examine the following elements of your alternatives:

  • What are your up-front costs (setup fees, physical space investment, hardware purchases, license fee purchases)?
  • What labor is required to set up the infrastructure?
  • What are the costs associated with running the infrastructure (hosting space, electricity, insurance)?
  • What are the labor costs associated with supporting the hardware and network infrastructure?
  • What are the ongoing license subscription/upgrade fees? Maintenance fees?

This particular example assumes that two application servers easily support standard demand. It also assumes, however, that the business has a peak period of traffic on the 15th day of each month that lasts for 24 hours. Serving this peak capacity at the same performance levels as standard capacity requires an extra four servers. This system can still function at peak capacity with only two extra servers—but at the expense of degraded performance.

If you’re starting from scratch, you will minimally need the following equipment for your IT shop:

  1. Half rack at a reliable ISP with sufficient bandwidth to support your needs
  2. Two good firewalls
  3. One hardware load balancer
  4. Two good GB Ethernet switches
  5. Six solid, commodity business servers (we will accept degraded performance on the 15th day)

For the cloud option, you will need just a few virtual instances:

  1. One medium 32-bit instance
  2. Four large 64-bit instances during standard usage, scaled to meet peak demand at 8

In addition, you need software and services. Assuming an entirely open source environment, your software and services costs will consist of time to set up the environments, monitoring services, support contracts, and labor for managing the environment. Table below lays out all of the expected up-front and ongoing costs.

For each option, calculate the present value of your monthly payments and add in any up-front costs:

  1. Internal: = (–PV(10%/12,36,1900,0)) + 53200 = $112,083.34
  2. Cloud: = (–PV(10%/12,36,3900,0)) + 1200 = $94,452.63

Not only is the cloud cheaper, but the payment structure of the cloud versus up-front investment saves you several thousand dollars.

The final point to note is that you can use the $112,083.34 and $94,452.63 numbers to help you understand how much money these systems need to generate over three years in order to be profitable (make sure that calculation is also using today’s dollars).

Where the Cloud Saves Money

Cost savings in the cloud become significant, and even reach absurd levels, as your variance increases between peak and average capacity and between average and low capacity.

My company has an extreme example of a customer that has very few unique visitors each day for most of the year. For about 15 minutes each quarter, however, they have the equivalent of nearly 10 million unique visitors each month hitting the website.

Obviously, purchasing hardware to support their peak usage (in other words, for 1 hour per year) would be insanely wasteful. Nevertheless, they don’t have the option of operating at a degraded level for that one hour each year.

The cloud is the perfect solution for them, as they can operate with a very baseline infrastructure for most of the year and scale up for a few minutes each quarter to support their peak demand.

A common and relatively straightforward set of cost savings lies in the management of nonproduction environments—staging, testing, development, etc. An organization generally requires these environments to be up at certain points in the application development cycle and then torn down again.

Furthermore, testing requirements may demand a full duplication of the production environment. In the cloud, you can replicate your entire production infrastructure for a few days of testing and then turn it off.

Find Us On Facebook

Computer Basics


C Programming


Java Tutorial


Data Structures


MS Office


Database Management