CA Community

May 2011 - Posts

Hurford of DNS Europe: service providers and SaaS developers are showing enterprises how cloud is done

Published: May 26 2011, 09:40 AM | no comments
by Jay Fry

The antidote to cloud computing hype is, well, reality. For example: talking to people who are in the middle of working on cloud computing right now. We've started a whole new section of the ca.com website that provide profiles, videos, and other details of people doing exactly that.

One of the people highlighted on this list of Cloud Luminaries and Cloud Accelerators is Stephen Hurford of DNS Europe. DNS Europe is a London-based cloud hosting business with over 500 customers across the region. They have been taking the cloud-based business opportunities very seriously for several years now, and provide cloud application hosting and development, hybrid cloud integration services, plus consulting to help customers make the move to cloud.

I convinced Hurford, who serves as the cloud services director for DNS Europe, to share a few thoughts about what customers and service providers are - and should be - doing right now and some smart strategies he'd suggest.

Jay Fry: From your experiences, Stephen, how should companies think about and prepare for cloud computing? Is there something enterprises can learn from service providers like yourself?

Stephen Hurford, DNS Europe: Picking the right project for cloud is very important. Launching into this saying "we're going to convert everything" to the cloud in this short period of time is almost doomed. There is a relatively steep learning curve with it all.

But this is an area of opportunity for all of the service providers that have been using CA 3Tera AppLogic [like DNS Europe] for the last three years. We're in a unique position to be able to help enterprises bypass the pitfalls that we had to climb out of.

Because the hosting model has become a much more accepted approach in general, enterprises are starting to look much more to service providers. They're not necessarily looking to service providers to host their stuff for them, but to teach them about hosting, because that's what their internal IT departments are becoming - hosting companies.

What is the physical infrastructure you use to deliver your services?

We don't have any data centers at all. We are a CSP that doesn't believe in owning physical infrastructure apart from the rack inwards. We host with reputable Tier 3 partners like Level3, Telenor, and Interxion, but it means that we don't care where the facility is. We can deploy a private cloud for a customer of ours within a data center anywhere in the world and with any provider.

When people talk about cloud, the public cloud is usually their first thought. There are some big providers in this market. How does the public cloud market look from your perspective as a smaller service provider? Is there a way for you to differentiate what you can do for a customer?

The public cloud space is highly competitive - if you look at Amazon.com, GoGrid, Rackspace, the question is how can you compete in that market space as a small service provider? It's almost impossible to compete on price, so don't even try.

But, one thing that we have that Amazon and Rackspace and GoGrid do not have is they do not have is an up-sell product - they cannot take their customers from a public cloud to a private cloud product. So when their customers reach a point where they say, "Well, hang on, I want control of the infrastructure," that's not what you get from Amazon, Rackspace and GoGrid. From those guys you get an infrastructure that's controlled by the provider. Because we use CA 3Tera AppLogic, the customer gets control, whether hosted by a service provider or by themselves internally.

My colleague Matt Richards has been blogging a bit about smart ways for MSPs to compete and win with so much disruption going on. Where do you recommend a service provider start if they want to get into the cloud services business today?

My advice to service providers who are starting up is to begin with niche market targeting. Pick a specific service or an application or a target market and become very good at offering and supporting that.

We recommend starting at the top, by providing SaaS. SaaS is relatively straightforward to get up and running on AppLogic if you choose the right software. The templates already exist - they are in the catalog, they are available from other service providers, and soon will be available in a marketplace of applications. Delivering SaaS offerings is the easiest technical and learning overhead approach and that's why we recommend it.

Looking at your customer base, who is taking the best advantage of cloud platform capabilities right now? Is the area you just mentioned - SaaS - where you are seeing a lot of movement?

Yes. The people who have found us and who "get it" are the SaaS developers. In fact, 90% of our customers are small- to medium-sized customers who are providing SaaS to enterprises and government sectors. It's starting to be an interesting twist in the tale: these SaaS providers are starting to show enterprises how it's done. They are the ones figuring out how to offer services. The enterprises are starting to think, "Well, if these SaaS providers can offer services based on AppLogic, why can't I build my own AppLogic cloud?" That's become our lead channel into the enterprise market.

How do service providers deal with disruptive technologies like cloud computing?

From a service provider perspective, it's simple: first, understand the future before it gets here. Next, push to the front if you can. Then work like crazy to drive it forward.

Cloud is a hugely disruptive technology, but without our low-cost resources we could not be as far forward as we are.

One of the fundamentally revolutionary sides of AppLogic is that I only need thousand-dollar boxes to run this stuff on. And if I need more, I don't need to buy a $10,000 box. I only need to buy 4 $1,000 boxes. I have a grid and it's on commodity servers. That is where AppLogic stood out from everything else.

Can you explain a bit more about the economics of this and your approach to keeping your costs very low? It sounds like a big competitive weapon for you.

One of the big advantages of AppLogic is that it has reduced our hardware stock levels by 75%. That's because all cloud server nodes are more or less the same, so we can easily reuse a server from one customer to another, simply by reprovisioning it in a new cloud.

One of the key advantages we've found is that once hardware has reached the end of its workable life in terms of an enterprise's standard private cloud, it can very easily be repurposed into our public cloud where there is less question of "well, exactly what hardware is it?" So we've found we can extend the workable lifespan of our hardware by 40-50%.

What types of applications do you see customers bringing to the cloud now? Are they starting with greenfield apps, since this would give them a clean slate? The decision enterprises make will certainly have an impact for service providers.

Some enterprises are taking the approach to ask "OK, how can I do my old stuff on a cloud? How do I do old stuff in a new way?" That's one option for service providers - can I use the benefits of simplifying and reducing my stock levels, reducing my management overhead from my entire system by moving to AppLogic and then I won't have 15 different types of servers and 15 different types of management teams. I can centralize it and get immediate benefits from that.

The other approach is to understand that this is a new platform with new capabilities, so I should look at what new stuff can I do with this platform. For service providers, it's about finding a niche - being able to do something that works for a large proportion of your existing customers. Start there because those are the folks that know you and they know your brand. Think about what they are currently using in the cloud and whether they would rather do that with you.

Some believe that there is (or will soon be) a mad rush to switch all of IT to cloud computing; others (and I'm one of those) see a much more targeted shift. How do you see the adoption of cloud computing happening?

There will always be customers who need dedicated servers. But those are customers who don't have unpredictable growth. And need maximum performance. Those customers will get a much lower cost benefit from moving to the cloud.

For example, we were dealing with a company in Texas that wanted to move a gaming platform to the cloud. These are multi-player, shoot-‘em-up games. You host a game server that tracks all the coordinates of every object in space in real-time between 20 and 30 players and sends that data to the Xbox or PlayStation that renders it so they can play in the same gamespace. If you tried to do that with standard commodity hardware, you're not getting the needed performance on the disk I/O.

The question to that customer was, "Do you have a fixed requirement? If you need 10 servers for a year and you're not going to need to grow or shrink, don't move to the cloud." Dedicated hardware, however, is expensive. They said, "We don't know what our requirements are and we need to be able to deploy new customers within 10 minutes." I told them you don't want to use dedicated servers for that, so you're back to the cloud, but perhaps with a more tailored hardware solution such as SSD drives to optimize I/O performance.

So what do you think is the big change in approach here? What's the change that a cloud platform like what you're using for your customers is driving?

Customers are saying it's very easy with our platform to open up 2 browsers and move an entire application and infrastructure stack from New York to Tokyo. But that's not enough.

Applications need to be nomadic. The concept of nomadic applications is way distant in the future, but for me, what we're able to offer today is a clear sign-post for the future. Applications with their infrastructure will eventually become completely separated from the hardware level and the hypervisor. My application can go anywhere in the world with its data and with its OS that it needs to run on. All it needs to do is to plug into juice (hardware, CPU, RAM) - and I've got what I need.

Workloads like this would be liable to know where they are. By the minute, they'll be able to find the least-cost service provisioning. If you've got an application and it doesn't really matter where it is and it's easy to move it around, then you can take advantage of least-cost service provisioning within a wider territorial region.

...

Thanks, Stephen, for the time and for sharing your perspectives. You can watch Stephen's video interview and read more about DNS Europe here.

 

This blog is cross-posted at Data Center Dialog. Follow @jayfry3 on Twitter.

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

 

By: Jay Fry
Jay Fry is vice president of marketing, Cloud Computing, at CA Technologies. He has over 20 years of experience in marketing and management for innovative enterprise software companies. Prior to CA, Jay was vice president of marketing at cloud computing start-up Cassatt and founded the marketing department...
Read More..

In cloud standards, it's all about survival of the fittest

Published: May 24 2011, 05:38 PM | no comments
by CA Community

The Kuppinger Cole European Identity Conference 2011 (EIC), which was held in Munich earlier this month, truly represented a ‘Who's Who' of cloud initiatives and standards.  Representatives from many influential, established and aspiring standards and industry bodies were on hand to showcase progress of the security initiatives currently in the works.

The number of initiatives is overwhelming. For years the joke was that any time two Dutch meet, they are likely to start an association or co-operative initiative, but apparently that is also true for security and cloud experts. I won't bore you with all the clever acronyms (it's a true alphabet soup), but I do want to highlight the more interesting overall findings.  

In one of the first forum sessions - called "In Cloud We Trust" - Dr. Laurent Liscia of OASIS gave an interesting perspective on these competing standards. He compared the process of establishing an accepted standard to a Petri dish (no relation).  Multiple cultures in a nutritious environment all trying to do a land grab. A process that is not orchestrated, it's ‘eat or be eaten' and it is hard to predict the outcome because the process takes time.  No amount of pressure  or additional heat can accelerate it and watching a Petri Dish real-time is about as useful and as interesting as watching grass grow. Meaning, it's better to wait for history to run its course.

Having said that, there one initiative from this forum - which had participants from ENISA, The World Economic Forum, TRUSTe and CA Technologies - that I do want to highlight, even though the implementation is still in an incubation phase.

Earlier this year the World Economic Forum IT partnership - in collaboration with Accenture and with input from a steering group including representation from CA Technologies - published "Advancing cloud computing: what to do now?" with eight recommended action areas. The reason I mention this particular initiative is because of the enormous influence this organization has on governments. As associations all over the world realize that legislation and government stimulus may determine the success of their regional cloud industry - an industry that is likely to be the next economic engine of prosperity - they are rapidly publishing recommendations on what they feel their local governments should do to facilitate the success of cloud computing. So as not to be drowned out in the aforementioned alphabet soup of initiatives, it makes sense to anchor such local recommendations against the global guidance of the World Economic Forum. 

 

The recommendations are not earth shattering, but if governments and the cloud ecosystem participants could streamline their efforts around these eight, it would further these efforts in a useful and pragmatic way. For more info read the (very readable) full report, but in a nutshell the recommendations are:

  1. Explore and facilitate the realization of the benefits of cloud
  2. Advance understanding and management of cloud related risks
  3. Promote service transparency
  4. Clarify and enhance accountability across all relevant parties
  5. Ensure data portability
  6. Facilitate interoperability
  7. Accelerate adaptation and harmonization of regulatory frameworks
  8. Provide sufficient network connectivity to cloud services

P.S. During the event I participated as a forum member in "Cloud Standardization: From Open Systems to Closed Clouds?," and "Identity and Access in the Cloud." I will be speaking more about the topic of lock-in at the upcoming International Cloud Expo in New York (June 6-9), and I will cover cloud computing and risk during the Middle East Financial Technology Conference (MEFTEC) in Abu Dhabi (May 30-31).

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

 

By: CA Community
CA Community is the blog manager’s account used to post general updates and news items.
Read More..

Pragmatic Cloud: Private Clouds Deliver No Value (Part II)

Published: May 23 2011, 09:00 AM | 1 Comment(s)
by George Watt

People who live in glass houses should throw dashboards

In Part I of this series, I discussed some of the challenges and value (or lack thereof) perceptions facing private cloud providers ending with the question "what can be done" to address those.  As is likely apparent, there are many things that might be done to address this, and selection of the most appropriate of those is certainly dependent upon your situation.  In this post, I will focus on some simple strategies that are likely broadly applicable.

Live in a Glass House - Transparency, SLAs Critical

CCL image courtesy seier+seier - http://www.flickr.com/photos/seier/2374552600/sizes/s/in/photostream/

To address the perceptions discussed in Part I,  stakeholder anxiety measurement and communication is key.  A diligent, aggressive approach to stakeholder engagement is required.  To remain relevant and viable the stakeholders must be engaged before they have become convinced your service has no value; and that does not take long at a senior level, especially when budgets are at stake.  Here are a few strategies that should to help avoid that:

#1  Measure value delivered

It is important to measure the value your service brings to the business not only in the context of communicating with key stakeholders but also in order to make wise choices about your service and investment priorities.  A close relationship with your Finance team can be immensely helpful in this respect.

#2  Measure the service delivered

It is also important to measure the service delivered by your team.  This means committing to and measuring against service levels through service level agreements (SLAs).  This can be challenging.  Intelligent and skilled technical people often resist this, because they know they are doing a great job and do not like to be "watched" in this way.  It makes them feel untrusted and unvalued.  In those cases ask them to consider the alternative.  Someone states that your service is not good, that "it stinks" (that's a detailed technical term). Without measurement they are correct, since you have no way of knowing otherwise. You are locked into management by perception (incidentally, perception is always important).

With good measurement there are three possible responses to a complaint about service.  Each is, in essence, a step forward in service maturity:

  • "Yes, service is bad. Here is a detailed account of what aspects are suboptimal. We have investigated the cause, and here is our plan of action."
  • "That service you mentioned is actually performing well (showing a report that confirms that to be the case). However, you are unhappy about something so there must be something else that is not meeting your needs. We will work with you to understand what the cause is and address it (even if the cause is perception only)."
  • The service level management systems detect that service is about to suffer, the team acts, and the disruption never happens.

All three will result in better service to your customer, and increased confidence in your team.

#3  Set realistic, achievable, sustainable customer expectations

Early on in the life of a service it may be possible to provide an extremely high level of service, much higher than is necessary.  That level of service may not be possible as the service matures, and that can cause friction with the stakeholders - or worse.  I recall one incident where someone escalated a request to their most senior executive and to mine because an instant message (not sent to a service team but to an individual) had not been answered within five minutes.  We had set a completely unachievable level of expectation during our growth phase.  Either setting an appropriate level of expectation or communicating that the level of service was unusual initially would have helped a lot.  It can be very difficult to reset an expectation. 

It is also important to help consumers to understand the levels of service they truly require, and that each comes with a cost.  This is something that everyone is accustomed to when dealing with external sources.  It is not always addressed by internal groups.  Everyone will always demand the highest level of service possible, whether or not they require it, when cost is not an issue.  Helping consumers to understand the cost associated with each tier of service and offering cost alternatives not only addresses this, but it also helps build a partnership between the provider and the consumer.  Tiered pricing for public clouds is a parallel to this.

Individual customer groups may also need to be reminded that not everyone requires the same level of service.  For example, our Customer Support team requires rapid response, seven days a week, every day of the year.  It is the nature of their business.  In contrast, someone using the systems for self-education might do with business hours support, five days a week.  Presenting the consumer with an analysis of the costs and letting them make the choice (and supply the requisite funding, or help you acquire it) can also help your team avoid perceptions of an unwillingness to serve or to "do the work".

(There is a lot to be discussed with regard to service level agreements, so perhaps more on this later.)

#4  Be proactive and transparent

Good news should travel fast.  Bad news should travel faster.  In his book "Behind the Cloud", Salesforce.com CEO Marc Benioff recounts a story of a series of outages that might have destroyed their company and how eventually transparency helped them retain their customers.  Customers should not be left in the dark.  The more proactive you are with your communication, even if the news is bad, the more satisfied your customers will be.  I have found that even simple things such as an RSS feed can go a long way toward addressing this.  We had two:  One for "good news" (upgrades, new resources...) and one for "bad news" (performance issues, scheduled outages, etc.).

Proactive communication will also result in less exhaustion for your team.  Mark Thiele recently wrote about the down side of IT heroics.  His points are equally applicable to report creation and communication.  I cannot think of too many things that are a greater drain on productivity than scrambling for a piece of data for a report.  I have seen these requests take several days.  Have the information available for your stakeholders all of the time, and give them a simple method for submitting suggestions and responses to you.

#5 Interested stakeholders are often very senior

As I mentioned earlier, it is often the sum total of your service that attracts the attention of senior executives, especially at budget time.  Proactive communication with these people is critical, as is being prepared to present your case to very senior people at a moment's notice. (A previous post regarding executive communication discussed that in more detail.)

Those are just a few of the things that helped us.  What successful strategies have you employed?

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

Three reasons why your cloud SLA is falling short

Published: May 18 2011, 09:20 AM | 2 Comment(s)
by Erik Hille

Recently, yet another service outage was reported from a major cloud service provider.  VMware Cloud Foundry, VMware's open-source platform-as-a-service offering, experienced a multiday outage.  On the heels of a press-worthy, multi-day Amazon EC2 outage that significantly impacted their customer base, a number of pundits have begun to speculate whether the security and performance standards for cloud providers are up to an enterprise class (see stories here and here).   

These concerns are certainly valid, and prompted me to ask, "What can a company really do about it?"  After all, any time we outsource a service to a vendor (cloud-based or not), we implicitly make a tradeoff.  In essence, we trade operational control for improved costs and/or agility.  Service providers try to make us feel better about that trade-off by offering SLAs that address these concerns.  In fact, when I looked at the Amazon EC2 SLA as an example, it turns out that the company offers a 99.95% uptime SLA - which means only 22 minutes of downtime a month (assuming 24x7). This seems pretty good on the surface, right?

Let's consider this one SLA as an example of the common shortcoming of SLA management in the cloud space.  More often than not, I find the typical SLA in this space are little more than a piece of paper coming up short in the following areas: 

  1. It doesn't measure what it should,
  2. The measurements are calculated in the vendor's favor, and
  3. The SLAs are not actively monitored.

The SLA doesn't measure what it should

SLAs for almost all cloud based services are expressed in terms of uptime percentage.  Why is that?  "SLA" has come to mean a wide spectrum of things.  Operational monitoring tools typically leverage it to mean an operational measurement (e.g., is this server up or down and what percentage of time it has been up or down over the past week, month, etc.).  At the other end of the spectrum are frameworks like ITIL which think of an SLA as an organizing contract inside of which there are performance metrics. 

Clearly the relationship with an outsourced service provider is governed by a contract and within it are the performance levels that govern the contract.  Ironically, the SLAs that most cloud companies offer generally mimic the operational ones that IT uses to manage internal systems.  For instance, looking at performance only in terms of uptime ignores other parameters necessary to govern the relationship.  For instance, Amazon might utilize a measure of stability (e.g., packet delay, packet jitter) or capacity (e.g., throughput rate volume) in addition to the single measurement of availability.

From the customer's perspective, it is unlikely that availability alone describes a satisfying performance experience, yet cloud vendors consistently fight over who has more 9s. 

The measurements used are calculated in the vendor's favor

This does not mean that cloud providers are willing to fall on the proverbial sword when it comes to those 9s.  A closer examination of the metrics will show calculation assumptions that benefit the vendor, particularly when some level of interpretation is involved.  Vendors will often establish calculation parameters that leverage time, calculation periods, and roll-up methods to their advantage. Here's a good example from Amazon's SLA:  "‘Annual Uptime Percentage' is calculated by subtracting from 100% the percentage of 5 minute periods during the Service Year in which Amazon EC2 was in the state of ‘Region Unavailable.'"

But what does that mean for the customer?  If the service is down for 4½ minutes, is it an outage?  Is it an outage if it occurs outside of standard business hours?  Does the time period go from 12:00 - 12:04, 12:05 - 12:09, and so on or does a "five minute period" begin at the point of an outage?

As companies continue to expand their use of cloud services, they must be sure they understand the terms, and cloud providers could improve by using more precise definitions in their standard SLAs.

The SLAs are not actively monitored

Of course greater precision only matters if you can effectively track performance.  Ironically, most cloud vendors have their customers do the tracking for them.  The company may be given access to a ticketing system but it is incumbent upon them to notice that there is an outage.  In other cases, the customer tracks the outage and sends an email.  Regardless of the reporting mechanism, the vendor then determines if there actually is an outage and whether a remedy is due.

Most often there is no tracking that is reported by the provider to the consumer.  Moreover, neither an active data stream, nor an audit trail is provided, thus leaving the customer to their own devices.

The key to cloud SLAs: trust but verify

In order to manage these vendors as an integral part of the corporate infrastructure, companies need to establish a "trust but verify" relationship with their vendors.  This means relying on them to report performance (including outages) on a regular basis, proactively calculate credits due and provide an audit trail.  Without this delivery assurance, many companies will likely bring some cloud services back in house or replace the vendor with a competitor who shows a more proactive approach to service levels.  Smaller MSPs who aggressively attack this market are likely to find this as an exploitable weakness.

As companies continue to adopt cloud services, they need to incorporate them into the infrastructure stack.  This means extending the view of IT services to include relationships with these vendors.  Actively managing these contracts will improve vendor performance, reduce the business risks that result from an outsourcer outage, and increase penalty collection.  In short, adding meaningful service level management to the organization is the key to incorporating the cloud into your business.

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

 

By: Erik Hille
Erik Hille joins CA Technologies as part of the acquisition of Oblicore in January 2010. With Oblicore, he was the company’s Marketing Director since July 2006. As an authority in the area of ITIL’s Service Level Management, Service Portfolio Management and Service Catalog Management processes, Erik...
Read More..

Is a revolutionary, greenfield approach to cloud The Ultimate Answer? (Or is it still 42?)

Published: May 16 2011, 11:00 AM | no comments
by Jay Fry

If you were looking for the Ultimate Answer to Life, the Universe, and Everything, chances are cloud computing is not high on your list of things to worry about. You're probably more interested in downing your Pan-Galactic Gargleblaster and getting on with things.

However, my CA Technologies colleague Andi Mann (@AndiMann on Twitter) and I used our recent Cloud Slam presentation to try to provide some straightforward advice on different approaches enterprises and service providers can take to move to a cloud-based infrastructure - while paying tribute to Douglas Adams and his Hitchhiker's Guide to the Galaxy series in the process. The result? "The Hitchhiker's Guide to Cloud Computing: Tips for Navigating the Evolutionary and Revolutionary Paths to Cloud."


Folks willing to wade through the egregious puns and overstretched sci fi references got a view of 2 different cloud computing approaches - one more evolutionary and one quite revolutionary - that customers are taking. (I touched on this topic in a previous blog myself a few months back.) For those that missed Cloud Slam, Andi posted his portion of the presentation - pros and cons of the more evolutionary approach - at his blog. I'm doing the same here, using this post to highlight what the revolutionary approach should get you thinking about.

Sometimes Marvin's right and it's easier to just start over

In looking at the pile of technology and processes that most IT shops are dealing with on a daily basis, the idea of building on top of what exists to slowly evolve your way to a more cloud-like environment sounds like a lot of work and a lot of complexity. Why? 

  • Your existing IT investments bog down new things
  • New technologies don't always fit easily in existing orgs
  • Those existing IT processes can restrict your range of innovation
  • IT organization politics & culture can put up some impressive resistance


Yes, the roadblocks seem big enough to depress even Marvin the Paranoid Android.

A ‘probable' option: a turnkey cloud platform

One way of getting to the cloud through the logjam is to kick your Infinite Improbability Drive into high gear. A more probable way? Use a turnkey cloud platform that picks up where server virtualization leaves off.


Virtualization breaks the chains between the hardware resources and the applications, but is still weighed down by networking and storage concerns. A more revolutionary approach is to set up a pool of computing resources and then create a virtual business service to run on top of that. A virtual business service is a multi-tier application and its infrastructure packaged together as a single object that can be moved, scaled, and replicated as needed. This approach allows you to skip right past a lot of the drawbacks of virtualization and evolving your existing systems toward a cloud architecture. For example, load balancers, SANs, and switches become virtual, programmable items.

Why use a revolutionary approach?


This revolutionary approach to cloud is an economic and agility game-changer for IT, enabling you to go far beyond what is enabled by simple server virtualization. It sets up huge potential improvements in the speed and operational expense of managing your applications and infrastructure - I can point you to at least one product in this space where you can literally draw what you need. This approach lets IT enter into conversations about your org's business needs - conversation it wouldn't have been in before. Service providers can use this approach to deliver cloud offerings faster, while building margin at the same time. Enterprises can make themselves ready to move apps to and from multiple different service providers.

In a world which IT has been a bit timid at taking a stand on cloud, this approach gives IT a position of strength to deliver what the business is asking for. It's not a bad way to come out looking like a hyper-intelligent, pan-dimensional being.

What the revolutionary approach looks like in the real world

At Cloud Slam, I talked about two customers taking this approach today that I know about from our work here at CA Technologies.

PGi: PGi turned to the cloud to help it quickly roll out new advanced meeting, conferencing and collaboration solutions services worldwide at a much faster pace and, as it turned out, a far lower price point than they could otherwise. As PGi enters new markets, it needs to quickly secure scalable data center resources near the new markets it will be serving to ensure the best service for its new customers. Building a new data center is extremely expensive and time-consuming; it can typically take about 18 months to create a new data center. Instead, PGi subscribes to data center capacity from a set of different service providers.

PGi uses CA 3Tera AppLogic to create a movable "infrastructure stack" supporting the services it creates. This infrastructure stack consists of all of the servers, firewalls, storage and other components uniquely configured to support a given service, and can be moved with the click of a button from one service providers' network to another. This way, PGi can choose the provider with the right price points and geographic coverage for each new market it enters. It can even easily move workloads between its own data centers and service providers' networks.

PGi's Chief Technology Officer David Guthrie (who has a video clip up on CA.com talking about all this) says that "using 3Tera, we've been able to spin-up new virtual data centers to support 5 new locations for what it would have cost us to build one physical data center."PGi's time-to-market with new services has improved significantly. Previously, it would take up to 6 months to purchase new hardware resources and 4-6 weeks to deploy a new software application. Today, it takes between 2-5 days to complete these processes from start to finish.

ScaleMatrix: My second example was a new service provider customer of ours that I profiled in a recent interview. ScaleMatrix is a brand-new business that started from scratch last year. And, they're already selling cloud services to their clients. By definition, that means no legacy systems. Instead they have taken this revolutionary approach to heart. They used the CA 3Tera AppLogic software and custom-designed hardware to get their offerings off the ground. Fast. If you want more details about what ScaleMatrix has been able to do, check out their profile here.

What are the challenges to taking this revolutionary path?

All is not simple with this revolutionary path to cloud, though.

You'll break a lot of glass. You're going to have to be ready to do a lot of learning about both the approach and a new use of technology. "Antibodies" from inside and outside IT will appear to resist this, often because this is such a different way to look at things. If you do take advantage of being able to move virtual business services among different providers, vendor management will take more of your time than it has.

And, of course, fewer people have taken this path. The risks are certainly higher, but so are the rewards. Picture yourself as Arthur Dent, complete with his hitchhiking towel, his guidebook, and hopefully a whole lot more luck.


The good news...getting your organization to cloud fast


This revolutionary approach means you won't have to wait around for generations for the Ultimate Answer, or even to see the initial benefits of the move to cloud. You jump right to the end state. You get application portability, mobility, and replication as part of the deal, plus some other very useful things for free, like standard application images, DR, and security.

A word of warning, however: to hear some people tell it, you're not going to want to go back to doing things the old way.


Which path should I choose?

How do you translate all of this commentary (and the ones Andi gave) into real action? We provided a bit of a virtual Babel Fish at the end of our Cloud Slam presentation, to help you figure out whether to take Andi's more evolutionary approach, or the revolutionary one I described here.

Here are a couple situations where you'd rather take the more revolutionary approach:

You could be a service provider that needs:

  • To deliver a cloud offering now
  • To get to market with new offerings
  • To deliver multiple offerings (like IaaS and SaaS) while maintaining margin


Or, you could be an enterprise that:

  • Wants an Amazon EC2-like infrastructure internally and can build up a greenfield infrastructure. To get the benefits, you need to control the components, have standardized (x86) hardware, a spikey usage profile, and be ready for a new development model
  • Is out of time. Maybe a competitor has made a move you must counter, or maybe you're just trying to deliver something to respond quickly to a new business initiative. Either way, you've figured out that the old way won't work.



Either way - evolutionary or revolutionary - the answer that Andi and I gave in our 42-slide deck (and no, Douglas Adams fans, that wasn't a coincidence) is "Don't Panic." Both are appropriate approaches in particular situations. In fact, most organizations will probably end up pursuing both. You'll notice that the use cases that both of us gave are not mutually exclusive. Spend the time to think it through.

Hopefully this recap, alongside Andi's, gives you some useful advice to having those Deep Thoughts. And, you'll be happy to hear that gratuitous Hitchhiker's Guide references are, well, "mostly harmless."

Unlike Vogon poetry.

 

This blog is cross-posted at Data Center Dialog. Follow @jayfry3 on Twitter.

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

 

By: Jay Fry
Jay Fry is vice president of marketing, Cloud Computing, at CA Technologies. He has over 20 years of experience in marketing and management for innovative enterprise software companies. Prior to CA, Jay was vice president of marketing at cloud computing start-up Cassatt and founded the marketing department...
Read More..

More Posts Next page »