Some back to front thinking in evidence?
One of the most frequent concerns about cloud is security. Andy Buss and I were discussing this the other day as part of a research scoping exercise. We are currently designing a study to look at the risk related aspects of Software as a Service (SaaS).
Something we always try to avoid in our research and analysis is falling into trap of generalising too much. In this case, it was important to acknowledge that businesses vary significantly in terms of their risk sensitivity, e.g. based on the degree to which they are regulated, the amount of confidential or personal information they handle, their operational dependency on IT, and their general risk awareness. Attitudes to security therefore range from extreme paranoia at one end to total complacency on the other. And even within a given organisation, some systems and data will be regarded as highly sensitive, and others will not.
The logic then goes that categorisation of applications based on their risk profile is a good place to start when considering which requirements lend themselves more to cloud based deployment from a security perspective.
So far so good, but then the conversation with Andy got really interesting.
The unspoken working assumption to this point was that application profiling would allow organisations to identify low risk candidates for initial cloud activity. To put it another way, if you're concerned about the hosted services model representing a security risk, then gain some initial experience with less sensitive applications for which security is less of a consideration.
The trouble is that for many small and mid-sized businesses, it could be argued that such advice would be flawed. Whatever the current perception, the reality is that a reputable service provider will almost certainly be able to manage application access and information security better than the majority of smaller businesses (and arguably many larger ones), so data and transactions would probably be a lot more secure in a third party hosting environment. The reasoning here is not rocket science, even though it may not be obvious to many. Service providers have the economy of scale to justify investment in top-notch technology and skills in a way that SMBs, with the best will in the world, could only dream of.
As responsible analysts, perhaps we should therefore be turning the logic on its head and advising at least some organisations to prioritise putting their most sensitive rather than least sensitive applications and data sets in the cloud first. While the original opposite view might be intuitively appropriate, that would be simply pandering to ignorance and ill-considered prejudices.
As this point, I can almost hear the abuse being directed at whatever medium you are reading this on – “Bloody naïve ivory tower analysts that have never done a real day’s work in the real world giving us bloody stupid advice about putting our most sensitive data into the hands of ‘fly-by-night’ cloud upstarts? They should get themselves a proper job and stop writing such crap”.
Then again, maybe this line of reasoning has got you thinking, which to be honest, is all I am trying to achieve.
In the real world, of course, it’s not legitimate to provide sweeping advice like the above. But neither does it make sense for those in IT to make sweeping generalisations about whether cloud services are or aren’t a good idea, on security or any other grounds. The point is that it needs some thinking about, and sometimes the most obvious conclusion can prove to be incorrect in many scenarios.
It’s for these kinds of reasons that one of my other colleagues, Tony Lock, and I put together a paper entitled “Applied Cloud Computing: A practical guide to identifying the potential in your environment”. In many respects, this was a reaction to all of the generalised opinion we hear on both sides of the house, as both the evangelists and the sceptics are guilty of the same crime in this respect.
The reality is that it’s all about context, and what’s appropriate or meaningful in one situation could be a total non-starter in others. Then there are those grey areas where it’s difficult to call it either way. With this in mind, after almost a quarter of a century in IT, I am still waiting for an example of a technology or approach that is universally right or wrong regardless of the circumstances.
Meanwhile, if you are interested in a more practical treatment of cloud computing, including some down to earth thoughts about security, integration, management and the general impact on the IT department, you can download the abovementioned paper from here.
Sunday, November 21, 2010
Tuesday, November 02, 2010
The great mainframe utilisation debate
Are you getting the most out of yours?
Someone recently asked me why mainframes are not utilised more broadly in large organisations that have them as part of their IT infrastructure. The point of the question was not so much to do with whether the capacity in place is fully used, more that people routinely seem to put workloads that are very well suited to the mainframe onto architectures that are more costly and complex to install and run.
In terms of high level context for this debate, many IT professionals we speak with tell us that x86 scale-out architectures (including what many call ‘private cloud’) are now very efficient compared to traditional discrete server deployments for dealing with mixed workloads. Those that are more mainframe savvy, however, suggest that the ‘big iron’ is still superior when it comes to the floor space occupied, the power consumed, and the admin resources required per unit of work done.
Of course this kind of generalised view doesn’t take into account the fact that there are very well engineered and run x86 environments, and (albeit less likely) very poorly implemented mainframes. Neither does it acknowledge that the nature of certain workloads and associated constraints often precludes the mainframe as an option for hosting them.
Nevertheless, we are continually coming across examples of organisations migrating workloads from the mainframe onto, say, a Unix or x86 based Oracle system, only to find that software licence and running costs soar, and managing the peaks and troughs of demand fluctuation becomes a challenge. Similarly, there are examples of organisations procuring a whole landscape to implement a new application on a Microsoft or Oracle platform when the same requirement could be fulfilled with lower cost, space, energy, cooling and operational implications in the existing mainframe environment.
So why is this? In our experience, there are three common reasons for IT professionals being reluctant to utilise the mainframe their organisation has in place for new and changing requirements.
The first is an out of date perception of the mainframe as being totally proprietary, despite the advances made over the last decade. Today’s mainframe, for example, supports the majority of open standards that are important from a software architecture and development perspective, allowing a good degree of portability and interoperability with other systems. This includes concepts such as Web services, Service Oriented Architecture (SOA) and the use of modern programming languages.
The second reason is a perception that the mainframe is expensive. This is a more interesting one. If you were to start with a green field site, the chances are that app for app in the early days your outlay would be greater if you went down the mainframe route. There comes a point, however, when the curves cross, partly down to the fact that the incremental cost of adding an extra unit of capacity once you are past a certain level drops off considerably compared to the x86 or Unix alternatives, and partly because the mainframe rules supreme when it comes to resource utilisation.
On this last point, it is worth remembering that the architecture underpinning the modern mainframe originates from a time when computing power was extremely scarce and expensive. Right from the outset, it was highly optimised to natively balance the use of resources efficiently in a mixed and fluctuating workload environment. And over the years, it has only got better at this, not just in terms of core processing, but also via the introduction of ‘offload engines’. These are basically ancillary processors specialised to deal with certain types of processing (e.g. Java runtime execution), which are seamlessly invoked when required.
Meanwhile, Unix, Windows and Linux environments are still subject to the principle that if you optimise them for one type of workload, they won’t run other workloads as efficiently. This is why rapid provisioning to achieve dynamic flexibility in a private cloud setup typically still involves moving complete stack images around (from an appropriately configured operating system upwards) when an application needs to be allocated more resource. While some might refer to the x86 ‘virtual mainframe’, there are still some fundamental differences that have implications in terms complexity and efficiency.
The third common reason for appropriate workloads not finding their way onto the mainframe is organisational prejudice and inertia. Unfortunately, as a function of history, many mainframe groups have become politically isolated over the years. This has often come about because they are perceived as being far too obsessed with matters security, resilience and operational integrity. A common complaint from architects and developers in the distributed computing world is that they are made to jump through hoops to get even the simplest of things done when they try to engage with the mainframe guys.
The irony is that many of those responsible for distributed systems are nowadays striving to emulate the traits they have previously criticised. As x86 architectures are increasingly used for business critical applications, for example, a lot more attention is having to be paid to security, resilience and so on. Nevertheless, when it comes to company politics, double standards are applied, and one man’s rigour is another man's uptight paranoia.
When we pull all of the above together, the upshot is that many large organisations are sitting on an asset that could do much more for them and help them meet some of their operational, environmental and cost reduction objectives, but they are not taking full advantage of it. Expecting busy rank-and-file IT practitioners to deal with the barriers we have discussed, however, is unrealistic.
With this in mind, there are two groups that are important: CIOs, who can evaluate the role of the mainframe in the big picture context and start to break down some of the barriers through a combination of policy, education, and the encouragement of collaboration between teams, and architects, who can apply a much more objective approach to evaluating practical requirements and making sure workloads end up on the right technical architecture for the right reasons.
If you are sceptical about the relevance of some of the things we have been discussing, it is worth considering that one of the reasons the mainframe is often not front of mind when it comes to future planning and new requirements is because it largely just sits there doing what it is supposed to do – i.e. handing complex and critical computing requirements - with minimal operational overhead and distraction. I’m sure a lot of people nurturing x86 infrastructures wish they could say the same about their environments.
Someone recently asked me why mainframes are not utilised more broadly in large organisations that have them as part of their IT infrastructure. The point of the question was not so much to do with whether the capacity in place is fully used, more that people routinely seem to put workloads that are very well suited to the mainframe onto architectures that are more costly and complex to install and run.
In terms of high level context for this debate, many IT professionals we speak with tell us that x86 scale-out architectures (including what many call ‘private cloud’) are now very efficient compared to traditional discrete server deployments for dealing with mixed workloads. Those that are more mainframe savvy, however, suggest that the ‘big iron’ is still superior when it comes to the floor space occupied, the power consumed, and the admin resources required per unit of work done.
Of course this kind of generalised view doesn’t take into account the fact that there are very well engineered and run x86 environments, and (albeit less likely) very poorly implemented mainframes. Neither does it acknowledge that the nature of certain workloads and associated constraints often precludes the mainframe as an option for hosting them.
Nevertheless, we are continually coming across examples of organisations migrating workloads from the mainframe onto, say, a Unix or x86 based Oracle system, only to find that software licence and running costs soar, and managing the peaks and troughs of demand fluctuation becomes a challenge. Similarly, there are examples of organisations procuring a whole landscape to implement a new application on a Microsoft or Oracle platform when the same requirement could be fulfilled with lower cost, space, energy, cooling and operational implications in the existing mainframe environment.
So why is this? In our experience, there are three common reasons for IT professionals being reluctant to utilise the mainframe their organisation has in place for new and changing requirements.
The first is an out of date perception of the mainframe as being totally proprietary, despite the advances made over the last decade. Today’s mainframe, for example, supports the majority of open standards that are important from a software architecture and development perspective, allowing a good degree of portability and interoperability with other systems. This includes concepts such as Web services, Service Oriented Architecture (SOA) and the use of modern programming languages.
The second reason is a perception that the mainframe is expensive. This is a more interesting one. If you were to start with a green field site, the chances are that app for app in the early days your outlay would be greater if you went down the mainframe route. There comes a point, however, when the curves cross, partly down to the fact that the incremental cost of adding an extra unit of capacity once you are past a certain level drops off considerably compared to the x86 or Unix alternatives, and partly because the mainframe rules supreme when it comes to resource utilisation.
On this last point, it is worth remembering that the architecture underpinning the modern mainframe originates from a time when computing power was extremely scarce and expensive. Right from the outset, it was highly optimised to natively balance the use of resources efficiently in a mixed and fluctuating workload environment. And over the years, it has only got better at this, not just in terms of core processing, but also via the introduction of ‘offload engines’. These are basically ancillary processors specialised to deal with certain types of processing (e.g. Java runtime execution), which are seamlessly invoked when required.
Meanwhile, Unix, Windows and Linux environments are still subject to the principle that if you optimise them for one type of workload, they won’t run other workloads as efficiently. This is why rapid provisioning to achieve dynamic flexibility in a private cloud setup typically still involves moving complete stack images around (from an appropriately configured operating system upwards) when an application needs to be allocated more resource. While some might refer to the x86 ‘virtual mainframe’, there are still some fundamental differences that have implications in terms complexity and efficiency.
The third common reason for appropriate workloads not finding their way onto the mainframe is organisational prejudice and inertia. Unfortunately, as a function of history, many mainframe groups have become politically isolated over the years. This has often come about because they are perceived as being far too obsessed with matters security, resilience and operational integrity. A common complaint from architects and developers in the distributed computing world is that they are made to jump through hoops to get even the simplest of things done when they try to engage with the mainframe guys.
The irony is that many of those responsible for distributed systems are nowadays striving to emulate the traits they have previously criticised. As x86 architectures are increasingly used for business critical applications, for example, a lot more attention is having to be paid to security, resilience and so on. Nevertheless, when it comes to company politics, double standards are applied, and one man’s rigour is another man's uptight paranoia.
When we pull all of the above together, the upshot is that many large organisations are sitting on an asset that could do much more for them and help them meet some of their operational, environmental and cost reduction objectives, but they are not taking full advantage of it. Expecting busy rank-and-file IT practitioners to deal with the barriers we have discussed, however, is unrealistic.
With this in mind, there are two groups that are important: CIOs, who can evaluate the role of the mainframe in the big picture context and start to break down some of the barriers through a combination of policy, education, and the encouragement of collaboration between teams, and architects, who can apply a much more objective approach to evaluating practical requirements and making sure workloads end up on the right technical architecture for the right reasons.
If you are sceptical about the relevance of some of the things we have been discussing, it is worth considering that one of the reasons the mainframe is often not front of mind when it comes to future planning and new requirements is because it largely just sits there doing what it is supposed to do – i.e. handing complex and critical computing requirements - with minimal operational overhead and distraction. I’m sure a lot of people nurturing x86 infrastructures wish they could say the same about their environments.
Subscribe to:
Posts (Atom)