The Organizational Challenge

One of the major challenges when looking into cloud architectures is the organizational/process shifts required to make the transition.  Technology refreshes seem daunting but changing organizational structure and internal auditing/change management can make rip-and-replace seem like child’s play.  In this post  I’ll discuss some ways in which to simplify the migration into cloud (there’s a vaporize your silos pun hidden around here somewhere.)  For more background see my post on barriers to adoption for cloud computing (

There are several ways in which companies can begin the process of migrating into the cloud and preparing their IT organization for the transition.  These same principles can be applied to each cloud architecture type and to the concept of data center virtualization.  In order to properly the first step is defining a cloud strategy:

Cloud Strategy:

Cloud strategies will be unique per company but should include the following (not an all inclusive list):

  • Migration goal.  This should be based on the ROI calculations driving the move to cloud.
  • Defined timeline complete with checkpoints and dates.  Timelines for this type of transition will most likely be multi-year, ranging from 3-10.
  • Type(s) of cloud architectures being considered and used.
  • Staged approach outline defining the migration flow including details of which apps will be moved when where.
  • Risk assessment for each piece of the plan and the plan as a whole.  If the migration could end up costing you more than the ROI will buy you it’s time to rethink.

With strategy in hand you can now begin planning the organizational migrations that will be required to make the  move to cloud computing.  The first step is a history lesson (you should never move forward without first looking backward.)

Our data center has a sordid history which is often forgotten because it all occurs in a short lifespan of about 30 years.  We scaled out from main frames to commodity hardware, then up to dense hardware, then virtualized to repair utilization problems and ended up in our current mess.

During that process we’ve built large technology silos and tailored our organizations to them.  We’ve actually built our processes around the technology mistakes or oversights we’ve made.  We’ve architected siloed organizational structures to marry our departmental or technological silos. Breaking those silos is not an easy task but it is key to moving forward.


You can not and will not break out of technological silos without first breaking organizational silos.

Organizational change cannot be an instantaneous thing in most companies.  Even when it could be, it’s best to err on the side of caution.  Assess your goals, reference your strategy and plan the changes to break the silos and bond the data center teams.

Some short-term suggestions for long-term results:

  • Place Network and Storage teams under common management.
    • Do this as close to the administrators as possible.  Regardless of technology the storage network and traditional data network will converge.  By consolidating management you will begin to build cohesion and knowledge base prior to technology changes.
  • Cross-train your MVPs.
    • Training is key to developing and maintaining the best, but cross-training is key to moving forward.  Take the best from each silo and train them across a second silo, possibly even going so far as to having them temporarily swap roles.  Each contributor needs a strong understanding of what their cross-department colleagues need.
  • Promote ingenuity.
    • Most organizations will have staff adverse to any change because they don’t understand it and or want to learn something new.  Many people feel they can cling to the past as long as possible and will do quite a lot to do so.  Encourage innovation and education within your organization, promote the embrace of new ideas and technologies.  Test new concepts in limited environments to ensure they work for your company.
  • Analyze budget process.
    • If the silos in your organization each own their own budget consider moving budget further up the chain.  I/O consolidation is a great example of this.  If you choose to consolidate networks which budget is responsible?  Prepare your budgets for data center structural changes.


These are just a few broad concepts to expedite the planning of your organizations move to the cloud.  Overall cloud will be no more of a rip-and-replace of your data center than a rip-and-replace of your organization, it’s as gradual a progression as you plan, so plan it well.

GD Star Rating


I came across a blog recently that peaked my interest.  The post was from Nate at TechOpsGuys ( and it purports to explain the networking deficiencies of UCS.  The problem with the posts explanation is that it’s based off of The Tolly Report on HP vs. UCS ( which has been shown to be a flawed test funded by HP.  Cisco was of course invited to participate, but this is really just lip service as HP funded the project and designed the test in order to show specific results, typically vendor’s will opt out in this scenario.

There were three typical reactions from the Tolly Report:

  • The HP fan/Cisco bigot reaction:
    • ‘Wow Cisco fails’
  • The unbiased non-UCS expert:
    • ‘There is no way something that biased can be accurate, let me contact my Cisco rep for more info’ (This is not an exaggeration)
  • The Cisco UCS expert:
    • ‘Congratulations, you proved that a 10GE link carries a max of 10GE of traffic, too bad you missed the fact that Cisco supports active/active switching.’ Amongst other apparent flaws.

The TechOpsGuys post mentioned above will have the same types of reactions.  Lover’s of HP will swallow it whole heartedly, major Cisco fans will write it and TechOpsGuys off, and the unbiased will seek more info to make an informed decision.

I initially began writing a response to the post, but stopped short when I realized two things:

  • It would take a lengthy blog to point out all of the technical errors, and incorrect assumptions.
  • It wouldn’t make a difference, Nate has already made up his mind, and anyone believing the blog whole heartedly would have as well.

Nate is admittedly biased towards Cisco and has been for 10 years according to the post.  Nate read the Tolly report and assumed it was spot on because he already believes that Cisco makes bad technology.  Nate didn’t take the time to fact check or do research, he just regurgitated bad information.

This is not a post about Nate, or about HP vs. Cisco, it’s about objectivity.  As IT professionals it’s easy to get caught up in the vendor wars, but unless you’re a vendor it’s never beneficial.  Everyone will have their favorites but just because you prefer one over the other doesn’t mean you should never look at what the other vendor is doing.

If you’re a consultant, reseller, integrator, or customer you’re most powerful ally is options.  Options to choose best-of-breed, option to price multiple vendors, option to switch vendors when it suites your customer.  Throwing away an entire set of options due to a specific vendor bias is a major disadvantage.  Every major vendor has some great products, some bad products, and some in the middle.  Every major vendor plays marketing games, and teases with roadmaps.  It’s part of the business.

If a major vendor makes a market transition into a new area it’s beneficial to just about everyone.  The product itself may be a better fit for the customer, the new product may force price drops in existing vendors products, the new product may drive new innovation into the field which will shortly be adopted by the existing vendors.  The list goes on.


As IT professionals objectivity is one of our key strengths, sacrifice it due to bias and your making a mistake.  When you see blogs, articles, reports, tests that emphatically favor one product over another take them with a grain of salt and do your own research.

If you have engineer in your title or job role you shouldn’t be making major product decisions based on feelings, PowerPoint, or PDF.  Real hands on and raw data (with a knowledge of how the data was gathered and why) are key tools to making informed decisions.

GD Star Rating

Cloud Types

Within the discussion of cloud computing there are several concepts that get tossed around and mixed up.  Part of the reason for this is that there are several cloud architecture types.  While there are tons of types and sub-types discussed I’ll focus on four major deployment models here: Public Cloud, Private Cloud, Community Cloud and Hybrid Cloud.  Each cloud type can be used to deliver any combination of XaaS.  The key requirements to be defined as a cloud architecture are:

  • The ability to measure the service being provided
  • Broad Network Access
  • Self-Service
  • Resource Pooling
  • Elasticity

I’ve discussed the business drivers for a transition to cloud in a previous post ( and the technical drivers here (

Public Clouds:

According to NIST with Public Clouds ‘The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services’ (  This is the service model for cloud computing, A company owns the resources that provide a service and sell that service to other users/companies.  This is a similar model to the utilities, companies pay for the amount of: infrastructure, processing, etc. that is use.  Examples of Public Cloud providers are:

  • Amazon Web Services
  • Rackspace
  • Newservers
  • Verizon
  • Savvis

These and more can be found on Search Cloud Computing’s Top 10 list (


 Private Clouds:

NIST defines the Private Cloud as: ‘The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.’

Private clouds are data center architectures owned by a single company that provide flexibility, scalability, provisioning, automation and monitoring.  The goal of a private cloud is not to sell XaaS to external customers but instead to gain the benefits of a cloud architecture without giving up the control of maintaining your own data center.  Typical private cloud architectures will be built on a foundation of end-to-end virtualization, with automation, monitoring, and provisioning tools layered on top.  While not in the definition of Private Clouds bear in mind that security should be a primary concern at every level of design.

There are several complete Private Cloud offerings from various industry leading vendors.  These solutions typically have the advantages joint testing, and joint support among others.  That being said Private Clouds can be built on any architecture you choose.


Community Clouds:

Community Clouds are when an ‘infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise’ according to NIST.

A community cloud is a cloud service shared between multiple organizations with a common tie.  These types of clouds are traditionally thought of as farther out in the timeline of adoption.


Hybrid Clouds:

So while you can probably guess what a hybrid cloud is I’ll give you the official NIST definition first: ‘The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds).

Using a Hybrid approach companies can maintain control of an internally managed private cloud while relying on the public cloud as needed.  For instance during peak periods individual applications, or portions of applications can be migrated to the Public Cloud.  This will also be beneficial during predictable outages: hurricane warnings, scheduled maintenance windows, rolling brown/blackouts.



When defining a cloud strategy for your organization or customer’s organization it is important to understand the different models and the advantages each can have for a given workload.  No cloud model is mutually exclusive and many organizations will be able to benefit from more than one model at the same time.

Defining a long term vision now and developing a staged migration path to it with set timelines will help ease the transition into cloud based architectures and allow a faster ROI.

When Cloud Goes Bad:


GD Star Rating

Post defining VN-Link

For the Cisco fans or those curious about Cisco’s VN-Link see my post on my colleagues Unified Computing Blog:

GD Star Rating

Fibre Channel over Ethernet

Fibre Channel over Ethernet (FCoE) is a protocol standard ratified in June of 2009.  FCoE provides the tools for encapsulation of Fibre Channel (FC) in 10 Gigabit Ethernet frames.  The purpose of FCoE is to allow consolidation of low-latency, high performance FC networks onto 10GE infrastructures.  This allows for a single network/cable infrastructure which greatly reduces switch and cable count, lowering the power, cooling, and administrative requirements for server I/O.

FCoE is designed to be fully interoperable with current FC networks and require little to no additional training for storage and IP administrators. FCoE operates by encapsulating native FC into Ethernet frames.  Native FC is considered a ‘lossless’ protocol, meaning frames are not dropped during periods of congestion.  This is by design in order to ensure the behavior expected by the SCSI payloads.  Traditional Ethernet does not provide the tools for lossless delivery on shared networks so enhancements were defined by the IEEE to provide appropriate transport of encapsulated Fibre Channel on Ethernet networks.  These standards are known as Data Center Bridging (DCB) which I’ve discussed in a previous post (  These Ethernet enhancements are fully backward compatible with traditional Ethernet devices, meaning DCB capable devices can exchange standard Ethernet frames seamlessly with legacy devices.  The full 2148 Byte FC frame is encapsulated in an Ethernet jumbo frame avoiding any modification/fragmentation of the FC frame.

FCoE itself takes FC layers 2-4 and maps them to Ethernet layers 1-2, this replaces the FC-0 Physical layer, and FC-1 Encoding Layer.  This mapping between Ethernet and Fibre Channel is done through a Logical End-Point (LEP) which can by thought of as a translator between the two protocols.  The LEP is responsible for providing the appropriate encoding and physical access for frames traveling from FC nodes to Ethernet nodes and vice versa.  There are two devices that typically act as FCoE LEPs: Fibre Channel Forwarders (FCF) which are switches capable of both Ethernet and Fibre Channel, and Converged Network Adapters (CNA) which provide the server-side connection for a FCoE network.  Additionally the LEP operation can be done using a software initiator and traditional 10GE NICs but this places extra workload on the server processor rather than offloading it to adapter hardware.

One of the major advantages of replacing FC layers 0-1 when mapping onto 10GE is the encoding overhead.  8GB Fibre Channel uses an 8/10 bit encoding which adds 25% protocol overhead, 10GE uses a 64/64 bit encoding which has about 2% overhead, dramatically reducing the protocol overhead and increasing throughput.  The second major advantage is that FCoE maintains FC layers 2-4 which allows seamless integration with existing FC devices and maintains the Fibre Channel tool set such as zoning, LUN masking etc.  In order to provide FC login capabilities, multi-hop FCoE networks, and FC zoning enforcement on 10GE networks FCoE relies on another standard set known as Fibre Channel initialization Protocol (FIP) which I will discuss in a lter post.

Overall FCoE is one protocol to choose from when designing converged networks, or cable-once architectures.  The most important thing to remember is that a true cable-once architecture doesn’t make you choose your Upper Layer Protocol (ULP) such as FCoE, only your underlying transport infrastructure.  If you choose 10GE the tools are now in place to layer any protocol of your choice on top, when and if you require it.

Thanks to my colleagues who recently provided a great discussion on protocol overhead and frame encoding…

GD Star Rating

What is the biggest barrier to your move into the cloud?

Take the poll:

GD Star Rating

What's Stopping cloud?

So with everyone talking about cloud and all of the benefits of cloud computing why isn’t everyone diving in?  The barriers to adoption can be classified into three major categories: Personal, Technical, and Business.

Personal Reasons:

Personal barriers to cloud adoption are broad ranging and can be quite difficult to overcome.  Many IT professionals have fears of job loss and staff reduction as things become more centralized or moved to a service provider.  In some ways this may very well be true.  If more and more companies increase IT efficiency and outsource applications and infrastructure there will be a reduction in the necessary work force, that being said it won’t be as quick or extreme as some predict in the sky is falling books and blogs.  The IT professionals that learn and adapt will always have a place to work, and quite possibly a bigger paycheck for their more specialized or broader scope jobs. 

Additionally human beings tend to have a natural fear of the unknown and desire to stay within a certain comfort zone.  If you’ve built your career in a siloed data center cloud can be a scary proposition.  You can see this in the differences of IT professionals that have been in the industry for varying amounts of time.  Many of those who started their career in main frames were tough to push into distributed computing, those that started in distributed computing had issues with server virtualization, and those who built a career in the virtualized server world may still have issues with pushing more virtualization into the network and storage.  Overall we tend to have a level of complacency that is hard to break.  To that point I always think of a phrase we used in the Marines ‘Complacency Kills’ in that environment it was meant quite literally, in a business environment it still rings true ‘Complacency kills business.’  A great example of this from the U.S. market is the Kroger grocery stores catapult to greatness.  When grocery stores were moving from small stores to ‘super stores’ the retail giant at the time A&P opened a super store which was far more succesful than its other stores.  Rather than embracing this change and expanding on it A&P closed the store for fear of ruining their existing market.  Kroger on the other hand saw the market shift and changed existing stores to superstores while closing down stores that couldn’t fit the model.  This ended up launching Kroger to the number one grocery store in the U.S.

Technical Reasons:

Technical barriers to adoption for cloud also come in many flavors, but on the whole the technical challenges are easier to solve.  Issues such as performance, security, reliability, and recovery are major concerns for cloud adoption.  Can I trust someone else to protect and secure my data?  The answer to that question in most cases is yes, the tools all exist to provide secure environments to multiple tenants.  These tools exist at all sizes from the small enterprise (or smaller) to the global giants.  When thinking about the technical challenges take a step back from how good you are at your job, how good the IT department is, or how great your data center is, and think about how much better you’d be if that was your businesses primary focus?  If I made widgets as a byproduct of my primary business my widgets would probably not be as good, or as low a cost as a company that only made widgets.  If your focus was data center and your company was built on providing data centers you’d be better at data center.  co-location data centers are a great example of this.  The majority of companies can’t afford to run a Tier III or IV data center but could definitely benefit from the extra up-time.  Rather than building their own they can host equipment at a colo with the appropriate rating and in most cases save overall cost over the TCO of data center ownership.

Business Barriers:

Business barriers can be the most difficult to solve.  The majority of the business challenges revolve around the idea of guarantees.  What guarantees do I have that my data is: safe, secure, and accessible?  Issues like the Microsoft/T-Mobile sidekick fiasco bring this type of issue to the spotlight.  If I pay to have my business applications hosted what happens when things fail?  Currently hosted services typically provide Service Level Agreements (SLA) that guarantee up-time.  The issue is that if the up-time isn’t met the repercussion is typically a pro-rated monthly fee or repayment of the service cost for the time by the provider.  To put that in perspective say you pay 100K a month to host your SAP deployment which directly affects a 20 million dollars per month in sales.  If that hosted SAP deployment fails for a week it costs you 5 million dollars, receiving a refund of the 100K monthly fee doesn’t even begin to make up for the loss.  The 5 million dollar loss doesn’t even begin to take into account the residual losses of customer satisfaction and confidence.

The guarantee issue is one that will definitely need to be worked out, tested, and retested.  The current SLA model will not cut it for full-scale cloud deployments.  One concept that might ease this process would be insurance, that’s right cloud insurance.  For example as a cloud service provider you hire an insurance company to rate your data centers risk, and ensure your SLAs against the per minute value of each customers hosted services/infrastructure.  This allows you to guarantee each customer an actual return on the lost revenue in the event of a failure.  Not only is the cloud provider protected but the customer now has the confidence that their actual costs will be paid if the SLA is not met.

Overall none of the challenges of cloud adoption are show stoppers, but the adoption will not be an immediate one.  The best path to take as a company is to start with the ‘low hanging fruit.’  For instance if you’re looking at using cloud services, try starting with something like email.  Rather than run your own email servers use a hosted service.  Email is a commoditized application and runs basically the same in-house or out, most companies are spending unneeded money running their own email infrastructure because that’s what they’re used to.  The next step up may be to use hosted infrastructure, co-location, or services for disaster recovery (DR) purposes.

Another approach to take is my personal favorite.  Start realizing the power of cloud infrastructures in your own data center.  Many companies are already highly utilizing the benefits of server virtualization but missing the mark on network and storage virtualization.  Use end-to-end virtualization to collapse silos and increase flexibility.  This will allow the IT infrastructure to more rapidly adapt to immediate business needs.  From there start looking at automation technologies that can further reduce administrative costs.  The overall concept here is the ‘Private Cloud’ also sometimes called ‘Internal Cloud.’  This not only has immediate business impact but also provides a test bed for the value of cloud computing.  Additionally once the data center workload is virtualized on a standard platform it’s easier to replicate it or move it into hosted cloud environments.

Most importantly remember moving to a cloud architecture is not an instantaneous rip-and-replace operation it’s a staged gradual shift.  Make the strategic business decision to move towards cloud computing and move towards that path over an alloted time frame with tactical decisions that coincide with your purchasing practices and refresh cycles.  Cloud doesn’t have to be a unantainable goal or mystery, utilize independent consultants or strong vendor ties to define the long-term vision and then execute.

GD Star Rating

Data Center Bridging Exchange

Data Center Bridging Exchange (DCBX) is one of the components of the DCB standards.  These standards offer enhancements to standard ethernet which are backwards compatible with traditional Ethernet and provide support for I/O Consolidation (  The three purposes of DCBX are:

Discovery of DCB capability:

The ability for DCB capable devices to discover and identify capabilities of DCB peers as well as identify non-DCB capable legacy devices.  You can find more information on DCB in a previous post (

Identification of misconfigured DCB features:

The ability to discover misconfiguration of features that require symmetric configuration between DCB peers.  Some DCB features are asymmetric meaning they can be configured differently on each end of a link, other features must match on both sides to be effective (symmetric.)  This functionality allows detection of configuration errors for these symmetric features.

Configuration of Peers:

A capability allowing DCBX to pass configuration information to a peer.  For instance a DCB capable switch can pass Priority Flow Control (PFC) information on to a Converged Network Adapter (CNA) to ensure FCoE traffic is appropriately tagged and pause is enabled for the chosen Class of Service (CoS) value.  This PFC exchange is a symmetric exchange and must match on both sides of the link.  DCB features such as Enhanced Transmission Selection (ETS) otherwise known as bandwidth management can be configured asymmetrically (different on each side of the link.)

DCBX relies on Link Level Discovery Protocol (LLDP) in order to pass this information and configuration.  LLDP is an industry standard version of Cisco Discovery Protocol (CDP) which allows devices to discover one another and exchange information about basic capabilities.  Because DCBX relies on LLDP and is an acknowledged protocol (2 way communication) any link which is intended to support DCBX must have LLDP enabled on both sides of the link for Tx/Rx.  When a port has LLDP disabled for either Rx or Tx DCBX is disabled on the port and DCBX Type Length Values (TLV) within received LLDP frames will be ignored.

DCBX capable devices should have DCBX enabled by default with the ability to administratively disable it.  This allows for more seamless deployments of DCB networks with less tendency for error.

GD Star Rating