Frequently Asked Questions
Frequently Asked Questions
The transition to the cloud will be a topic of interest for a long time. As you move forward with your cloud efforts, please consider the list of frequently asked questions . We are currently working on a WIKI, but if you have additional questions to put forward in the short term, please email them to Doug Neal.
Definitions
Governance
- What do we do for governance in the cloud?
- Why does IT insist on governance? Is it needed in the cloud?
- Can governance in the cloud make use of social software?
- How do we make easier, cheaper, and faster to do it the right way than any other way?
Financial and legal issues
- What are the cost savings in moving to the cloud?
- Why does it matter how things are billed?
- Why should we be worried about switching to OPEX?
- How do we deal with licensing issues?
Security
- How much security is enough?
- How do we decide what data may live in the cloud?
- Where can I find good guidance about security issues in the cloud?
Migration issues
- What is the sequence or roadmap of moving to the cloud?
- How do we review our app portfolio?
- How do we choose what level in the cloud is appropriate?
- How does the way you provide fail-over change as you go up the stack?
- For a new application the cloud is often a no-brainer, but what are the barriers for existing applications?
- How do we deal with legacy programs?
- How do we migrate applications from the mainframe?
Operating in the cloud
- We know that we want more than just one cloud, but how many are enough?
- Can we use the cloud to handle peak loads?
- When will we be able to use the cloud for production?
- What will my data centre look like if production is in the cloud?
- What are the things that I do today that will become critical in the cloud?
The role of IT in the cloud
- Will Marketing get to the cloud before IT?
- How do we organize to take effective advantage of the cloud?
- What new jobs does IT have in the cloud?
Government issues
- As a government agency we will be forced into multiple cloud vendor relationships – how do we operate a multi-cloud?
- What is the impact of governments on how quickly the cloud evolves to meet enterprise requirements?
How do you define the cloud?
The US government National Institute of Standards and Technology is now on version 15 of what it describes as “an evolving paradigm”. The core of its definition is:
"Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models."
For the details see http://csrc.nist.gov/groups/SNS/cloud-computing/
We are more interested in the impact of cloud computing on the business. We define cloud computing as follows:
Cloud computing is the latest major phase of information technology evolution, in which all the major components of computing – hardware, software, storage, networking, data, information, and expertise – are becoming available virtually, globally and on-demand from either "multi-tenant" public or single-customer private facilities, typically through some type of subscription, pay-per-use or other variable cost model. While such facilities have been developing for many years, today’s ability to rapidly assemble and disassemble sophisticated, scalable, and customized information technology resources in an increasingly self-service manner, without any fixed, capital investment is unprecedented, and is having an escalating and increasingly disruptive impact on the way that businesses are designed, deployed and managed.
We also think that the roots of the cloud are in the consumerization of information technology and the emergence of public infrastructure.
How do you define orchestration?
We think of the cloud as being the SPI stack (Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service ) with Business-Process-as-a-Service on top (see Figure 2). These are all ways of delivering IT services. All of these delivery mechanisms share a common need for governance, management, security and identity. We draw a band around the 4 layers of the stack and call it ‘orchestration’.
We expect that orchestration will evolve to providing alternative sources for the layers as a way of increasing the overall robustness of the system.
What do we do for governance in the cloud?
Today, most organizations have a heavyweight process for CAPEX governance. This process is typically owned by the corporate controller whose job it is to say No, or at least to make it take a long time. In contrast, there is often little in the way of governance for OPEX.
What we need is lightweight governance that encourages innovation but has some measure of accountability. At a minimum we need to know how much is being spent, and for what purpose. This information then needs to be shared with others in the firm so that ideas and experiences can be leveraged.
There is also a tactical reason for governance in the cloud that has to do with making it easier to do something the right way rather than any other way. Today it is easy to spin up virtual machines in the cloud and to make mistakes – such as setting the wrong firewall rules. We need orchestration software to keep track of virtual machine instances and ensure that firewalls are set properly. We also need to make sure that the virtual machine instances are composed from trusted sources.
We need orchestration. However, it must be lightweight and demonstrably easier, better, and faster to use than any other way.
Why does IT insist on governance? Is it needed in the cloud?
As discussed on page 17 in the section Putting the cloud into a management framework, IT tends to focus too much on Operational Efficiency. This translates into a concern for cost, regulatory compliance and the appropriate handling of data.
As long as the audit committee of the board sees fit to hold IT responsible for any data breach, then IT will continue to insist on governance that locks down what other employees may do. If employees are responsible for their own behaviour, IT may be willing to change.
Can governance in the cloud make use of social software?
The short answer is that we don't know, but we think so. By providing systems that make it easy to tag and share what you are doing, we think we can begin to build communities that will help each other and act as a social mechanism to encourage productive behaviour.
As we have seen with PCs and the Internet, peer pressure and peer recognition are powerful forces, as is providing recognition for a job well done. Treating people as adults and providing a mechanism for them to share can go a long way towards taking full advantage of the cloud.
How do we make easier, cheaper, and faster to do it the right way than any other way?
In the stack diagram in Figure 2 on page 6 there is a layer that wraps around all the layers of the cloud stack. This layer is called orchestration. There are a variety of functions that need to be performed by orchestration including security, identity management and governance. If done right, these functions should make it easier, cheaper and faster to do it the right way rather than any other.
For example, rather than have individuals set firewall rules for their virtual machines in the cloud, we should have software that does it for them, according to our enterprise needs. We also need some notification that servers have been started and that money is being spent. Products such as Rightscale are available to perform a number of those functions.
Critical capabilities (such as governance and resource allocation/management) still need to be created for this new environment. Such governance needs to be lightweight and fast. Employees should be encouraged to make use of new cloud capabilities – with its low price, you can even think of it as training.
However, the freedom to innovate comes with an obligation to let others know what you are trying to do and what you have learned. We see a real opportunity for micro-blogging and tagging to be a part of the formal governance process. If your orchestration layer looks and feels like a Web 2.0 app, you are probably headed in the right direction.
What are the cost savings in moving to the cloud?
As we have said before, the most important value the cloud brings is not lower costs but improved agility and business effectiveness. Therefore we recommend that you focus, initially, on doing new things that your current environment cannot support rather than on cutting costs.
But the answer to this question depends on the answers to two more: what does it cost in the cloud, and what does it cost us today?
The cost of computing in the cloud has a number of components including the costs of processing, storage and communications. Savings in these direct costs are easily captured by the short billing intervals. The important thing in the cloud is to make sure that you invoke resources only when you need them and only in the quantity that you need. A little trickier to measure is the impact on the cost of managing systems. Especially for those who don't have extensive VMware experience, the move to the cloud can ease time-consuming tasks. For example, replacing a dead server, even if the vendor gives you a new one for free, can take a long time. In the cloud it can be done in minutes. There is also the cost of getting your staff up to speed on using these new tools. You may want to talk to your HR department about training budget that may be used for cloud projects.
Answering the second question requires Activity Based Costing (see http://en.wikipedia.org/wiki/Activity_based_costing .) The problem is that buying, installing and maintaining servers requires services from all over the organization. There is a classic example of a window manufacturer with a special ultra-expensive line of windows that were customized for each sale. The assumption was that since they were so expensive they must be profitable, but when the cost of all the extra administrative work was identified, they were found to be no more profitable than regular windows. One of our subscribers estimated that it could cost as much as $100,000 to approve, procure, plan and install a server – above and beyond the direct purchase price.
Why does it matter how things are billed?
Key advantages of the cloud include the ability to pay just for what we use and to switch suppliers whenever we choose. If one vendor has a problem we want to be able to move either temporarily or permanently to another source. The shorter the billing interval, the easier it is to switch from one supplier to another.
Why should we be worried about switching to OPEX?
We don’t really have good lightweight governance for OPEX. We need it to be lightweight so that it doesn’t create the heavy bureaucracy and ‘learned helplessness’ of our CAPEX processes. These new cloud services are inexpensive and available on-demand; our processes need to be the same way. We need to make it easier and faster to do it the right way than any other way.
There is resource allocation involved, even if it is small amounts, so there needs to be some kind of tracking. However, why not consider initial use to be training and simply give those interested $100 Visa debit cards?
Of more concern is the sharing of lessons learned. Instead of heavyweight activity reports, consider requesting employees to micro-blog and tag their efforts. That way others can share in what they have learned and know who to contact for more information.
How do we deal with licensing issues?
Licensing can be an issue, but it is one that we expect to evolve in the near term as more and more suppliers see that it is in their interest to make it easy for customers to use their products in the cloud. For example, IBM now makes a variety of software such as DB2, Informix and Tivoli available on Amazon’s EC2. These products may be used either with licenses you already own, or by paying a surcharge on top of regular EC2 prices.
How much security is enough?
This question has to be answered in the context of specific data – you have to decide what is appropriate for each group of data.
Historically we have not made very fine distinctions between data elements, preferring to treat everything the same way. This one-size-fits-all approach would mean that we would have to treat all data in the cloud the same as the most sensitive element.
To take advantage of public clouds we need to make some distinctions. Consider a contract that has many pages of boilerplate and a relatively small amount of sensitive information. We may decompose the data in the contract such that the sensitive part is held locally, perhaps in the country of origin, whereas the non-sensitive part is held in a public cloud.
We do expect public clouds to get more secure over time. Several firms are now deploying private clouds today with the expectation that they will become hybrid public/private clouds over time.
For a good check list see the Security Guidance document from the Cloud Security Alliance: http://www.cloudsecurityalliance.org/
How do we decide what data may live in the cloud?
It depends on the kind of data it is and the regulatory requirements that apply to it. We need a much more fine-grained approach to data. One size does not fit all.
We recommend you to review your data portfolio. This is a new area and requires some thought. You need to decompose data into ‘chunks’ that have shared requirements. You need to find ‘chunks’ of the right level of granularity, and make decisions and policies about the appropriate treatment for each ‘chunk’.
Then ask the question what will happen if this chunk of data is breached? A related question is what will happen if this chunk is corrupted or altered? Will I go to jail? Will I lose my job? Will it make no difference?
This treatment has to be matched with the capabilities of the cloud as they evolve over time. Consequently this is something that we will need to review periodically.
Where can I find good guidance about security issues in the cloud?
A good place to start is the Cloud Security Alliance "Security Guidance for Critical Areas of Focus in Cloud Computing". http://cloudsecurityalliance.org/csaguide.pdf
What is the sequence or roadmap of moving to the cloud?
We think that the first uses of the cloud will be for development and testing using non-sensitive data. Closely following that will be the use of the cloud for data analysis. In some firms the marketing department may reach the cloud first (see question ‘Will marketing get to the cloud before IT?’ below). The next major step will be when organizations have developed enough confidence to use the cloud for disaster recovery. Cheap disk storage in the cloud (or clouds) means that data and systems can be pre-positioned.
Once organizations are comfortable with disaster recovery in the cloud, we expect to see a move to run production in the cloud and increasingly use the local data centre for disaster recovery and the storage of the most sensitive data.
How do we review our app portfolio?
The best way we know of is to make use of the portfolio review process described earlier in this workbook.
How do we choose what level in the cloud is appropriate?
Take a look at Figure 2, the cloud stack, and review the text on page 7. Use moving to the cloud as an opportunity to free up management attention by pushing non-core activities up the stack. At the same time, moving to the cloud gives you the opportunity to differentiate your core activities by moving them down the stack to benefit from the greater flexibility there.
Be careful not to confuse core with mission critical. There are activities that are mission critical, but which may not be core. By ‘core’ we mean those activities that cause customers to buy from you instead of someone else.
How does the way you provide fail-over change as you go up the stack?
At the infrastructure level, fail-over means switching to another cloud. That second cloud could be another zone from your current provider (as in Amazon’s Availability zones) or it could mean switching to another provider, preferably one that makes use of the same APIs. As you move up the stack and become more application-specific, it becomes harder to switch providers. For example, ETS will make use of Microsoft’s BPOS in a multi-tenant environment. Part of the deal is that there is a parallel ‘hot’ server on the other side of the country that can pick up the load if the machine you are using has trouble.
For a new application the cloud is often a no-brainer, but what are the barriers for existing applications?
Not all enterprise applications are appropriate for the cloud at present. It depends on the data they use. However, most IT organizations do not have a clear view of the different requirements of their data because historically they have treated it all the same.
So, one of the biggest barriers for existing businesses is deciding how each major chunk of data should be treated and acting accordingly (see ‘How do we decide what data may live in the cloud?’). This will require consultation with legal and regulatory staff to ensure proper treatment. Over time we expect regulations to evolve. For example, today regulations such as the credit card PCI-DSS regulations require physical inspection of servers; when virtualized, this may not be possible.
How do we deal with legacy programs?
Some legacy programs are single-threaded, mainframe applications – the opposite of the horizontally scaleable, so-called “shared nothing” approach of big cloud applications.
The first question to ask is can this program be replaced with something further up the stack? If not, how hard will it be to parallelize it? In many cases, it might be easier to replace it. New tools and platforms can dramatically change the length of time needed to develop new applications. For example, look at Force.com and what Japan Post has been able to do1. It is essentially leapfrogging over the ERP era.
How do we migrate applications from the mainframe?
We know of cases where MicroFocus COBOL was used migrate mainframe applications to the cloud. One app that was known to be a resource hog on the mainframe actually ran faster on an 8-core box in the cloud.
The harder problem occurs when we want to take advantage of the elasticity of the cloud. This often requires that applications be re-written in the expectation that they are segmented so that multiple threads can execute concurrently. But the potential savings or gains in agility may not be worth the trouble.
In each technology transition some applications have stayed behind. That’s why they are called legacy. Similarly, in each transition, it is new applications that typically are the real driving forces of change.
How many clouds are enough? We know that we want more than just one, but how many are enough?
The question of how many clouds are enough depends on the time criticality of the data you are looking to put in the cloud. If you can afford to be without the data for a day, it is likely that one cloud is enough. The trick will be to categorize your data so that you know how time-critical different chunks of data are and can create configurations that are appropriate for each.
Historically we had a single vendor because it was so expensive to have more than one. Now the buyer can have control over reliability by having multiple clouds. Since the cost of cloud storage is low, it is possible to pre-position data in multiple clouds. Using VPN overlay technology (such as CohesiveFT’s VPN-Cubed) you can create systems that automatically fail-over if one cloud has troubles. As cloud vendors get larger they will have multiple availability zones that will provide some degree of fail-over within a single vendor.
Can we use the cloud to handle peak loads?
Data centres in many enterprises run at only 10 percent utilization. This is usually because each application was installed with the extra capacity needed for it to run at its peak, independent of any other application, and the hardware procured was planned to handle multiple years’ growth. The cloud makes it possible to look at exchanging that local ‘safety stock’ for capacity on demand in the cloud.
There are two approaches. One is to shift work running in the data centre to the cloud to free up resources in the data centre. The other is ‘cloudbursting’ – procuring additional servers dynamically, as needed, in the cloud. The low cost of storage in the cloud makes it relatively cheap to pre-position systems in the cloud, to be started as needed.
But cloudbursting requires that applications be designed for horizontal scaling. Only a fraction of our portfolio is designed this way today, but this will change over time, following the evolution of processor architecture from faster single processors to multi-core machines.
When will we be able to use the cloud for production?
For some applications, the cloud is production-ready now. The cloud is being used for websites and test processing today. However, none of these applications is particularly sensitive in terms of personally identifiable data or time.
What will my data centre look like if production is in the cloud?
We expect that, ultimately, production will be in the cloud and the local data centre will have two roles: 1) disaster recovery and 2) keeping the most sensitive data. There will always be a need for some internal capacity. Our expectation is that the local data centre will shrink – it may become a Cisco UCS box under the CFO's desk – but it will not go away. The CIO still has to be able to answer in the affirmative if the CEO asks, "If the Internet goes dark, can we still send out bills?"
What are the things that I do today that will become critical in the cloud?
Today security is largely the responsibility of dedicated IT security staff who operate, monitor and create policies. In the cloud responsibility becomes shared with staff who are increasingly IT literate. Today, we treat users as children. As we move to the cloud we need them to behave as adults.
We will need to be clear about what our expectations of employees are. In our work on consumerization we have discussed how some firms have developed a 2-page ‘Big Rules’ document that makes explicit what is expected. (See pages 26-27 of the LEF report Global Business Collaboration: Where culture, technology, and innovation meet.)
With those expectations in place we will need to ramp up the training we provide to employees. We do some today. We need to do a lot more in future as we switch from doing things to or for employees and starting doing things with them.
Will Marketing get to the cloud before IT?
Marketing departments are increasingly becoming examples of ‘double deep’ employees: ones who know about both their specific business requirements and the relevant information technology. Now that servers can be purchased with a $25 Visa debit card, the IT organization is no longer the exclusive owner of the means of production. IT departments would be well advised to have conversations with their marketing departments to understand what needs they have that might well be suited to the cloud.
How do we organize to take effective advantage of the cloud?
It helps to start by realizing that the biggest enemy to effective use of the cloud may well be ourselves. Many firms outsourced years ago and no longer do many of the day-to-day activities that systems require. When moving to the cloud, the outsourcer is not always part of the process. What this means is that the internal IT organization has to pick up the work. The problem is that this work is typically not the official job of anyone in the retained IT organization. As a consequence there may be no-one specifically tasked with the various responsibilities.
The key is to examine the work that needs to be done and make sure it is someone’s explicit job, either internally or from your outsourcer. If it is just another task layered on top of a busy list of things for someone to do, it will not get done effectively and the advantage of the cloud may not be gained.
What new jobs does IT have in the cloud?
Cloud computing has arrived at the same time that the consumerization of IT has produced double-deep employees: those that know the business and are increasingly smart about the technologies. These employees are a growing source of economic value. IT needs to accelerate this trend. So, IT has a series of new jobs related to teaching, end-user architecture, and end-user platform deployment. A good example is the provision of virtual machines already configured with applications that double-deep employees can deploy and run with just a few clicks. Another is finding ways to include double-deep employees in taking increasing responsibility for the organization’s security. The hardest part for IT will be learning ways to share decision rights appropriately and treat end-users as peers.
As a government agency we will be forced into multiple cloud vendor relationships – how do we operate a multi-cloud?
Over the last year there has been a great deal of discussion about cloud standards and interoperability. However, the cloud is still developing. We are not yet at a stage where we can have an inter-cloud of easily interoperable clouds from different vendors. In the short run the best that we have is API compatibility where the interface to the customer is consistent, but how that service is created is left up to the vendor. In the near term the most widespread APIs are the Amazon APIs. Several companies (such as Eucalyptus) now support and are interoperable with the Amazon API. In the US, NASA Ames has developed a system called Nebula based on the open source code of Eucalyptus. Vivek Kundra, the US Federal CIO, has suggested that the cloud should be the basis for much of US Federal computing, and launched Apps.gov to help federal agencies to browse and purchase cloud-based IT services.
The other competitor for becoming the standard API is VMware with its vCenter and recent vCloud Express offering. The combined buying power of the US, UK, Canadian and Japanese governments is starting to have an impact on the degree to which providers are willing to become interoperable.
What is the impact of governments on how quickly the cloud evolves to meet enterprise requirements?
The cloud has evolved out of the consumerization of information technologies. A key part of this evolution is that information technologies are delivered cheaply, on demand and at massive scale, to consumers. For example, Yahoo has more than a quarter of a billion e-mail accounts. The problem for large enterprises is that they often have – or believe they have – requirements that are not met by consumerized technology providers.
In comparison with the consumer market, big enterprises are just a niche market. This is why consumerized technology providers have been slow to address the needs of big enterprises and unwilling to negotiate separate contracts.
Governments are now playing an important role in this market. The recent economic crisis has forced governments to look for new ways to operate. This has made them more open to consumerized technologies, and the government market is big enough to attract the attention of cloud companies such as Google and Amazon. This is starting to change the behaviour of consumerized technology vendors in ways that will help meet big enterprise requirements.
1We heard about Japan Post on the 2009 Study Tour – see the forthcoming Study Tour Report.