Why You’re Ready to Create a Private Cloud

I’m catching up on my reading and ran into David Linthicum’s ‘Why you’re not ready to create a private cloud’ (http://www.infoworld.com/d/cloud-computing/why-youre-not-ready-create-private-cloud-458.)  It’s a great article and points out a major issue with private-cloud adoption – internal expertise.  The majority of data center teams don’t have the internal expertise required to execute effectively on private-cloud architectures.  This isn’t a knock on these teams, it’s a near impossibility to have and maintain that internal expertise.  Remember back when VMware was gaining adoption.  Nobody had virtualization knowledge so they learned it on the fly.  As people became experts many times they left the nest where they learned it in search of bigger better worms.  More importantly because it was a learn-as-you-go process the environments were inherently problematic and were typically redesigned several times to maximize performance and benefit.

Looking at the flip side of that coin, what is the value to the average enterprise or federal data center in retaining a private cloud architect?  If they’re good at their job they only do it once.  Yes there will be optimization and performance assessments to maintain it, but that’s not typically a full time job. The question becomes:  Because you don’t have the internal expertise to build a private cloud should you ignore the idea or concept?  I would answer a firm no.

The company I work for has the ability, reseller agreements, service offerings and expertise to execute on private clouds.  We’re capable of designing and deploying these solutions from the data center walls to the provisioning portals with experts on hand that have experience in each aspect, and enough overlap to tie it all together.  To put our internal capabilities in perspective one of my companies offerings is private cloud containers and ruggedized deployable private cloud racks.  These aren’t throw some stuff in a box solutions they are custom designed containers outfitted with shock absorption, right-sized power/cooling, custom rack rails providing full equipment serviceability and private cloud IT architectures built on several industry leading integrated platforms. That’s a very unique home grown offering for a systems integrator (typically DC containers are the space of IBM, Sun, etc.)  I accepted this position for these reasons, among others. 

This is not an advertisement for my company but instead an example of why you’re ready to build private cloud infrastructures.  You should not expect to have the internal expertise to architect and build a private cloud infrastructure, you should utilize industry experts to assist with your transition.  There are two major methods of utilizing experts to assess, design, and deploy a private cloud: a capable reseller/solutions provider or a capable consultant/consulting firm.  Both methods have pros and cons.

Reseller/Systems Integrator:

Utilizing a reseller and systems integrator has some major advantages in the form of what is provided at no cost and having a one stop shop for design, purchase, and deployment.  Typically when working with a reseller much of the upfront consulting and design is provided free, this is because it is considered pre-sales and the hardware sale is where they make their money.  With complex systems and architectural designs such as Virtual Desktop Infrastructures (VDI) and cloud architectures don’t expect everything to be cost free, but good portions will be.  These type of deployments require in depth assessment and planning sessions, some of which will be paid engagements but are typically low overall cost and vital to success.  For example you won’t deploy VDI successfully without first understanding your applications in depth.  Application assessments are extended technical engagements.

Another advantage of using a reseller is that the hardware design, purchase and and installation can all be provided from the same company.  This simplifies the overall process and provides the ever so important ‘single-neck-to-choke.’  If something isn’t right before, during or after the deployment a good reseller will be able to help you coordinate actions to repair the issue without you having to call 10 separate vendors.

Lastly a reseller of sufficient size to handle private cloud design and migration will have an extensive pool of technical resources to draw upon during the process both internally and through vendor relationships, which means the team your working with has back-end support in several disciplines and product areas.

There are also some potential downsides to using a reseller that you’ll want to fully understand.  First a reseller typically partners with a select group of vendors that they’ve chosen.  This means that the architectural design will tend to revolve around those vendors.  This is not necessarily a  bad thing as long as:

  • The reseller takes an ‘independent view’ and has multiple vendors to choose from for the solutions they provide.  This allows them to pick the right fit for your environment.
  • You ensure the reseller explains to your satisfaction the reasoning behind the hardware choices they’ve positioned and the advantages of that hardware.

Obviously a reseller is in the business of making a sale, but a good reseller will leverage their industry knowledge and vendor relationships to build the right solution for the customer. Another note is even if your reseller doesn’t partner with a specific vendor, they should be able to make appropriate arrangements to include anything you choose in your design.

Consultant/Consulting Firm:

Utilizing a consultant is another good option for designing and deploying a private-cloud.  A good consultant can help assess the existing environment/organization and begin to map out an architecture and road map to build the private cloud.  One advantage of a consultant will be the vendor independence you’ll have with an independent consultant or firm.  Once they’ve helped you map out the architecture and roadmap they can typically work with you during with the purchase process through vendors or resellers.

Some potential drawbacks to independent consultants will be identifying a reliable individual or team with the proper capabilities to outline a cloud strategy. The best bet here to minimize risk here will be to use references from colleagues that have made the transition, trusted vendors, etc.  Excellent cloud architecture consultants exist, you’ll just need to find the right fit.

Hybrid Strategy:

These two options are never mutually exclusive.  In many cases I’d recommend working with a trusted reseller and utilizing an independent consultant as well.  There are benefits to this approach, one the consultant can assist to ‘keep the reseller honest’ and additionally should be able to provide alternative opinions and design considerations.

Summary:

Migrating to cloud is not an overnight process and most likely not something that can be planned for, designed and implemented using all internal resources.  When making the decision to move to cloud utilize the external resources available to you. As one last word of caution, don’t even bother looking at cloud architectures until your ready to align your organization to the flexibility provided by cloud, a cloud architecture is of no value to a silo driven organization (see my post ‘The Organizational Challenge’ for more detail: http://www.definethecloud.net/?p=122)

GD Star Rating
loading...

Learning from FaceBook’s failures

In the interest of honesty I’ll start this post by saying I’m not a fan of FaceBook and never have been.  This is based on two major things:

  • If you and I don’t keep in touch through email or phone there is a reason for that.  I have no desire to waste time being FaceBook poked by you, participating in your mafia war, or hearing about your interests and daily life.
  • Constant issues with questionable or downright unacceptable privacy practices and user data/credential theft.

This post however is not that broad in scope, it’s all about what we can learn from FaceBook’s privacy failures and how we can apply that to information and services we decide to place on the web and in the cloud.  I’m also not stating that FaceBook is in any way a cloud provider, the closest cloud definition FaceBook could be provided is FaaS (Failure as a Service.)  That being said FaceBook is a web based service providing an online tool for things you used to do offline (remember the family address book and the yearly holiday card?)

Lately there has been a lot of buzz around FaceBook’s latest major privacy infringement, pushing/selling your data to 3rd party services in the interest of ‘enhancing your user experience.’  The main issue with what FaceBook has done is not the addition of services which may enhance your experience, or even the privacy sacrificed to get those enhancements, it’s about the way they pushed this using an ‘opt-out’ model, rather than an ‘opt-in’ model.

  • Opt-in: A service or add-on that you must consciously choose to accept in order to gain it’s features, for example: ‘Would you like to turn on enhanced personalization features for our service (yes/no.)
  • Opt-out: A service or add on that becomes enabled automatically and may or may not inform you.

If the advanced personalization features of FaceBook were actually a benefit to the end user than opt-in would have been the way to push them.  FaceBook would have provided you a pop-up window detailing the benefits of the new service and the way in which it was done, and you would have happily accepted.  Because the new features are really just a pretty face on a new way for FaceBook to profit from the information you store in your profile they chose an opt-out model and obscured the ability to disable the feature behind a complex non-documented privacy setting hierarchy that requires a PHD to navigate (the complexity of FaceBook’s privacy policy and options system has been well documented in several other posts, if you have a good link post it in the comments.)

Since this announcement several IT professionals, myself included have publicly deleted their accounts to spread awareness.  The hope is that awareness makes it to the average end-user who has no clue about privacy dangers.  From my perspective it’s even more important that this information reach children and teens and that they learn the issues with too much public data.  Several young people will have a rude awakening when they sit across the desk from a manager during an interview and she/he turns their monitor around to show the job candidate a series of highly unprofessional blogs, pictures, videos, etc from FaceBook and other sites that are the reason the candidate won’t be getting the job.  As a side note to that, marking your profile ‘private’ or deleting it won’t be of any use, FaceBook’s privacy settings won’t help and any information that touches the web can be retrieved in some way regardless of deletion (http://www.archive.org/index.php for instance.)

So what’s this got to do with cloud?

FaceBook is just one example of privacy and security concerns with placing data/information in web based services or moving services to the cloud.  Another great example would be Gmail.  When checking your Gmail through a web browser you’re presented with advertisements targeted at you based on email content.  I’m actually a fan of this on the surface, I get non-intrusive text based ads that are typically somewhat relevant to me, this pays for the free service I’m using.  Now if Google took that one step further and sold keyword lists from my email history to advertisers that would be a different story (I’m not saying they do or don’t, if I was aware that they did I would close my account publicly as well.)  The same could be applied to cloud based business services such as SalesForce.com, if they started cross referencing your business data with other hosted companies and selling that it would be a major concern (again not saying they do or don’t.)

As you decide to use web based services, cloud based or not, for business and personal purposes you need to carefully assess how the data is encrypted, secured, backed up and used.  You need to also be very aware of changes to the privacy policies and End User License Agreements (EULA.)  This is no small task as these policies are typically lengthy and change frequently.  In every case remember that being skeptical is your best tool.  If I walked up to you on the street and told you that for just $100.00 I could teach you how to be a millionaire you’d laugh in my face, so why trust a company that says they can give you the world for $0.05 per Gigabyte?

Summary:

This is not intended as an anti-cloud rant, if you look around my blog you’ll see that I’m a definite endorser of cloud architectures in all shapes and forms.  The concept here is that you need to carefully assess both what you move to the cloud and where you move it.  Throughout the history of the data center we as an industry have had a tendency to make it work first and worry about security and privacy later.  Fantastic security engineers and researchers are working hard to change this behavior, help them out.  There is a saying in carpentry that you should always ‘measure twice, cut once’ apply the same to data center and cloud migration strategies.

GD Star Rating
loading...

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 (http://www.definethecloud.net/?p=73.)

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.

image

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.

Summary:

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
loading...

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
loading...