<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1078844192138377&amp;ev=PageView&amp;noscript=1">


From Infrastructure to Workloads. What We're Talking About Today

Three years ago we were asked a relatively simple question 

"Can you get me out of the infrastructure business?"  

The answer to this question was a function of migrating applications and infrastructure from a customer-site, customer-managed environment to ServerCentral managed infrastructure located in a ServerCentral managed data center. Simple enough. Basic migrations that sometimes remained on bare metal, and sometimes transitioned to fully virtualized environments. Private cloud at its finest, if you will. 

Today, however, we are asked a very different question, one that isn't anywhere near as simple, 

"Where should I put each workload to optimize performance, maximize flexibility / agility / ability to scale, minimize cost and be sure my security / compliance requirements are addressed?" 

The answer to this question is a function of significantly more analysis, assessment and strategy. 

Why do we bring this up? Another good question. 

We're bringing this topic up because it reflects the natural evolution of ServerCentral – helping companies by providing the right infrastructure for their applications, available in the right places at the right times in order to help them realize the right results for their business. 

Just a few years ago helping our customers was typically about a single migration from location A to location B. Today, helping our customers means having an ever increasing foundation upon which we can architect, deliver, manage and scale solutions on their behalf.  

What does this mean for you? 

This means we're going to be asking a lot more questions … but it is all part of making sure that you have exactly what you need, where you need it, to achieve your objectives. 

Since ServerCentral is a services company, we are continually working to be in the best possible position to enable your organization with all of the infrastructure elements needed, without making your organization reliant upon any one hardware, network or cloud platform.

Topics: Cloud Infrastructure Migration

How Much Cloud Do I Really Need?

We see it all the time: A company with 50 servers moves to the cloud by creating 50 instances, one for each physical server. The thinking goes that if I’m using this much physical infrastructure, I’ll need this much cloud infrastructure. Simply convert servers to instances, and just like that, I’ve moved to the cloud.

It's a logical approach, but it's wrong.

Often, when we’re migrating customers to the cloud, we find ourselves in the odd position of bargaining them down. While they’re using 50 servers today, we only see a need for, say, 35 cloud instances to deliver the same service levels and achieve the same objectives with a higher level of system performance. It’s very likely the move doesn’t require a one-to-one switch from physical servers to cloud instances. Optimizing infrastructure is the fastest way to help our customers realize the benefits of the cloud. If you’re thinking about making the switch to the cloud—or if you’re already there and find yourself receiving larger bills than you expected—here’s what you need to be thinking about.

The No. 1 mistake companies make when moving to the cloud

Rightsizing your infrastructure is a critical step in successfully moving to the cloud—and one we see companies skip all the time. The reality is that in most organizations, servers are wildly underutilized. Take a company we worked with that was running three data centers around the world. The company wanted insight into, and eventually control over, its spending. The C-suite simply didn’t know what they were running. After a detailed assessment of the operational and technical environments, we found that the company’s three data centers full of servers were running at an average utilization rate of 8 percent.

8 percent!

Unfortunately, this happens all the time. Enterprise IT departments are often stretched too thin to give the job the time it needs—let alone take advantage of constantly changing technologies. As a result, companies frequently end up with a collection of infrastructure they don’t need, and more equipment is added to the pile every time there’s a request for more capacity. For strapped IT teams, this is the easiest and most direct course of action. The costs of this model are a capital expense nightmare, and the complexity benefits no one.

This situation only gets worse when the same IT team is asked to migrate the company to the cloud. Keeping up with cloud technologies is a full-time job. In ServerCentral’s case, we have a whole team dedicated to identifying and adopting cloud innovations and best practices. Overtaxed IT departments simply don’t have the resources to keep up. The fastest way for them to check the box of getting into the cloud is to take a one-to-one approach—moving each server to a cloud instance. The problem is they end up duplicating the sizing of the existing infrastructure instead of optimizing it, robbing them of a shot at cost savings. Every time there’s a new need, another cloud instance is added, and the costs and complexity of managing the environment continue to increase. When the company gets hit with a massive monthly bill for cloud resources, the exec team’s left running a cost comparison between physical and cloud infrastructure, trying to understand how they ended up paying more, without ever seeing a benefit. We have this conversation with companies every single day.

Physical Servers vs. Cloud: Why it isn’t one-to-one

The first challenge to understanding cloud is recognizing that physical infrastructure does not equal virtual infrastructure. If a company has hundreds of physical servers that are underutilized, in a virtual environment that’s going to collapse down to maybe two virtualized servers each running a number of virtual machines.

Physical infrastructure is typically siloed—but the cloud isn’t. When ServerCentral looks to move a customer from physical infrastructure to the cloud, we’re analyzing the cloud as a system of components, rather than assessing each individual element. The cloud’s ability to quickly move applications and data across components prepares the business for scale and opens it up to opportunities for innovation. 

To convey the benefits of cloud, we ask people to think of their physical IT infrastructure as individual Lego bricks. Each piece stands alone, executes certain functions, and holds a certain amount of information. Not that useful by itself, and certainly not a very good toy. The cloud lets you start stacking these bricks. Now, instead of being stuck on individual bricks, information can flow between pieces. One workload that takes up 25 percent of a brick’s capacity can join another workload that takes up 10 percent and another that takes up 15 percent. Like the old defragmentation programs you’d run on your PC, the workloads can compress into the smallest possible space, freeing up bricks and increasing the efficiency of your infrastructure.

How much cloud do I really need?

A move to the cloud should be an opportunity to assess current utilization and true infrastructure needs, then build for these requirements instead of repeating past mistakes. Moving 50 servers straight to 50 cloud instances will, technically, get a company into the cloud, but it doesn’t take advantage of the cloud’s true potential for elasticity and scalability. It doesn’t even provide the expected cost benefits.

To make sure our customers actually realize this initial advantage of the cloud, instead of just moving there, we use tools that map server and storage utilization to cloud resources. This way we can see how needs change in a connected environment and assess the compute, memory and storage utilization, as well as the latency, across all instances, not just each individual one. Instead of deciding how much cloud a company needs by looking at how many physical servers it’s running, we analyze the amount of data it has and what it needs to do with that data. This helps our customers achieve the first, most basic benefit of the cloud—cost efficiency—by ensuring they’re not buying more cloud than they need.

To realize all of the potential of the cloud, there are more steps to take—the biggest one being application optimization. But making sure you have a thoughtful virtual infrastructure in place that fits your company’s needs will position you to take advantage of those other benefits when the time comes. And it will be a vast efficiency and cost improvement over your legacy physical infrastructure.

The benefits of the cloud can seem almost mythic. And when virtual environments are treated the same way as physical environments, those benefits will continue to be a myth. But if you treat your move to the cloud as an opportunity to get your infrastructure needs right, you’ll set yourself up for cost savings in the present and more efficient capacity management as your business grows.

For more insight into how much cloud your business needs, schedule a meeting with me.

Tom Kiblin

Topics: Cloud

What is Next for Your Cloud Project

In my previous post, Is ‘Why?’ the Most Important Cloud Question?Is ‘Why?’ the Most Important Cloud Question?, I discussed the importance of knowing Why you’re moving to the cloud as a critical success factor for your cloud project.

One of the questions I received in response to the post was, “Once you can answer the question why you’re moving to the cloud, what’s next?”

Exactly. What is next.

At ServerCentral, the second step in a successful cloud project, after answering Why, is What. We formally call this phase Identification, but it is answering the question, “What are you moving to the cloud?”

Identification (or What) is the process of developing a complete understanding of each of the applications within your organization and whether or not they are in play for cloud consideration. This may sound trivial but it is time very well spent. Not having this complete list of applications that will potentially be moving to the cloud will quickly undermine a successful cloud project as inter-app dependencies (and internal negotiations on prioritization) will inevitably delay your timeframe. These delays are extremely expensive as other projects await completion of the cloud projects before they can proceed.

To ensure your cloud project gets off to a smooth start, stay ahead of this situation by quickly assembling the master list of applications that are in play. Note which applications are already virtualized and their dependencies.

When it comes time to actually execute the cloud migration, you’ll know Why you’re doing it and What you’re doing. Hard to argue with that.

Topics: Cloud

Is “Why?” the Most Important Cloud Question?

The question today isn't IF you are moving to the cloud.

Everyone is already in the process of moving to the cloud, or will be in very short order. There are strategic, operational and human capital reasons for this transition - and there is no slowing it down.

The real question is WHY are you moving to the cloud?

  • Is it a business objective?
  • Is it a financial objective?
  • Is it a technical requirement?
  • Is it to provide stronger opportunities for your IT team to learn new skills and stay engaged with your organization?
  • Is it to save money?
  • Are you looking to increase agility?
  • Do you want to get out of the IT infrastructure business?
  • Are you expanding geographically / internationally?

“Why?” is a much more difficult question than most people and organizations recognize. All too often no one bothers to define the success criteria for a cloud project. The criteria is often implied, yet rarely clearly communicated across the organization.

We have managed and supported thousands (and thousands) of cloud projects and the inability to define a project’s ultimate goal, the answer to why, is always the reason a project takes longer than it should.

The cloud is supposed to be easy, quick and, ideally, cost effective. In too many cases, it is none of these.

What is your Why?

Topics: Virtualization Cloud

An Introduction to ServerCentral’s Enterprise Cloud

Part I: The Basics

ServerCentral’s enterprise cloud utilizes VMware’s vSphere platform. Powered by vCloud Director, we offer on-demand, self-service Enterprise Cloud services. For those most familiar with VMware private clouds (think ESXi, vCenter, etc.), managing cloud infrastructure from vCloud Director is a fundamentally different way of thinking. No longer do you have to worry about hardware, hypervisors, or maintenance. Our intent is to offer peace of mind that is seldom found in the IT world. 

Our enterprise cloud is architected to offer flexibility, convenience and the much sought-after single pane of glass.

Understanding how our Enterprise Cloud functions is the key to utilizing the platform to its highest potential. In this first part of our Enterprise Cloud series we will discuss how our platform is organized and how to spin up your first virtual machines in the cloud.

 Understanding the vCloud Director Hierarchy

For most users, their exposure to vCloud Director begins when they first login and access the web-based portal. It is here that they they are presented with an overarching view of their infrastructure. It is also here that you will create vApps, provision virtual machines, and manage your cloud resources. The good news is that it’s all in one place. The bad news is that not much thought is put into how these resources are aligned.

vCloud Director is a very hierarchical platform in all senses of the word. Customers are assigned to the platform as an “organization” which is comprised of varying levels of resources and user management. Organizations are further divided into “virtual data centers” (or VCDs for short). One organization can have multiple virtual data centers if they like. This granular approach allows for centralized management from the previously mentioned single pane of glass. Virtual data centers are also further divided into vApps (virtual applications), edge gateway services and any number of unique network configurations. This detailed hierarchy allows our customers to deploy their infrastructure in the most flexible and sensible manner possible – and to do so within the construct of the best possible best practices.

Think Inside the Box

Many virtual environments are deployed with virtual machines in a configuration where they are in a standalone configuration. This creates single VMs running applications independently from each other with no shared dependencies or policies. vCloud Director takes a different route in the deployment of virtual machines. vCloud Director is architected based on the application tiering model. In this configuration, organizations create virtual applications, or vApps, that contain virtual machines. Typically vApps are used to provide the flexibility to create service levels and policies based on dependency and tiering requirements. All applications need not be created equal.

Take a large cardboard box for example. In this box (your virtual data center) you could place all of your valuables (virtual machines) together. While convenient at first, this becomes a disorganized mess to sort through as more and more valuable are added. Using smaller boxes (vApps), you could separate these valuables along logical lines for better organization and management within the larger box.

With this understanding in mind, let’s login and create an initial vApp in the cloud.

Logging Into vCD and Spinning up a vApp

Every customer receives a unique vCloud Director login for their Enterprise Cloud. It will follow this format:


If you are unsure of your Enterprise Cloud login, please contact us so that we can get you to the right address! Once you have it, logging in and setting up a vApp is a simple and straight-forward process.

1/ Login with the credentials provided:


2/ Once logged in you will see your organization’s default home screen. This shows you the status of various vApps and resources available in your Enterprise Cloud. From here you can navigate around to manage the environment.


3/ Setting up your first vApp is simple. For the sake of this tutorial, we will create a new vApp from scratch. On the right side of the home screen, click on “Build new vApp”. There are other ways to deploy vApps such as from templates and OVFs, but that is a discussion for another time. For now, we’ll continue to keep it simple.

4/ A new window will pop up asking for details for the new vApp. You will need to give it a name, a description (optional), choose which virtual data center it should be in and modify the lease times. For this first vApp deployment, the defaults are recommended.


5/ The next screen is where you can deploy a new VM with the creation of the vApp. We normally recommend setting up at least one VM with the vApp so it completes the process all at once. Click on the “New Virtual Machine” button to begin this part of the setup process.


6/ Configure all the settings for the VM as you need them. You can give it a name, assign compute and memory resources, choose which hardware version (VCD defaults to HW v9), and a few other options. Most of the options are customizable, but we recommend that some of the options be setup as follows:

a/ Expose hardware-assisted CPU virtualization to guest OS: Unchecked
b/ Bus Type: “LSI Logic SAS (SCSI)"


Exposing CPU virtualization to the guest allows you to run nested hypervisors, and other applications requiring HW virtualization on the CPUs. “LSI Logic SAS (SCSI)” bus type provides better performance on most guest operating systems. However, some older operating systems may need to use older emulation. Paravirtualized SCSI buses may also be used. However, please note that there are limited OSes that can use them. There may be a slight performance gain, depending upon the use case.

If you are unsure what configuration is best for you, please ask.

That’s what we’re here for.

7/ Once the VM configuration is finished on this page, proceed to the next section of the vApp creation. Here you will configure the storage policy, which in most cases will be the default storage policy.


8/ The next section of the configuration asks you to specify the initial networking settings for the VM. Make sure to choose the right network for the VM. You may leave the other settings as the defaults.


9 / There is a second networking screen that allows you to enable a couple of advanced networking settings. For now, let’s skip this as they are not needed in the initial configuration. Click “Next” to continue.


10/ The last part of the process is to verify the configuration and finish building the vApp. Let’s click on “Finish”.


11/ Once the vApp customization is done, you will see that the vApp and VM are now being created on the home screen.


Once the vApp and VM are created, you are done with the initial configuration of your first vApp! At this point it is common to begin the installation of the OS onto the virtual machine.

If you found this valuable, please stay tuned. Part II will cover how to upload, mount, and install from an ISO and take a more detailed dive into VM management.

Topics: Cloud VMware