I have recently been involved in a number of vendor events in which the keynote focused on the massive change that cloud computing is supposedly bringing to our industry, only to be followed by feedback from customers, embarrassingly sometimes from the same stage, making it clear that that senior IT professionals are generally not swallowing the hype at the moment.
While people are interested, it is clear that most regard developments in cloud services as just an evolution of hosting and outsourcing - not necessarily without value, but to be thought of in a similar way when it comes to due diligence and decision making. Capabilities of service providers to one side, from an internal policy perspective, if you have previously shied away from making extensive use of hosted services for reasons of security, compliance, trust, etc, then it is unlikely that introducing what is in effect just a variation on a 30-year-old model will change this. On the other hand, if you're the kind of organisation that has always been comfortable with the use of third party hosted services, then, while you might find some of the new commercial models and the concept of elasticity interesting in some scenarios, you are unlikely to regard cloud computing as the revolutionary concept that is being peddled in keynotes and PowerPoint by the vendor community.
I personally think it is a bit of a shame that vendors feel they cannot take a more balanced and measured approach. The big danger is that over-positioning can easily lead to customers dismissing everything being said and missing out on some of the opportunities that the collection of technologies and services currently brought together under the cloud computing umbrella represent. For those that look at developments objectively, there really are some good things happening that throw up interesting opportunities to streamline IT delivery if you can figure out where and how the new stuff fits.
While there continues to be incongruity between what vendors are telling us customers need, want, and are doing, and what the customers themselves are actually saying, the credibility gap that exists at the moment between cloud marketeers and IT decision makers will continue.
Having said this, the disjoint does present some interesting opportunities for mischief making. If you want to read about one of those, and an interesting issue that occurred to me at one of the abovementioned events, see 'There's no escaping the cloud'.
Thursday, August 27, 2009
Tuesday, August 25, 2009
There’s no escaping the cloud
You can run, but you can’t hide
So you think the cloud is not for you? If that's the case, you are not alone. Feedback from we get from IT professionals has been consistently mixed on the subject of cloud computing. In spite of all the hype, many working at the sharp end in mainstream IT departments remain sceptical.
While some dispute the economics and dismiss the claims of the evangelists as being wildly exaggerated, others point to some of the integration challenges of getting multiple cloud services working together with your in-house systems. There are then the questions about how to coordinate security and access policy across multiple operating domains, the dangers of getting locked into proprietary services, and, quite frankly, the readiness of some cloud service providers with a limited track record and/or more of a consumer background to step up to the mark when it comes to supporting core business processes.
By far the most commonly heard concern, however, is that of trust. Many IT pros are reticent about handing the corporate crown jewels, i.e. core information assets, across to a third party for safe keeping, especially when that third party is a US multinational perceived to be open to governmental snooping under the pretence of antiterrorism legislation. And regardless of how robust the provider’s security infrastructure appears to be in physical terms, stories of admin passwords escaping into the wild and exposing private information have a tendency to feed the fears of the sceptics.
One response to this is to simply sit tight and carry on with the 'box hugging' approach, maintaining everything in house where you can keep an eye on it. But does that mean information pertinent to your organisation's business will be 'safe’ from the cloud?
I had interesting exchange a few months ago at a vendor conference I attended that cast doubt on this. As is becoming very clichéd nowadays, the senior exec stood up and gave a keynote talking about how cloud computing was the future and how his company was well positioned to help organisations 'make the transition’. You would get the impression from listening to him that the whole world was committed to embracing this brand-new disruptive paradigm shift that was taking place. To illustrate the point he talked about how the use of Salesforce.com had transformed his own organisation.
The following speaker that stood up was one of the vendor's customers - a big financial institution. After talking about how the vendor's traditional product offerings had helped his organisation, the floor was opened to Q&A. One of the questions asked at this point was to what degree the company had embraced cloud computing, to which the answer was not really at all because, you guessed it, the idea of the bank’s data and/or core business systems being looked after by a generic third-party would be a 'difficult sell' to business stakeholders. While bespoke hosting arrangements with a trusted traditional outsourcer might be one thing, this utility stuff is a different kettle of fish altogether.
Feeling in a slightly mischievous mood, I stuck up my hand, reminded the presenter that the vendor hosting the conference had described the bank as a strategic customer, and had also talked about all of its sales and account management needs being fulfilled by Salesforce.com. Given the deep interaction between the two companies, I therefore suggested that a lot of proprietary information about the bank was probably being maintained in the cloud whether they liked it, trusted it, or not. This would, for example, include the names, positions and responsibilities of key people, and who knows what other background on each, along with details of not only past but also future projects, which trusted suppliers had been made aware of in confidence, or which had been mentioned indiscreetly by an employee over a beer with a salesperson. When I asked whether the aforementioned bank stakeholders were aware of this, or how they would feel if they realised it, the response was merely that this was an ‘interesting question’.
The point here was not to pass judgement on whether cloud services are a good or a bad thing, either in absolute terms or for any given organisation, but simply to highlight the fact that there really is no escaping the impact of this trend. In the example given, we were talking about CRM data, but as cloud-based ERP gets used in a collaborative supply chain context, as sensitive contract information ends up in the inbox of a supplier, customer or partner who happens to be using Google's hosted email service, and so on, we have to accept that the security and privacy of our proprietary business data will increasingly be dependent on cloud providers.
As the bank’s spokesperson said, this really is a very interesting problem, and there is no easy answer to dealing with it. Some cloud providers are clearly very competent and probably don't represent a significant risk, but if someone we deal with is putting information we care about into the hands of dodgy or inexperienced cloud players, there is a potential exposure, at least theoretically.
But is this a real problem, or something we shouldn't get too hung up about? Perhaps it's a question of making sure policies are in place to deal with the sharing of information or the vetting of third parties before sensitive information is shared with them. Then again, we could ask whether anything has really changed. After all, how well do we police the way in which other parties store and manage information that is confidential or sensitive to our business now?
So you think the cloud is not for you? If that's the case, you are not alone. Feedback from we get from IT professionals has been consistently mixed on the subject of cloud computing. In spite of all the hype, many working at the sharp end in mainstream IT departments remain sceptical.
While some dispute the economics and dismiss the claims of the evangelists as being wildly exaggerated, others point to some of the integration challenges of getting multiple cloud services working together with your in-house systems. There are then the questions about how to coordinate security and access policy across multiple operating domains, the dangers of getting locked into proprietary services, and, quite frankly, the readiness of some cloud service providers with a limited track record and/or more of a consumer background to step up to the mark when it comes to supporting core business processes.
By far the most commonly heard concern, however, is that of trust. Many IT pros are reticent about handing the corporate crown jewels, i.e. core information assets, across to a third party for safe keeping, especially when that third party is a US multinational perceived to be open to governmental snooping under the pretence of antiterrorism legislation. And regardless of how robust the provider’s security infrastructure appears to be in physical terms, stories of admin passwords escaping into the wild and exposing private information have a tendency to feed the fears of the sceptics.
One response to this is to simply sit tight and carry on with the 'box hugging' approach, maintaining everything in house where you can keep an eye on it. But does that mean information pertinent to your organisation's business will be 'safe’ from the cloud?
I had interesting exchange a few months ago at a vendor conference I attended that cast doubt on this. As is becoming very clichéd nowadays, the senior exec stood up and gave a keynote talking about how cloud computing was the future and how his company was well positioned to help organisations 'make the transition’. You would get the impression from listening to him that the whole world was committed to embracing this brand-new disruptive paradigm shift that was taking place. To illustrate the point he talked about how the use of Salesforce.com had transformed his own organisation.
The following speaker that stood up was one of the vendor's customers - a big financial institution. After talking about how the vendor's traditional product offerings had helped his organisation, the floor was opened to Q&A. One of the questions asked at this point was to what degree the company had embraced cloud computing, to which the answer was not really at all because, you guessed it, the idea of the bank’s data and/or core business systems being looked after by a generic third-party would be a 'difficult sell' to business stakeholders. While bespoke hosting arrangements with a trusted traditional outsourcer might be one thing, this utility stuff is a different kettle of fish altogether.
Feeling in a slightly mischievous mood, I stuck up my hand, reminded the presenter that the vendor hosting the conference had described the bank as a strategic customer, and had also talked about all of its sales and account management needs being fulfilled by Salesforce.com. Given the deep interaction between the two companies, I therefore suggested that a lot of proprietary information about the bank was probably being maintained in the cloud whether they liked it, trusted it, or not. This would, for example, include the names, positions and responsibilities of key people, and who knows what other background on each, along with details of not only past but also future projects, which trusted suppliers had been made aware of in confidence, or which had been mentioned indiscreetly by an employee over a beer with a salesperson. When I asked whether the aforementioned bank stakeholders were aware of this, or how they would feel if they realised it, the response was merely that this was an ‘interesting question’.
The point here was not to pass judgement on whether cloud services are a good or a bad thing, either in absolute terms or for any given organisation, but simply to highlight the fact that there really is no escaping the impact of this trend. In the example given, we were talking about CRM data, but as cloud-based ERP gets used in a collaborative supply chain context, as sensitive contract information ends up in the inbox of a supplier, customer or partner who happens to be using Google's hosted email service, and so on, we have to accept that the security and privacy of our proprietary business data will increasingly be dependent on cloud providers.
As the bank’s spokesperson said, this really is a very interesting problem, and there is no easy answer to dealing with it. Some cloud providers are clearly very competent and probably don't represent a significant risk, but if someone we deal with is putting information we care about into the hands of dodgy or inexperienced cloud players, there is a potential exposure, at least theoretically.
But is this a real problem, or something we shouldn't get too hung up about? Perhaps it's a question of making sure policies are in place to deal with the sharing of information or the vetting of third parties before sensitive information is shared with them. Then again, we could ask whether anything has really changed. After all, how well do we police the way in which other parties store and manage information that is confidential or sensitive to our business now?
Wednesday, August 19, 2009
Unified Communications in Context
We here at Freeform Dynamics have been tracking developments in the unified communications market for quite a while now. If we go back three years, it was still largely all about visions and theory, with very little activity in the mainstream in terms of real life adoption.
As time went on, we started to see activity as a result of traditional communications players such as Cisco, Avaya, Siemens, Nortel, NEC, etc up-selling from IP telephony requirements. Where this happened, however, customers often failed to capitalise on the true potential of unified communications from a value perspective, as initiatives had not been set in the appropriate business context with the necessary business and IT stakeholders involved. Indeed, one of the challenges has been how to articulate the problems, opportunities, principles and benefits associated with unified communications in a meaningful manner, which is why I wrote ‘Joining the Dots of Business Communications’ a little while back, to at least provide some clarity around the basics.
As economic pressure has continued to impact IT and communications related investment decisions, the need for precision in terms of business context and rationale has become even more critical, especially as one of the most common objections to embracing unified communications is difficulty making the business case. While no one argues with the vision of removing the friction and disjoints in the way we communicate today by implementing a more seamless approach that cuts across telephony, conferencing, e-mail, instant messaging, and so on, many say they have more pressing demands on the finite funding and resources they have available to them.
One of the things that doesn't particularly help here is the generic way in which the unified communications proposition is often presented. Whether it’s vendors or pundits, there is a tendency to discuss the area without distinguishing between the different scenarios in which the same (or similar) underlying technology can be applied. The reason this is significant is because it is only possible to get 'crunchy’ about defining specific benefits and practicalities if you are precise about the kind of deployment you are considering.
When we get into discussions with those who are evaluating the relevance of unified communications to their business or trying to establish the best way forward, we find it very useful to run through some of the different types of initiative we see. At the highest level, these can be boiled down to three important categories that each map onto different drivers and stakeholders within the business:
General Comms and Collaboration
The business problem being tackled here is removal of the communications related fragmentation and disjoints associated with the activities of professional workers such as managers and executives, sales and marketing personnel, consultants and engineers, etc. While there are some important cost and productivity related benefits to be realised in this area, allowing professional workers to communicate more quickly, reliably, and in a richer manner enhances decision making, sales effectiveness, innovation and team working in general. Furthermore, facilities such as smart call routing, unified inboxes, etc, lead to improved organisational responsiveness to external parties, whether in a sales, partnering, supply chain, or service context. In many ways, this form of unified communications, including the mobile technology element, is best thought of as an enabler of any broader workforce collaboration initiative already in place or being considered.
Business Process Optimisation
Some vendors have started to talk about ‘Communications Enabled Business Processes’ (CEBP), which is essentially about implementing enhanced communication capability to streamline more structured activities within the business. The premise here is that the performance of many processes is directly dependent upon the efficiency with which individual contact and response takes place. This could be as simple as tracking down an appropriate individual and confirming their availability to deal with a job, incident or issue, and there are many examples of this across industries such as healthcare, manufacturing, utilities, telecoms, etc. It could also be more sophisticated, e.g. allowing key resources to be brought together automatically for troubleshooting or remedial purposes as a result of a systems-triggered event in a logistics, manufacturing or service management context, for example. The difference is that while communication is initiated by an individual on an ad hoc or discretionary basis in the general comms and collaboration scenario, with CEBP, it is kicked off in accordance with predefined rules as an embedded part of a structured process.
Enhanced Contact Centre
The use of unified communications can move the traditional call centre concept forward in a couple of different ways. Firstly, applying some of the same principles already discussed in relation to the first two categories of initiative, it is possible to extend customer service activity, for example, beyond the walls of the call centre to bring expertise residing in other departments or even in the field. The ease with which availability can be determined and calls routed in a device and location independent manner makes this possible. Taking this to the next level, unified communications enables the move to a more virtual approach, in which the need for centralised resources in a physical call centre is diminished, or even done away with all together. Some organisations are already taking advantage of this to incorporate home-based agents seamlessly into their customer service operations. Beyond the internal dimension, the same underlying unified communications technology can also be used as a foundation for enhancing communication with customers, allowing richer interaction across a range of different mechanisms to be offered without running into routing and efficiency issues.
These three flavours of unified communications initiatives illustrate that even at the highest level, the technologies and solutions we are talking about here can be applied in quite different ways. Some vendors, such as IBM and Avaya, have a good handle on this and can advise accordingly. Others still tend to focus on one type of deployment, e.g. Microsoft puts the emphasis on enhancing the communication and collaboration of ‘information workers’ (the first category above). As we said at the beginning, some are also still discussing unified communications in more of a generic way, and can find it hard to bridge the gap between the high level vision and specific business benefits that can be assessed objectively.
Of course there are also the differences in implementation requirements to consider. It is beyond the scope of this article to go into detail here, but suffice it to say that interoperability with existing telephony, email and desktop productivity solutions is key for general comms and collaboration; integration, e.g. via the SOA model, with both bespoke and packaged applications will be required for CEBP, and the ability to work with CRM and other call centre technology is key in the contact centre scenario.
Having said all this, I do still have some sympathy with those who discuss unified communications as just 'one thing', as this viewpoint does have some merit if you put the business context to one side and focus purely on the architectural perspective. It could be argued, for example, that wherever you start in terms of type of deployment, if you implement the technology in the appropriate manner, you will be laying the infrastructural foundations to deal with subsequent requirements in other areas down the line.
The trouble is that this doesn't help with initial scoping, understanding and justification when each type of solution falls within the domain of different budget structures and business sponsors. The CIO and their team are therefore going to be in that familiar situation of trying to balance longer term infrastructure development interests at an overall enterprise level with the immediate business needs that are used as the foundation for justifying and funding the initial project.
The one thing for certain, though, is that trying to secure business buy-in to the high level unified communications vision and proposition for the organisation as a whole is not going to be that easy in the current climate. Getting specific in the way we have described is therefore key to getting things moving and starting to take the organisation forward in the right direction.
As time went on, we started to see activity as a result of traditional communications players such as Cisco, Avaya, Siemens, Nortel, NEC, etc up-selling from IP telephony requirements. Where this happened, however, customers often failed to capitalise on the true potential of unified communications from a value perspective, as initiatives had not been set in the appropriate business context with the necessary business and IT stakeholders involved. Indeed, one of the challenges has been how to articulate the problems, opportunities, principles and benefits associated with unified communications in a meaningful manner, which is why I wrote ‘Joining the Dots of Business Communications’ a little while back, to at least provide some clarity around the basics.
As economic pressure has continued to impact IT and communications related investment decisions, the need for precision in terms of business context and rationale has become even more critical, especially as one of the most common objections to embracing unified communications is difficulty making the business case. While no one argues with the vision of removing the friction and disjoints in the way we communicate today by implementing a more seamless approach that cuts across telephony, conferencing, e-mail, instant messaging, and so on, many say they have more pressing demands on the finite funding and resources they have available to them.
One of the things that doesn't particularly help here is the generic way in which the unified communications proposition is often presented. Whether it’s vendors or pundits, there is a tendency to discuss the area without distinguishing between the different scenarios in which the same (or similar) underlying technology can be applied. The reason this is significant is because it is only possible to get 'crunchy’ about defining specific benefits and practicalities if you are precise about the kind of deployment you are considering.
When we get into discussions with those who are evaluating the relevance of unified communications to their business or trying to establish the best way forward, we find it very useful to run through some of the different types of initiative we see. At the highest level, these can be boiled down to three important categories that each map onto different drivers and stakeholders within the business:
General Comms and Collaboration
The business problem being tackled here is removal of the communications related fragmentation and disjoints associated with the activities of professional workers such as managers and executives, sales and marketing personnel, consultants and engineers, etc. While there are some important cost and productivity related benefits to be realised in this area, allowing professional workers to communicate more quickly, reliably, and in a richer manner enhances decision making, sales effectiveness, innovation and team working in general. Furthermore, facilities such as smart call routing, unified inboxes, etc, lead to improved organisational responsiveness to external parties, whether in a sales, partnering, supply chain, or service context. In many ways, this form of unified communications, including the mobile technology element, is best thought of as an enabler of any broader workforce collaboration initiative already in place or being considered.
Business Process Optimisation
Some vendors have started to talk about ‘Communications Enabled Business Processes’ (CEBP), which is essentially about implementing enhanced communication capability to streamline more structured activities within the business. The premise here is that the performance of many processes is directly dependent upon the efficiency with which individual contact and response takes place. This could be as simple as tracking down an appropriate individual and confirming their availability to deal with a job, incident or issue, and there are many examples of this across industries such as healthcare, manufacturing, utilities, telecoms, etc. It could also be more sophisticated, e.g. allowing key resources to be brought together automatically for troubleshooting or remedial purposes as a result of a systems-triggered event in a logistics, manufacturing or service management context, for example. The difference is that while communication is initiated by an individual on an ad hoc or discretionary basis in the general comms and collaboration scenario, with CEBP, it is kicked off in accordance with predefined rules as an embedded part of a structured process.
Enhanced Contact Centre
The use of unified communications can move the traditional call centre concept forward in a couple of different ways. Firstly, applying some of the same principles already discussed in relation to the first two categories of initiative, it is possible to extend customer service activity, for example, beyond the walls of the call centre to bring expertise residing in other departments or even in the field. The ease with which availability can be determined and calls routed in a device and location independent manner makes this possible. Taking this to the next level, unified communications enables the move to a more virtual approach, in which the need for centralised resources in a physical call centre is diminished, or even done away with all together. Some organisations are already taking advantage of this to incorporate home-based agents seamlessly into their customer service operations. Beyond the internal dimension, the same underlying unified communications technology can also be used as a foundation for enhancing communication with customers, allowing richer interaction across a range of different mechanisms to be offered without running into routing and efficiency issues.
These three flavours of unified communications initiatives illustrate that even at the highest level, the technologies and solutions we are talking about here can be applied in quite different ways. Some vendors, such as IBM and Avaya, have a good handle on this and can advise accordingly. Others still tend to focus on one type of deployment, e.g. Microsoft puts the emphasis on enhancing the communication and collaboration of ‘information workers’ (the first category above). As we said at the beginning, some are also still discussing unified communications in more of a generic way, and can find it hard to bridge the gap between the high level vision and specific business benefits that can be assessed objectively.
Of course there are also the differences in implementation requirements to consider. It is beyond the scope of this article to go into detail here, but suffice it to say that interoperability with existing telephony, email and desktop productivity solutions is key for general comms and collaboration; integration, e.g. via the SOA model, with both bespoke and packaged applications will be required for CEBP, and the ability to work with CRM and other call centre technology is key in the contact centre scenario.
Having said all this, I do still have some sympathy with those who discuss unified communications as just 'one thing', as this viewpoint does have some merit if you put the business context to one side and focus purely on the architectural perspective. It could be argued, for example, that wherever you start in terms of type of deployment, if you implement the technology in the appropriate manner, you will be laying the infrastructural foundations to deal with subsequent requirements in other areas down the line.
The trouble is that this doesn't help with initial scoping, understanding and justification when each type of solution falls within the domain of different budget structures and business sponsors. The CIO and their team are therefore going to be in that familiar situation of trying to balance longer term infrastructure development interests at an overall enterprise level with the immediate business needs that are used as the foundation for justifying and funding the initial project.
The one thing for certain, though, is that trying to secure business buy-in to the high level unified communications vision and proposition for the organisation as a whole is not going to be that easy in the current climate. Getting specific in the way we have described is therefore key to getting things moving and starting to take the organisation forward in the right direction.
Server Virtualisation Workshop
One of the things I love about my job is the interaction I have with IT professionals out there just getting on with stuff in mainstream IT departments. It provides a real contrast to many of the discussions around visions, transformations and magic bullets that all too often characterise the vendor pitches and briefings we as analysts are continually on the receiving end of.
As part of our community activities, one of the mechanisms we use to tune into experiences and perceptions at the sharp end is the online workshop. In a nutshell, we work with one of the big news sites, e.g. The Register, and elicit feedback and discussion by publishing a series of thought-provoking articles exploring a particular topic from various different angles. Along the way, we run surveys to provide more quantitative intelligence on what's going on.
At the time of writing, we are working through the topic of virtualisation in one of these workshops, and have just finished dealing with the x86 server side of the equation. If it's an area you are interested in, check out the links below, and don't just read the articles, have a scroll down some of the comments attached to each. Various bits of feedback bring the discussion of costs and benefits to life, for example, confirming some of the stuff we get from vendors, but also throwing up some things we don't often hear, or providing real world examples of principles in action or practical considerations.
We'll be writing and publishing a summary report on all of this soon (one of my jobs for this week), but if you are into virtualisation and are interested in a bunch of real world views and experiences, I encourage you to click across and have a browse of the raw material in the meantime.
Virtualisation Workshop Links
Is server virtualization delivering for you yet?
Real world, real benefits?
Virtualization payback, now and in the future
Do you really want to join this pool party?
Virtualization rocks - but who cares beyond consolidation?
Roundup of discussion from Week 1
Server virtualization – what could possibly go wrong?
Rise of the Virtual Machines
Virtualization security – oxymoron or perfect partnership?
New environments, new security risks
Does *free* virtualization = certain chaos?
Round-up of discussion from week two
Counting the cost of virtualization
Avoiding nasty surprises
When is an operating system not an operating system?
Challenging traditional ideas
Getting under the shell of virtualization
Week 3 round-up: On kernels and other nut puns
The discussion within the workshop is now moving on to desktop virtualisation, and we'll be finishing off by taking a look at the relationship between virtualisation and cloud computing. So, feel free to check here for new articles and feedback over the next few weeks.
As part of our community activities, one of the mechanisms we use to tune into experiences and perceptions at the sharp end is the online workshop. In a nutshell, we work with one of the big news sites, e.g. The Register, and elicit feedback and discussion by publishing a series of thought-provoking articles exploring a particular topic from various different angles. Along the way, we run surveys to provide more quantitative intelligence on what's going on.
At the time of writing, we are working through the topic of virtualisation in one of these workshops, and have just finished dealing with the x86 server side of the equation. If it's an area you are interested in, check out the links below, and don't just read the articles, have a scroll down some of the comments attached to each. Various bits of feedback bring the discussion of costs and benefits to life, for example, confirming some of the stuff we get from vendors, but also throwing up some things we don't often hear, or providing real world examples of principles in action or practical considerations.
We'll be writing and publishing a summary report on all of this soon (one of my jobs for this week), but if you are into virtualisation and are interested in a bunch of real world views and experiences, I encourage you to click across and have a browse of the raw material in the meantime.
Virtualisation Workshop Links
Is server virtualization delivering for you yet?
Real world, real benefits?
Virtualization payback, now and in the future
Do you really want to join this pool party?
Virtualization rocks - but who cares beyond consolidation?
Roundup of discussion from Week 1
Server virtualization – what could possibly go wrong?
Rise of the Virtual Machines
Virtualization security – oxymoron or perfect partnership?
New environments, new security risks
Does *free* virtualization = certain chaos?
Round-up of discussion from week two
Counting the cost of virtualization
Avoiding nasty surprises
When is an operating system not an operating system?
Challenging traditional ideas
Getting under the shell of virtualization
Week 3 round-up: On kernels and other nut puns
The discussion within the workshop is now moving on to desktop virtualisation, and we'll be finishing off by taking a look at the relationship between virtualisation and cloud computing. So, feel free to check here for new articles and feedback over the next few weeks.
Tuesday, August 04, 2009
Will cloud put traditional hosters out of business?
Elasticity isn't everything
It sometimes seems as if the whole world has gone cloud crazy - well at least most of the vendors, pundits and many in the media. If we listen to the evangelists, the days of the enterprise data centre are numbered and players like Google, Amazon and Microsoft will inherit the earth. Even David Cameron, the illustrious leader of the opposition to our UK government, has been talking about handing over the country's health records for storage and management to one of these big American multinationals.
In the midst of all this noise and hype, many have lost sight of the fact that getting a third party to run some of your infrastructure for you is a model that has been around for at least three decades. Indeed, those who have been taking advantage of hosted services, or on the other side of the fence, delivering them, must be wondering what all the fuss is about. Just what, exactly, is this cloud thing bringing to the party that's apparently going to change the way everything works?
Well to deal with this question, we need to be very clear what we mean by cloud services. There are all kinds of definitions kicking about, but most of it boils down to three types of offering. If we start at the top, we have software as a service (SaaS), which is essentially based on the concept of renting application functionality from a service provider rather than buying, installing and running software yourself. Offerings within this range from services such as Salesforce.com at one end, delivering the equivalent of a complete application suite, to players like MessageLabs at the other, whose services are designed to complement your operational infrastructure.
If we drop down a level in the systems stack, we then have platform as a service (PaaS), which is all about providing, well, a platform in the cloud, upon which applications can be developed and executed. Players like Google, again Salesforce.com (this time with Force.com), and Microsoft (with Azure) exist in this space. Facilities provided include things like database management, security, workflow management, application serving, and so on. Once you have developed your application, it then takes advantage of the scalability and on-demand economics associated with the cloud computing model at execution time, which is great for highly dynamic externally facing applications, for example. The snag is, at least for today, that these environments are very proprietary, offering little in the way of portability should you want to move your application elsewhere.
We then get to the bottom of the stack, and it is here that we find the concept of infrastructure as a service (IaaS). The proposition here is the offering of compute power and storage space on demand. The difference between this and the other two categories of cloud is that the software that executes is essentially yours. In practical terms, the model is based on the same principles of virtualisation that we are all familiar with in the context of server partitioning or flexible storage. Rather than running a virtual image on a partition existing on a physical server in your data centre, you spin it up on a virtual machine that you have created in the cloud. Virtual disks can be created in a similar manner to deal with the storage side of things.
“Hold on”, you might say, “but haven't we been doing this with traditional hosting companies and ISPs for a long time?” Well in terms of the basic principle of renting virtual servers from a provider to run some of your stuff on, then the answer is obviously “Yes”. The difference is that hitherto, we have generally been required to commit to that rental for a reasonable period of time and pay for the resources allocated whether we use them or not. In the cloud model, we can grab a virtual server for as little as a few hours then drop it again, and only pay for the time and/or resources that we have used. And if the load on the application fluctuates, the horsepower available to it can be adjusted accordingly. Rapid and automatic provisioning and deprovisioning, coupled with clever billing systems are the key to this on the service provider side.
With such an attractive model emerging, it begs the question of whether existing hosting companies and ISPs will be threatened by the new breed of cloud services offered by the likes of Amazon. To address this question we have to remember, however, that the kind of flexibility we have been talking about, or ‘elasticity’, as the cloud folk like to call it, is likely to come at a price. Indeed, as some of the traditional hosters have started to extend their service portfolios to include cloud type offerings, this difference becomes very apparent in their price lists (if you do the calculations).
Conveniently, however, while cloud computing advocates are constantly comparing the cost of IaaS with the cost of running on-premise equipment, they typically ignore the comparison between the elastic cloud model and the traditional static hosting approach. And when we consider that the majority of computing workloads running in the average data centre or even on existing hosted infrastructure are not that dynamic, this is quite an important difference to consider. After all, why would you pay a premium for elasticity and you don't really need it.
Looking forward, it is clear that the on-demand IaaS model will find its place for executing applications that are genuinely very dynamic in nature, or for grabbing resources to deal with transient needs such as development, testing, one-off number crunching jobs, and so on. And many of the traditional hosters have already realised this and are moving in that direction. There will, however, continue to be a demand for the kinds of hosting we have always been familiar with. Whether it's commodity server space, or more bespoke hosting arrangements, cloud is not going to kill the traditional approaches or providers.
In fact, as customers are likely to need a blend of static and dynamic hosting arrangements in most situations, providers who can offer a range of options within a single service portfolio, and for strategic hosting arrangements back that up with good quality support and account management, will continue to do well. Amazon will not, at the end of the day, rule the world.
It sometimes seems as if the whole world has gone cloud crazy - well at least most of the vendors, pundits and many in the media. If we listen to the evangelists, the days of the enterprise data centre are numbered and players like Google, Amazon and Microsoft will inherit the earth. Even David Cameron, the illustrious leader of the opposition to our UK government, has been talking about handing over the country's health records for storage and management to one of these big American multinationals.
In the midst of all this noise and hype, many have lost sight of the fact that getting a third party to run some of your infrastructure for you is a model that has been around for at least three decades. Indeed, those who have been taking advantage of hosted services, or on the other side of the fence, delivering them, must be wondering what all the fuss is about. Just what, exactly, is this cloud thing bringing to the party that's apparently going to change the way everything works?
Well to deal with this question, we need to be very clear what we mean by cloud services. There are all kinds of definitions kicking about, but most of it boils down to three types of offering. If we start at the top, we have software as a service (SaaS), which is essentially based on the concept of renting application functionality from a service provider rather than buying, installing and running software yourself. Offerings within this range from services such as Salesforce.com at one end, delivering the equivalent of a complete application suite, to players like MessageLabs at the other, whose services are designed to complement your operational infrastructure.
If we drop down a level in the systems stack, we then have platform as a service (PaaS), which is all about providing, well, a platform in the cloud, upon which applications can be developed and executed. Players like Google, again Salesforce.com (this time with Force.com), and Microsoft (with Azure) exist in this space. Facilities provided include things like database management, security, workflow management, application serving, and so on. Once you have developed your application, it then takes advantage of the scalability and on-demand economics associated with the cloud computing model at execution time, which is great for highly dynamic externally facing applications, for example. The snag is, at least for today, that these environments are very proprietary, offering little in the way of portability should you want to move your application elsewhere.
We then get to the bottom of the stack, and it is here that we find the concept of infrastructure as a service (IaaS). The proposition here is the offering of compute power and storage space on demand. The difference between this and the other two categories of cloud is that the software that executes is essentially yours. In practical terms, the model is based on the same principles of virtualisation that we are all familiar with in the context of server partitioning or flexible storage. Rather than running a virtual image on a partition existing on a physical server in your data centre, you spin it up on a virtual machine that you have created in the cloud. Virtual disks can be created in a similar manner to deal with the storage side of things.
“Hold on”, you might say, “but haven't we been doing this with traditional hosting companies and ISPs for a long time?” Well in terms of the basic principle of renting virtual servers from a provider to run some of your stuff on, then the answer is obviously “Yes”. The difference is that hitherto, we have generally been required to commit to that rental for a reasonable period of time and pay for the resources allocated whether we use them or not. In the cloud model, we can grab a virtual server for as little as a few hours then drop it again, and only pay for the time and/or resources that we have used. And if the load on the application fluctuates, the horsepower available to it can be adjusted accordingly. Rapid and automatic provisioning and deprovisioning, coupled with clever billing systems are the key to this on the service provider side.
With such an attractive model emerging, it begs the question of whether existing hosting companies and ISPs will be threatened by the new breed of cloud services offered by the likes of Amazon. To address this question we have to remember, however, that the kind of flexibility we have been talking about, or ‘elasticity’, as the cloud folk like to call it, is likely to come at a price. Indeed, as some of the traditional hosters have started to extend their service portfolios to include cloud type offerings, this difference becomes very apparent in their price lists (if you do the calculations).
Conveniently, however, while cloud computing advocates are constantly comparing the cost of IaaS with the cost of running on-premise equipment, they typically ignore the comparison between the elastic cloud model and the traditional static hosting approach. And when we consider that the majority of computing workloads running in the average data centre or even on existing hosted infrastructure are not that dynamic, this is quite an important difference to consider. After all, why would you pay a premium for elasticity and you don't really need it.
Looking forward, it is clear that the on-demand IaaS model will find its place for executing applications that are genuinely very dynamic in nature, or for grabbing resources to deal with transient needs such as development, testing, one-off number crunching jobs, and so on. And many of the traditional hosters have already realised this and are moving in that direction. There will, however, continue to be a demand for the kinds of hosting we have always been familiar with. Whether it's commodity server space, or more bespoke hosting arrangements, cloud is not going to kill the traditional approaches or providers.
In fact, as customers are likely to need a blend of static and dynamic hosting arrangements in most situations, providers who can offer a range of options within a single service portfolio, and for strategic hosting arrangements back that up with good quality support and account management, will continue to do well. Amazon will not, at the end of the day, rule the world.
Monday, August 03, 2009
SOA Performance - Seeing through the complexity creep
Had an interesting chat with the Application Performance Management (APM) team at CA about performance with respect to Service Oriented Architecture (SOA). We were comparing notes on the way in which it is easy for SOA initiatives to descend into confusion as services proliferate and knowledge of the dependencies between them gradually degrades.
From a performance and troubleshooting perspective, this can be pretty bad news as when an application slows down or breaks, it can be difficult to pinpoint where the bottleneck or fault has occurred. This is one of those nitty gritty practical issues that SOA advocates often neglect, but is a real risk for those who are upping their commitment to this distributed computing model.
While this may not be new for more experienced adopters, it is not so simple to know where to start. In an ideal world, good SOA governance would minimise the degree to which such problems occur and, for example, prevent surprises from a service being hammered into failure because a developer decided to call it from a particularly demanding application without telling anyone.
Unfortunately, however, we don’t live in an ideal world, so generating some kind of visibility of what’s going on at execution time is a requirement. Inspection of raw logs from various components in the system coupled with cleverly placed debug code are some of the more common ways of troubleshooting, but this can be tedious and time consuming.
Against this background, I had read about CA’s extension of the APM capability it acquired with Wily into the SOA domain, but hadn’t had a chance to check it out properly. I got that chance recently at CA’s analyst conference in Ottawa.
For those who don’t know the Wily solution set, it grew out of the need for tools to monitor and troubleshoot complex Java applications in high end application server environments, then evolved into more of an end to end APM system. The basic idea is to drop agents in at key points in your network to monitor transaction calls, e.g. between the web server and the application server, the application server and the database management system, and so on.
Data accumulated in this way can be used for real time monitoring and alerting, and for analysis of history for both troubleshooting and planning purposes. While a picture of end-to-end performance can be derived at an application or individual user level (something that can also be done with solutions that monitor response times ‘at the glass’), the approach adopted for the CA APM solution goes further by providing visibility into the performance of individual transaction steps behind the scenes.
As the solution has become increasingly well proven, CA has enjoyed significant growth in demand for the Wily technology, even though it is still not that widely known in the mainstream. As the solution has evolved, however, it moved on from the concept of ‘see to’ to ‘see through’ monitoring, and this is the key to helping unravel what’s going on in a complex SOA environment.
As an example, if the application being monitored makes a call to a service elsewhere on the network, it has always been possible to capture response times at that step along with diagnostic information when things go wrong. This is the ‘see to’ approach. But what if that service calls another one behind the scenes? This is where ‘see through’ visibility comes in, which can be achieved by distributing coordinated agents to equipment running relevant services, and/or by plugging an agent into the Enterprise Service Bus (ESB).
Of course CA is not the only game in town when it comes to performance management, whether in an SOA or traditional application environment, and anyone investigating this field should check out players like HP, IBM, Quest and Compuware too. I thought the insights I got from the CA guys were worth sharing, however, hopefully to stimulate some thought among IT shops who have taken a more tactical approach to SOA and have had visibility and performance issues sneak up on them over time.
It’s an interesting area that we will continue to investigate, so if you have any experience or insights yourself that you are willing to share, feel free to ping me with your thoughts.
From a performance and troubleshooting perspective, this can be pretty bad news as when an application slows down or breaks, it can be difficult to pinpoint where the bottleneck or fault has occurred. This is one of those nitty gritty practical issues that SOA advocates often neglect, but is a real risk for those who are upping their commitment to this distributed computing model.
While this may not be new for more experienced adopters, it is not so simple to know where to start. In an ideal world, good SOA governance would minimise the degree to which such problems occur and, for example, prevent surprises from a service being hammered into failure because a developer decided to call it from a particularly demanding application without telling anyone.
Unfortunately, however, we don’t live in an ideal world, so generating some kind of visibility of what’s going on at execution time is a requirement. Inspection of raw logs from various components in the system coupled with cleverly placed debug code are some of the more common ways of troubleshooting, but this can be tedious and time consuming.
Against this background, I had read about CA’s extension of the APM capability it acquired with Wily into the SOA domain, but hadn’t had a chance to check it out properly. I got that chance recently at CA’s analyst conference in Ottawa.
For those who don’t know the Wily solution set, it grew out of the need for tools to monitor and troubleshoot complex Java applications in high end application server environments, then evolved into more of an end to end APM system. The basic idea is to drop agents in at key points in your network to monitor transaction calls, e.g. between the web server and the application server, the application server and the database management system, and so on.
Data accumulated in this way can be used for real time monitoring and alerting, and for analysis of history for both troubleshooting and planning purposes. While a picture of end-to-end performance can be derived at an application or individual user level (something that can also be done with solutions that monitor response times ‘at the glass’), the approach adopted for the CA APM solution goes further by providing visibility into the performance of individual transaction steps behind the scenes.
As the solution has become increasingly well proven, CA has enjoyed significant growth in demand for the Wily technology, even though it is still not that widely known in the mainstream. As the solution has evolved, however, it moved on from the concept of ‘see to’ to ‘see through’ monitoring, and this is the key to helping unravel what’s going on in a complex SOA environment.
As an example, if the application being monitored makes a call to a service elsewhere on the network, it has always been possible to capture response times at that step along with diagnostic information when things go wrong. This is the ‘see to’ approach. But what if that service calls another one behind the scenes? This is where ‘see through’ visibility comes in, which can be achieved by distributing coordinated agents to equipment running relevant services, and/or by plugging an agent into the Enterprise Service Bus (ESB).
Of course CA is not the only game in town when it comes to performance management, whether in an SOA or traditional application environment, and anyone investigating this field should check out players like HP, IBM, Quest and Compuware too. I thought the insights I got from the CA guys were worth sharing, however, hopefully to stimulate some thought among IT shops who have taken a more tactical approach to SOA and have had visibility and performance issues sneak up on them over time.
It’s an interesting area that we will continue to investigate, so if you have any experience or insights yourself that you are willing to share, feel free to ping me with your thoughts.
Subscribe to:
Posts (Atom)