CA Community

September 2011 - Posts

CA World Preview: Cloud Choice Focus Area Highlights

Published: September 30 2011, 01:29 PM | no comments
by Christine Needles

 

I've been checking the CA World website on a daily basis, watching as the countdown draws closer to 0 - we're now 44 days out from the main event, taking place November 13-16 at the Mandalay Bay Resort & Casino in Las Vegas! CA World brings together 6000 attendees to share best practices on how to deliver IT services and applications when and how you need them.

For our CA Cloud Storm Chasers blog readers, following is a quick preview of the Cloud Choice Focus Area - highlights of the main theme and tracks.

If you haven't yet registered, you can here. Then make sure to use the Agenda Builder to customize your schedule, selecting the "Cloud Choice" focus area from the pull down menu for the list of cloud-related sessions.

So, what's the "Cloud Choice: Your Cloud, Your Way" focus area going to cover?

In these sessions, attendees will learn how to make sense of the rapidly accelerating set of cloud choices. With tracks covering Our Solutions for Your Cloud, Your Cloud Future, Today, and Your Peers Talk Cloud, you will gain important insights on when, where, and how to incorporate cloud computing into your IT portfolio and how to tailor it to your needs.

Visit the Cloud Choice Focus Area page for complete details, but here's a short overview of each track:

Our Solutions for Your Cloud: How, when and why should you decide to move to the cloud? CA Technologies can help you make the right cloud choice among the growing public, private and hybrid options. Sample session topics include:

  • Evolutionary and revolutionary approaches to cloud computing
  • Strategies for providing secure access to the cloud
  • How to manage service levels in the cloud

Your Cloud Future, Today: Cut through the cloud hype with pragmatic sessions to help you plan and execute your cloud strategy. This track will also explore other trends impacting IT, such as devops and the consumerization of IT. Sessions will cover:

  • The Cloud Computing Debate: Cutting Through the Cloud Clutter
  • Cloud financials 101
  • Consumer driven IT: Can users love IT as much as they love their iPad?
  • DevOps: where agile development meets agile infrastructure

Your Peers Talk Cloud: Hear directly from IT pros about their experiences and lessons learned with cloud computing. This track will also explore how participating in a cloud ecosystem can help you expedite the creation and delivery of cloud services. Samples sessions will cover:

  • Cloud contract essentials
  • Cloud adoption best practices: a panel discussion
  • Building a European cloud with Belgacom and CA: challenges and solutions
  • Zen and the Office of the C-I-No: How to address the hardest part of cloud computing: culture, skill-sets and organizational challenges

There is a wealth of information available at the event website. For example, you can read up on the General Sessions or check out the Week at a Glance schedule for an overview of the show schedule.

Not able to attend? Follow the #CAWorld hashtag on Twitter, or #cloudchoice for updates on Cloud Choice Focus Area sessions and activities as we get closer to the event.

And of course, watch the blog for additional details and updates on the event over the coming weeks.

Share this post:  
Tags: , , , ,
Leave a comment

 

By: Christine Needles
Christine Needles ( @cmneedles ) is a director of communications at CA Technologies, working with the Cloud Computing business. She is immersed in the world of B2B public relations and marketing communications, with 11 years of experience spanning several PR firms, until joining the communications team...
Read More..

DMTF Releases Cloud Management Work In Progress

Published: September 28 2011, 09:54 AM | 1 Comment(s)
by Marvin Waschke

The DMTF released a work in progress specification for its Cloud Infrastructure Management Interface (CIMI) September 14.  There are, as yet, few standards that apply directly and purely to cloud computing and even fewer of those that exist are well established, but there is a tangled thicket of established and de facto standards that do play some role.  Therefore, the significance of CIMI may be hard to see - and that's what I will attempt to uncover in this post.

The NIST cloud standards roadmap, published this summer, pointed out the need for a specification for an Infrastructure as a Service (IaaS) management interface, which is what CIMI is, and what is commonly referred to as ‘cloud infrastructure management.'

So, what is cloud infrastructure management?

Simply put, it is the control and direction of IaaS services, the bare computing infrastructure that you can get from the likes of Amazon EC2. The trouble is, consumers of public IaaS are at the mercy of their providers, who are free to use any interface they'd like. Until the entry of CIMI, there were three main options: Amazon's AWS interface, Openstack, and Open Cloud Computing Interface (OCCI). The Amazon interface is proprietary, although a few other providers have emulated some parts of it. Openstack is an open source effort using an Apache license. OCCI is a standard that was published in three documents earlier this year.

None of these three have established dominance. As a pioneer in providing IaaS, AWS has by far the most consumers using the AWS API and might be called a de facto standard, but Amazon's API is tailored to the features of the company's cloud offerings, which other providers may not want to emulate. Consequently, the prevalence of AWS is will probably depend on the continued dominance of AWS as a cloud provider. Openstack has gotten some traction, mainly with government bodies and institutions. OCCI is still relatively new, the final document of the specification having been released only this summer.  

Every IaaS has both a management and a functional interface

IaaS, PaaS, and SaaS all have two interfaces: a management interface and a functional interface. For IaaS, the management interface is used to describe the computer the consumer needs, ask the provider to create the computer, and then start and stop it. You can think of the management interface as what you do to set up a computer system before you get to the keyboard: picking out the model and configuration, waiting for the FedEx delivery, plugging everything in, and finally throwing the switch.  When the machine is booted up on the pre-installed operating system, it's time to use the functional interface. You sit down at the keyboard, install your software and start exercising your new increment of compute power. The functional interface is usually very similar, if not identical, to the interface you would use to work with an on-premise installation.

What does CIMI bring to the table that the alternatives do not?

The purpose of CIMI is to provide a standard way of performing work in a cloud that represents the work that is done without the keyboard on a system.

(Before I go on, please don't take this too literally. There may be things in the management interface that would be done with the keyboard of the cloud resource. This is a rule of thumb not a normative statement. I give credit to Gil Pilz of Oracle, the editor of the CIMI model spec, for the kernel of this way of describing the management interface. He made a remark in a meeting that I have stretched way beyond his utterance into this extended analogy; if it doesn't make sense, it's me, not him!)

Let me highlight some advantages to having an open standard IaaS management interface:

  • From the user's point of view, a widely accepted standard interface means only one interface to learn to use. This is a convenience that should not be under estimated. Imagine a World Wide Web where HTTP was not the standard interface and each website supported its own protocol. Dealing with two or three sites might be possible, but as the number of sites goes up, the difficulty of dealing with all those protocols would quickly become overwhelming.
  • For builders of tools to facilitate the use of cloud, such as CA Technologies, a widely accepted standard interface makes it possible for a single tool or module to reach many more providers, reducing development and maintenance costs.
  • Standards are unambiguously documented, with clear indication of what is normative for interoperability and what is suggested practice. Clear API documentation makes it easier for both providers and consumers to design around the API.
  • Many standards have established compliance testing and certification. This provides predictability and confidence in the behavior of interfaces.
  • A standard interface managed by an open standards organization supported by many vendors tends to be more stable than de facto interfaces. Standards organizations have processes to mediate between contending requirements and systematically maintain specifications.

Will CIMI come out on top?

Only time will tell if CIMI becomes the predominant standard for IaaS management.  It is still a work in progress and a late arrival, but it has the advantage of contributions from a number of vendors who are active in developing cloud computing. The range of contributors to the specification, and the rigor of DMTF processes (which have recently passed the scrutiny of ANSI and ISO/IEC for the Open Virtualization Format and Server Management Command Line Protocol) are in its favor.

Interface specifications are a bit dry, but I recommend looking at the work in progress. The texts are available on the DMTF site: DSP0263, DSP0264, DSP2027. The primer (DSP2027) is a quick route to the flavor of the specification.  The model and REST protocol specification (DSP0263) is the meat of the standard. The CIM section (DSP0264) will be useful to DMTF CIM aficionados.

(All of that said, my friend and colleague in many work groups, William Vambenepe, has expressed an alternate view of the significance of CIMI in his blog . I encourage you to read both and share your point of view in comments. Time will tell...)

*Public domain keyboard image courtesy of Petr Kratochvil.

Share this post:  
Tags: , , , , , ,
Leave a comment

 

By: Marvin Waschke
Marv Waschke is a senior principal architect at CA Technologies. He has represented CA Technologies in several standards groups including the Cloud Management Working Group and Configuration Management Database Federation working groups of the Distributed Management Task Force (DMTF). He is also a member...
Read More..

Pragmatic Cloud: You Can't Always Get What You Want

Published: September 26 2011, 09:00 AM | no comments
by George Watt

Give your customers what they need.  It's not always what they ask for.

Soft skills a key ingredient to cloud computing success

This week I had the pleasure of joining the Cloud Exchange discussion in Toronto.  Though there was a great and diverse group in attendance with a broad range of interests, there were a few things that were of more universal interest.  Amongst these were several issues that might be placed into the "people management" or "soft skills" categories.  I was very encouraged to learn that, though not because I enjoy the suffering of others.  I believe this signifies an increase in the maturity of cloud computing.  At the very least it is a sign that more organizations are more mature when it comes to their thinking about cloud solutions.

At your service

During the session I discussed some of the soft skill challenges we faced when I was a private cloud provider.  Ironically, a (partial) cause of one of those challenges was that were very fortunate to have one of the most service-focused, customer-focused teams I have ever had the pleasure to work with.  We later learned that while this is a great strength it can, if left unchecked, become a great weakness. 

How is that possible?

Solve the solution, please

Quite often our customers (colleagues from across the company) approached our team with a request for a new service.  At least that's what they thought they were doing.  In fact, in many cases what they brought to the team was a description of how they had determined the team could accomplish their business objective, as opposed to information about the goal or the business objective itself.  ("I need six M1000 servers, a <vendor name omitted> switch, some duct tape, and a Rottweiler.")  Sometimes this was not necessarily a problem.  Often it was.

The challenge I referred to previously can occur when the team adopts that service focus posture and simply says "yes" to every request without understanding what the customer hopes to accomplish.  (That tended to happen during phases where our service was growing rapidly.)  This issue can also surface when a senior stakeholder in the customer's team applies pressure (in the negative sense of the word), essentially forcing the team to do the wrong things.  (Of course, there are other causes.)

Sadly I have witnessed both, and the terrible outcomes that can result.  Unmet needs, missed opportunities, wasted resources and funding - and sometimes a lot of it.  And in the end the relationship between the consumer and the supplier suffer greatly (to say they despised one-another may have been an understatement in some cases).  As a result they sentence themselves, consumer and provider, to even more of the same.

Partnership is paramount

This challenge has many causes, so it was critical for us to train our team to behave in ways that would catch it when it was about to happen and prevent it from occurring.  The good news  - it was all about becoming a true partner with the business teams we served.  We had to train our team to ask questions about what it was our business partners were trying to accomplish.  To understand their business objectives.

It's not as simple as it sounds (which may not be as surprising to those of us who have been living and breathing "business and IT alignment" challenges for years).  In many cases the business partners had done a lot of thinking about their solution and any questioning could come across as an insult, as combative, or worse, as "just another example of what you get when you approach the Office of the C-I-No".  The dialog had to be held in such a way that the customers understood we were a partner, we had their best interests at heart, and we were committed to their success.

That's not always easy.  In fact, early on it's not often easy.  It takes discipline and good interpersonal skills.  It needs to be as widespread as possible.  Some people take a long time to obtain these relationship skills.  Some never do.  And diligence is required on the part of managers because even once a team has acquired these skills they will not always apply them when necessary.  When this discipline is maintained the results can be outstanding.  The solutions we delivered in partnership were often (almost always) much better than the solution either side proposed on their own.

When a team "gets this right" the results can be infectious, resulting in more demand for services from new customers.

"I want the thrifty box"

This challenge is not unique to IT.  In fact, when thinking about this problem my "eureka moment" came from an experience I had in high school.  (Yes, they had computers when I was in high school; this moment simply had nothing to do with them.)  The event that came to mind was one that occurred whilst I was picking up lunch at a fast food restaurant.

As you might expect, this outlet offered various packages and combinations of their product:  some for the individual, some for a larger party.  The package that contained the food changed form depending upon the size of the meal that was purchased.  As I entered the restaurant I saw an elderly woman in a very passionate discussion with the store manager.  "I want the thrifty box!" she explained, quite a few times as I recall.  (It's strange what one remembers.)  The conversation became circular very quickly.  She wanted the "thrifty box".  The manager told her that's what she had.  She said that she did not and...  yes, she wanted the "thrifty box".  They danced for quite a while...

Think beyond the surface of the request

So, what happened?  And what does any of this have to do with cloud computing or enterprise IT?  It was actually a very simple misunderstanding.  The manager did not take a moment to ask his customer questions and learn her real objectives.

Her objective:  Gardening.  How's that for a tangent?  Many gardeners in the locale had realized that one of the containers offered by the restaurant was an excellent tool for repotting and relocating plants.  She did not receive one of those because she ordered a meal one size below the smallest meal delivered in that package. The store's menu had a picture of the container she wanted on the plaque that listed the meal she had ordered.  She kept pointing to the sign asking for it.  The manager assumed she just didn't realize she had all the food she paid for.  He thought she wanted more.  He said repeatedly that he had given her what she asked for (let's just call it...  "the thrifty box" - not it's actual name).  That was not what she wanted, nor was it food.  She simply wanted the larger package.

Sometimes the answer is simpler

Any one of a number of simple solutions (e.g.: put the container she had inside of one of the larger packages) would have resulted in a very satisfied customer, and in goodwill with all others who were in the store.   

"But if you try sometimes you might find you get what you need"

So, as the Rolling Stones' song suggests, it's not always by giving a customer exactly what they ask for that we best serve them.  We must remember to be diligent to ensure we understand what they need, and work in partnership with them to deliver the business value they seek; and as much of that as is possible. 

In addition, we must not believe that our ideas are always better than our customers.  We delivered some great, innovative services based upon ideas brought to us by our customers.  Great partnerships include bi-directional communication and open minds all around.  After all, as Edward de Bono said "If you never change your mind, why have one?"

Has this ever happened to you?  If so, what strategies and tactics did you use in order to ensure your customers received the service they deserved?

 

This blog is cross-posted at Pragmatic Cloud. Follow @GeorgeDWatt on Twitter.

 

Share this post:  
Tags: , , , , ,
Leave a comment

 

By: George Watt
George Watt ( @GeorgeDWatt ) is VP of Strategy for the Cloud Computing organization at CA Technologies. For nearly 25 years, George has been helping customers simplify and automate their complex IT infrastructures. Prior to his current role, George founded CA Technologies Engineering Services team, which...
Read More..

A Service Taxonomy for Cloud Choices

Published: September 22 2011, 12:18 PM | 2 Comment(s)
by Andi Mann

I have been talking with many CIOs for some time about strategic adoption of cloud solutions. A key step in these conversations is always the review of the portfolio of services they provide to business users, so they can choose which clouds to adopt and why.

This has led me to describe a high-level taxonomy that segments the service portfolio according to the different cloud requirements, capabilities, and approaches in different types of applications and services.

Essentially, this work has segmented most (all?) service portfolios into four areas, which (roughly) follow the adoption curve of cloud computing

Cloud-Free Services

For most of the large enterprises I talk to, some services will not be part of any cloud. These ‘cloud-free' services may migrate from physical to virtual, but do not need elastic scalability and self-service, are too impractical or incomprehensible, are too locked into non-commodity (e.g. z-Series) hardware, or are too sensitive or mission-critical to migrate to (especially public) cloud environments. With apologies to the ‘pure cloud' fantasists, it is a reality for many organizations, especially larger enterprises, many services will not be part of their cloud adoption plans - at least not soon, perhaps not ever. It is important to identify these ‘cloud-free' services.

Cloud Migrant Services

As CIOs get a handle on cloud, they start proactively evaluating their service portfolio and migrating selected existing workloads - from the OS up - initially from physical to virtual, then to appropriate public or private cloud choices. These ‘cloud migrant' services are not fundamentally changed, as they simply ‘lift and shift' the same code, requirements, interconnections, users, data sources, etc. from traditional environments to (typically IaaS) clouds. Many benefits can accrue from running these services in a cloud - agility, flexibility, efficiency, cost reduction - but the services themselves are not specifically built in or for the cloud.

Cloud Native Services

As organizations embrace cloud computing, they start developing and using new ‘cloud-native' services built in the cloud and for the cloud. Mobile and social services, for example, really blossom when built on cloud-native characteristics like self-service, mobility, scalability, and ‘big data', while cloud-native development also allows business ideas to ‘fail fast' or prove success with minimal upfront investment. Of course, rogue-cloud services (see below) can become cloud-native services when they move to ‘official' production status; and SaaS applications are also cloud-native services, just delivered out-of-the-box by public providers.

Rogue Cloud Services

In many organizations, business users or developers have adopted cloud already, outside of the normal IT procurement process. The term ‘rogue' may seem pejorative, but is not intended to be - I simply described a process that is outside of IT's knowledge or control. As I wrote back in 2009, rogue cloud can be very positive, and there is no per se reason for IT should to shut it down. However, IT does need to establish visibility into rogue cloud to ensure security or compliance, avoid cost overruns, drive broader adoption of good cloud choices, or even to promote better cloud choices.

Why Does This Matter?

This segmentation came about not as an academic exercise, but to help CIOs with a taxonomy for service portfolio analysis and cloud choice. Each of these cloud service types has different needs, from both platform and management perspectives. By identifying cloud service types, a CIO can better adopt their choice of cloud as appropriate for different services at different times.

For example,

  • A cloud-native service can be ‘designed to fail', whereas a cloud-migrant service needs additional management (e.g. real-time replication) to maintain the same level of continuity.
  • A cloud-migrant application that has been QA'd on a closed and proprietary hypervisor may need additional testing and QA before it can be moved to a different (or unspecified) hypervisor.
  • A rogue cloud service must be discovered before it can be managed as part of a whole portfolio, whereas a cloud-native or cloud-migrant service will be catalogued as it is deployed.
  • A cloud-free service needs none of the above, and specifically can fall outside the cloud portfolio and be exempt from new policies specifically designed to enable cloud services.

This segmentation is not meant to replace a thorough service portfolio analysis in making good cloud choices. In my session at VMworld 2011 in Las Vegas, for example, I presented analysis models from Visible Ops - Private Cloud, a CA Technologies quadrant framework, Forrester Research's Evaluating Application Fit With Cloud model, and Freeform Dynamics' model from Applied Cloud Computing: A practical guide to identifying the potential in your environment.

However, I do think it is a useful taxonomy to start making sense of your own service portfolio as you start to take stock of where you are in your cloud strategy, and where you want to go. So far, the CIOs I have worked with on this have agreed.

What do you think?

 

This blog is cross-posted at Andi Mann - Übergeek. Follow @AndiMann on Twitter.

Share this post:  
Tags: , , , , , , , ,
Leave a comment

 

By: Andi Mann
Andi Mann is vice president of Strategic Solutions at CA Technologies. With over 20 years’ experience across four continents, Andi has deep expertise of enterprise software on cloud, mainframe, midrange, server and desktop systems. Andi has worked within IT departments for governments and corporations...
Read More..

Pragmatic Cloud: Cloudy Views Bring Sunny Outlook for Cloud Consumers

Published: September 19 2011, 10:37 AM | no comments
by George Watt

"#CloudViews" Cloud Outage Chat Participants Put Their Customers First

Last Thursday I participated as a panelist in Cloud Commons' "#CloudViews" Twitter chat (partial session archive here or page through the full archive here).  The following is a brief summary of that event.

Put the Customers' Interests First

Though the topic of this chat session was "Cloud Outages" there was, I believe, another clear theme:  It's all about the consumer.  It's all about the customer.  And the participants care about the well-being of the businesses to which they provide service.  Whilst this was demonstrated in a somewhat subtle way in numerous posts, some of them were quite straight forward.

Transparency is Paramount

Closely connected to the underlying theme of respect for our customers was a very active discussion regarding transparency of providers when service is disrupted.  Participants weighed in from both customer and provider perspectives.  For example, this excerpt from an exchange started by Jonathan Davis of DNS Europe who offered his opinion on the service provider perspective:



Jay Fry's comment resulted in much agreement and was widely reposted.  Christoph Streit of ScaleUp agreed:

 


And this exchange from the customer's perspective generated much agreement, including from the service provider community in attendance, as can be seen through responses from Jonathan and from Mimecast's Justin Pirie.



(This topic produced much conversation.  Posts were too numerous to include all of them.  I apologize to those whom I omitted. )

So, it was incredibly encouraging to see so much agreement on the importance of best practices, customer focus, and ethical conduct.

Built-in and Built-On Resilience

Yes, there was also discussion of service outages and resilience - and a lot of it.  There were many good perspectives on how providers, application architects, and consumers can deliver resilience.  I believe there was also nearly unanimous agreement that components can and will fail, and that services must be architected to address that.  (Please visit the chat archive for other examples.)

I have attempted to extract a representative sampling of key points made throughout the discussion and share it via the list below.  Before I share that I would like to answer a question asked by my colleague, Andi Mann, during the session that I missed as posts flew past.  (Apologies for not catching that, Andi.)  In response to one of my posts that stated resilience can be "built-in" to the cloud platform or "built-on" via the application or service Andi asked:


When I referred to "built-in" resilience I was referring to the things that the service providers have added to their services in order to ensure that their customers experience no loss of service when a component fails.  The providers who joined the session discussed many of these things such as N+1 environments, clustering, and geographically disbursed data centers.

As we have witnessed recently, even when such precautions are taken a service can suffer an outage.  There are many reasons this can happen ranging from a new type of issue surfacing for which the provider was not prepared, to cases where, through no fault of the provider (their service remains active) the customer (composite application...) is unable to connect to the service.  In order to address this, and to ensure that services are not disrupted even in these cases (to make sure nobody notices) application architects are building cloud-savvy resilience into their solutions (into the application).  This is what I referred to as "built-on", since it sits "on top of" any resilience "built-in" by the service providers, and since it adds a/another layer of protection.  Netflix' "Rambo Architecture" and its use of "Chaos Monkeys is a good example of this.

The tweet chat panelists shared and discussed many great tips and lessons learned.  While approaches to specific issues were different at times, generally there was broad agreement in many areas.  Participants tended to agree on the following:

  • Components and services will fail
  • Not all failures are predictable or preventable
  • Consumers must be prepared for outages in both "traditional" on-premise environments and in clouds
  • It is possible to provide continuous service even when a service fails
  • Many service providers are aware of the importance of resilience and are taking action to provide it
  • Resilience can and should be built into both the cloud service ("platform") and the business application ("built-in" and "built-on")
  • A poorly designed application when moved to the cloud is still a poorly designed application
  • Many traditional on-premise applications are not built to "expect" failure and that can add complexity when moving those applications to the cloud
  • Not all services require the same level of resilience
  • Providers and consumers must work together to evaluate risk and determine the best appropriate level of resilience for their services
  • Consumers may need assistance to determine the criticality of their applications, the risk they can tolerate, their best approach to resilience, and balancing that with cost
  • Assume components and services will fail, plan for that, test the plan
  • Test the plan at an appropriate frequency
  • Did we mention test the plan?
  • Services and environments change, so keep plans fresh (and yes, test them)
  • Failures and outages should not be hidden from consumers/customers
  • Transparency regarding outages is key: Customers should be informed and providers should communicate proactively

In addition to these items, several tips were shared such as this one:


I quite enjoyed the session and was very pleased with the level of active participation, with the great information that was shared, and with the level of respect the participants offered one-another, even when their views were different.  So I would like to offer a sincere thank you to the chat participants.  If I missed something important please do let me know.

To all who were kind enough to read this:  What other words of wisdom would you offer regarding cloud outages?  We would also greatly appreciate suggestions for topics for future chat sessions.

 

This blog is cross-posted at Pragmatic Cloud. Follow @GeorgeDWatt on Twitter.

Share this post:  
Tags: , , , , , , , ,
Leave a comment

 

By: George Watt
George Watt ( @GeorgeDWatt ) is VP of Strategy for the Cloud Computing organization at CA Technologies. For nearly 25 years, George has been helping customers simplify and automate their complex IT infrastructures. Prior to his current role, George founded CA Technologies Engineering Services team, which...
Read More..

More Posts Next page »