Fundamentals Of Cloud Computing: Webcast Series - Questions and Answers - Is cloud software or hardware
The answer to this question is really a matter of perspective. If you are looking at this from a "cloud consumer" perspective, then cloud is a service. There is a little bit of software in the form of, say, a web browser, mobile application or other lightweight software client that is used to access the services, though. It is also entirely possible to use virtual desktops for applications running in a cloud. If you are looking at this from a "cloud provider" perspective, then the answer is, "Yes. There is a whole lot of hardware and software involved." This will range everywhere from the physical infrastructure (i.e. servers, storage, network equipment, and other appliances) to the virtualization and/or multi-tenant applications, to the actual software that makes the cloud service "cloudy"… like resource pooling, metering, portals for provisioning the service, and all of the operational tools needed to run the IT infrastructure.
- Do you have to have virtualization in place to migrate to a cloud based offerings
No, you do not need to have virtualization in place to leverage cloud based offerings. Unless, of course, you are planning on building your own private cloud, in which case virtualization is a key ingredient of your private cloud platform. Virtualization is an enabling technology for cloud, but virtualization is not a cloud. If one were to consider moving some existing IT services out to something like an Infrastructure as a Service (IaaS) platform, having the skills and knowledge attained by having in-house experience with virtualization will certainly be a benefit. However, this is not a requirement to use IaaS or any other cloud service. Many customers have already moved existing services like email, collaboration, web content delivery, CRM and the like to Software as a Service (SaaS) providers. In addition, many customers have moved both legacy applications as well as new applications to cloud based service providers.
- I've heard a lot about cloud standards recently from NIST's forum. Will providers be compliant with these emerging standards
This reminds me of an old adage within the IT world. "The one thing I love about standards is that there are so many to choose from." All joking aside, NIST has done a good job of pulling together both existing Internet standards as well as some emerging cloud based standards. It is still early days in terms of cloud standards, but there are some nice ones taking shape (Open Virtualization Format (OVF), Cloud Data Management Interface (CDMI), and Open Cloud Computing Interface (OCCI) to name a few). But it is still early days, and adoption by vendors and cloud providers is going to vary greatly. We're starting to see vendors start to adopt standards like the OVF and the Security Content Automation Protocol (SCAP), and in the short term, some enterprising companies will adopt these standards as a competitive differentiator. This may seem like an oxymoron, but those vendors who are early adopters will actually have an advantage over their competitors who are sticking to their own proprietary methods. Adopters will be proponents of portability, interoperability, and secure-ability. Over the mid- to long-term, we'll see more vendors jump on the standards bandwagon, and some large vendors will wait until the last minute before they adopt, so as not to bet on a losing standard.
- We're currently looking at hosted email solutions with applications in the cloud. What are some things I should be thinking about for this sort of move
Risk is certainly top of mind, but most IT shops and Chief Information Security Officers (CISO) have a good handle on their compliance, governance, and security requirements. At the end of the day, it will take rolling up the sleeves to see what cloud providers can and cannot deliver. (We'll talk more about security and cloud in upcoming webcasts and blogs.) However, many other critical topics are often foreshadowed by the risk conversation. Other areas to keep in mind when migrating services to the cloud… or any other new platform for that matter include: - Skills - This includes both IT skills as well as end users. There will be new tools, policies, processes, and technology for the IT staff to learn. On the flipside, the end users may have a different experience in terms of user interface and functionality. All will need training on the new platform.
- Incident/Problem Management - Before going live, be sure that both IT and users have a clear understanding of how they submit incidents. IT will also need to have an equally clear understanding of how to interact with the cloud provider. Does the cloud provider actually have live people available to answer the phone in the event of a critical incident? What sorts of response times are expected? What level of detail will be provided in terms of root cause? What are the escalation procedures? Do they have a special hotline for security specific incidents?
- New Disciplines - Cloud technologies are bringing to the forefront some IT disciplines that have not necessarily been priorities in the past. Disciplines like Service Level Management and Capacity Management are two that come immediately to mind. It will be key for IT to be able to understand Service Level Agreements. It may also be necessary to invest in new tools in order to monitor against those SLA's, as you may not be comfortable to with assuming that the provider will be monitoring it for you. Capacity Management is another area where it will greatly benefit cloud consumers to increase their skills and tooling. When you are paying by the drink/gigabyte/CPU, it will be key to know how much resource is being consumed and how much is expected to be consumed in the future, as unexpected variance may wreak havoc on budgets.
- ulture - Change acceptance is a challenge for most organizations, and changing to cloud based services may be received with fear by some IT folks. This needn't be the case, though, as I have yet to run into an IT shop that has too many people with too little work. The reality is that most IT shops are understaffed with too many projects falling behind schedule. One big benefit of moving some services to the cloud is that it can free up IT staff to focus on higher value projects and opportunities… as well as learning new skills like performance analysis and capacity planning.
- Communicate - And Communicate some more. Rolling out any new service (and for some strange reason, it seems even more relevant to cloud services), requires communication with management, end users, and IT. I've yet to see any rollout where people complained about over-communication. Also, don't limit the communication to the good news. Keep everyone abreast of what is working, what the challenges are, and what is not working. Keep everyone on the same page, and solicit their input for solutions to any challenges.
- For the sake of brevity, I'll stop here, but these are the top of mind topics of many of the IT folks with whom I've worked. Expect more on this topic in the future.
- You've mentioned IaaS, PaaS, and SaaS. What about all of these other "as a Service" offerings out there
There is certainly a proliferation of "Things as a Service" (TaaS) out there. However, if you peel back the layers and look at it from an a) targeted consumer perspective and b) completeness of business value perspective, you can typically figure out where in the IaaS, PaaS, and SaaS trifecta the service actually resides. For the time being (and for the sake of simplicity), I'll keep the services in these three buckets, though I expect that in the not so distant future, marketing folks will chafe at these restraints, so expect a proliferation of creative new TaaS.
- What are some recommendations for complying with OMB CIO Vivek Kundra's mandate? What sorts of IT services can I look at for moving into the cloud
Cloud isn't all that new to the Federal Government, and a number of agencies were already either using or evaluating the use of cloud technologies even before the mandate. This adoption has ranged from the development of private clouds within different agencies, with DISA's RACE and NASA's Nebula being two examples, to the adoption of public cloud offerings for IT services like web content delivery, content delivery networks, rich media delivery, email, collaboration, and CRM. So, where to start? First, I'd recommend looking at the edge services? Is there information that is specifically for the public's consumption? This is an easy start, as the odds are good that the FISMA or DOD security requirements are going to be low. We've also seen SaaS providers starting to achieve FISMA moderate level certification which may be suitable for some agencies' email and collaboration environments. Finally, it may be worth considering private cloud projects. Having a small cloud running within the IT department for prototyping a small set of services can be invaluable not only from a service delivery perspective, but also from a up-skilling perspective for the IT folks.
- Does any direction exist for things like data sharing agreements, discovery, and private cloud regulatory standards for data interchange, data in place, and other privacy issues
There is quite a bit of good direction shaping up that can be leveraged for the design of a private cloud, and the National Institute of Standards and Technology (NIST) has been doing a good job of compiling the list of relevant standards and definitions. Of particular interest to this question are the Open Cloud Computing Interface (OCCI), Service Provisioning Markup Language (SPML), eXtensible Access Control Markup Language (XACML), and Open Authorization Protocol (OAuth). Of course, FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, FIPS 199: Standards for Security Categorization of Federal Information and Information Systems, FIPS 201: Personal Identity Verification of Federal Employees and Contractors, and Secure Content Automation Protocol (SCAP). In addition to these standards, NIST’s other Guidelines and Recommendations like 800-53: Recommended Security Controls for Federal Information Systems and Organizations, 800-125: Guide to Security for Full Virtualization Technologies, and 800-146: DRAFT Cloud Computing Synopsis and Recommendations all provide additional resource material that can be useful in designing a private cloud. The downside is that this is a very dynamic time to be in Information Technology. Wide adoption of standards, open Application Programming Interfaces, and security controls are sorely lacking. However, if you are looking to design a private cloud, then all of the existing controls, standards, and requirements that already exist within your IT infrastructure still apply.
- Is the usual practice for cloud providers to provision all three service models (Saas, Paas, IaaS), and can these be decoupled? Does a business need to consider all of these in lockstep
Not necessarily. As consumers of public cloud services, you do not need to consume all three (3) service models from cloud providers. For example, if you are using something like Google Apps which provides email and collaboration SaaS, you do not need to also use their Google App Engine (PaaS) offering, and vice versa. (Google doesn’t provide an IaaS offering.) Granted, there may be some additional functionality and integration were you to leverage both from the same provider, but this is not always so. One other item to be wary of, though, is cloud services that rely on some other cloud service. One good example is BMC Software’s Remedyforce which is a SaaS service desk offering. Remedyforce is built atop Salesforce’s Force.com PaaS. There is nothing wrong with this model, and I only bring it up here because it’s important to understand for security, risk, and compliance activities.
- Capabilities like data cleansing, replication, stand-by synchronization, et cetera, have been around for a long time. So, what’s different with the cloud
Very true. All of these features have been available on premise in our data center for a long time. However, we may not be using it regularly (or have variable workloads) which means that the software and hardware, including support, licensing, power, cooling, floorspace, and other CapEx/OpEx costs are being paid, whether we are utilizing it at 10% or 90%. Rather than hosting this on premise, we can now leverage this same sort of data integration functionality without needing to pay the upfront costs of acquiring and integrating the systems. This also has the added benefit of freeing up constrained IT resources (i.e. people!) to do more mission critical work. In some cases, this may prove much more cost beneficial. (Note: Informatica also offers a hybrid platform which has both a cloud and on premise component. This would be appropriate when there are data sets residing both internally and in the cloud that need integration.)
- I’m still not quite clear on Software as a Service (SaaS). Can you relate this to something like the presentation layer by end users versus business logic... is it both
First, let’s start with a simplified model of how we traditionally deliver services within IT. This is often referred to as the three (3) tier architecture. These three tiers are: - Persistence Tier – the database
- Application Tier – the business logic and middleware applications
- Presentation Tier – the web server or presentation application that provides the user interface
For this example, we’ll say that the client application that connects to the Presentation Tier is a web browser. SaaS providers are responsible for all three of these tiers and provide the entire experience as a pre-integrated, managed, and maintained service to the business users via a web browser of other client application. In most cases, we (the consumers) are not able to dramatically change any of these three tiers, as it is a multi-tenant service. However, the SaaS provider may allow us to change some things in these tiers, like possibly adding some columns to a database table, or adding additional business logic or workflows, and, perhaps, some of the look and feel of the web interface. Keep in mind though, that the key to efficiency from a SaaS provider is standardization, and this efficiency translates to lower costs as the consumers of their services. We’re still responsible for our web browsers, though. So always keep your browser up to date, and don’t load plug-ins that you don’t trust!
- Is there a private cloud that is not customized
Yes...and no. In the Federal Government, NIST has done a great job defining the attributes of a cloud, and fortunately, most folks in the industry have adopted this definition. This makes it easier for all of us to define and agree on what a cloud is. Now, how one actually builds a private cloud is a whole different story. On the one hand, it depends on where you start. Is it a greenfield, built-from-scratch private cloud, or are you leveraging an existing virtualized infrastructure on which you want to layer additional cloud functionality? Are you going to leverage open source or commercial products? To which APIs would you like to be able to interoperate? Are you looking to build an IaaS, PaaS, or SaaS private cloud? There is a lot of variability in how you can actually build your cloud, so to that point, they are all customized. So, the key functionality that is needed to be called a cloud is pretty well defined, how you actually choose to implement that functionality is a matter of choice, skills, and requirements.
- How do you build virtual machines / Amazon Machine Images so they can automatically provision to something like Amazon EC2
There are a couple of ways in which you can create your own Amazon Machine Images (AMI) for use in Amazon’s Elactic Compute Cloud (EC2). The first is to modify an existing AMI from Amazon’s library of images. You have the choice of creating AMIs for either Elastic Block Storage (EBS) or Simple Shared Storage (S3) deployment. Note that the same image will not deploy to both of these storage options. Simply load the existing AMI into an instance, modify it, and when you have a running instance that you are satisfied with, save the image as either a private or public AMI. The other method is for environments that are already running VMware and want to upload a VMware virtual machine to EC2. Amazon provides both a command line method and a plug-in for VMware vSphere that enables you to import a virtual machine image. There are some limitations to this capability, so be sure to check out the latest Amazon Elastic Compute Cloud User Guide.
- What about outages from public IaaS cloud providers? How do we plan for and handle these interruptions
It’s important to remember that IaaS providers deliver power, pipe, ping, and virtual machines. As such, we need to treat our IaaS hosted assets as an extension of our own physical data center. The IaaS providers are responsible for the physical facilities, the physical infrastructure (servers, network, storage, et cetera), and the virtualization that abstracts those physical infrastructure components into virtual compute resources that we can consume. The actual care, feeding, and security of IT services residing in the cloud are our responsibility. We still need to backup, monitor, maintain, patch, update, and secure our virtual computing platforms and applications. We also need to make sure that our virtual assets and the services running on them are also incorporated into our disaster recovery plans, processes, and procedures. In short, nearly all of the disciplines that we have been honing in datacenters for the past 50 years are equally relevant in the cloud.
- What is the difference between "Virtual Private Clouds" and "regular" cloud
Virtual private clouds (VPC) are some cloud providers’ response to customers’ needs for dedicated resources (think performance) or isolated resources (i.e. no multi-tenancy). These offerings often allow for the rapid provisioning of dedicated machines (note: we’re talking physical machines here, not virtual machines), with a private network, and usually with a virtual private network (VPN) encrypted connection. The tradeoff of VPC versus standard IaaS will be price. With VPC, you are paying for whole systems, regardless of utilization, as you have reserved the whole machine. Elasticity of resources may also be more challenging, depending on the provider. The upside is that rapid provisioning, metered service, and network access are still part and parcel of VPC, making it a good compromise for some consumers. VPC may be a good alternative for groups who have more stringent governance, compliance, regulatory and security requirements. It may also serve as a nice option for “cloud bursting” (temporarily grabbing public cloud resources when a private cloud’s resources are exhausted).
- How do you integrate SaaS, PaaS, and IaaS? Where do the savings come from without losing the security
There are no simple answers for these questions. In terms of integration, we must rely on the APIs that the cloud providers publish. Fortunately, there are a number of developments that show a silver lining for cloud to cloud integration. The first development is the improvements in the APIs that cloud providers are exposing. The second is the creation of “translator” types of products and services that translate calls from one cloud provider’s API to another cloud provider’s API (think Red Hat’s Deltacloud and CloudForms). Finally, we are seeing SaaS providers who are designed specifically for transferring and synchronizing data between clouds (like Informatica Cloud). I expect we’ll see improvements in both the APIs and tools used to connect these APIs in the months and years to come. Now for the really hard question… “where do the savings come from without losing the security?” You will only be as strong (secure) as your weakest link. It’s key that we look closely at every link of our IT service supply chain. This will be costly, but I’m not convinced that it will cost any more than it is costing us internally now, anyway. The nice thing about cloud is that we get to leverage the cloud providers to help us meet some of our security requirements. For IaaS providers, this includes items like physical security, system firmware maintenance, and abstraction layer security (think hypervisor) for the compute resources. For PaaS providers, it adds the virtualization layer, operating system, and development environment. Finally, SaaS providers cover everything up and including the presentation layer. I’ve also find it encouraging that cloud providers are increasingly becoming more aware of and attaining certification in key areas. Keep an eye out for cloud providers who have passed SAS 70 type II audits, achieved ISO 27001 certification, achieved FISMA compliance, and PCI DSS to name a few. The list is growing. We’ll still need to “watch the watchers”, and this will cost time and money, but with some of the cloud providers picking up other areas of responsibility, it won’t cost quite as much.
- How can Designated Approving Authority approval be gained and maintained for cloud computing
The short answer for this question is to leverage auditors who have experience auditing cloud providers and understand multi-tenant architectures. Also, look for cloud providers who have experience gaining key certifications and compliance for government agencies. Existence of FISMA certifications, an existing Authority to Operate (ATO), ISO 27001, and SAS 70 Type II are all good indicators that the cloud provider has the knowledge and experience needed to successfully get through this process in a timely manner. I’m also hoping that improvements to continuous monitoring will help expedite the renewal of these ATOs once they are obtained. Let’s also not forget FedRAMP… with agency buy-in, FedRAMP would be revolutionary in how the Federal Government acquires IT services.
- How do I store Intellectual Property (IP) – namely healthcare related data – in a public cloud
In previous webcasts, we talked about what NIST defines as a community cloud. A community cloud is a cloud that caters to a specific community’s requirements. For example, we are starting to see cloud providers who are designed to support customers in the healthcare vertical. As such, these healthcare oriented cloud services are focuses on customer with HIPAA or HITECH Act requirements. One example is a company called FireHost (no affiliation with DLT Solutions) that specifically caters to customers with HIPAA and PCI requirements.
For HIPAA related cloud services, also look for cloud providers who are business associate friendly. Being business associate friendly means that the cloud provider is willing to sign up as a business partner to the healthcare customer and will accept additional risk and responsibility.
Other more general purpose cloud providers like Amazon have also been publishing white papers explaining how to build HIPAA compliant cloud services on their platforms. It is important to read these papers and understand the architectures they are describing. Additionally, be sure to get the Chief Information Security Officer and Legal team involved to review the Service Level Agreements and further evaluate any risks.
Finally, the Cloud Security Alliance has a wonderful tool called the cloud control matrix. In this matrix, they have mapped 100 control areas related to cloud architecture to various regulatory compliance requirements including HIPAA and the HITECH Act as well as NIST, FedRAMP, and others. This is a nice tool to have at hand when evaluating cloud providers and their compliance to specific requirements.
- How do you validate security settings for secure cloud computing
First, don’t forget everything we have learned in the past. Start by evaluating how you are currently validating security settings today. Look at how you are auditing existing systems as well as how changes are currently being tracked. In many cases, the processes and tools currently in place can be leveraged with slight modification to a cloud service.
Fortunately, this is not a completely new problem that needs to be addressed. The trick is that our existing perimeter of trust will need to be extended. This is not to say that we should trust blindly, rather we should trust but verify. This means that we may need to change our audit methods or tools slightly to account for the areas that are now out of our direct control or visibility. We may also want to consider leveraging auditors who understand cloud service models and multi-tenant environments.
When using PaaS or SaaS, things may be a little trickier, and it will require more trust in the provider. (Again, trust, but verify.) The reason for this is that we have even less control and visibility over the platform itself. We only have access to the service either at the application level (PaaS) or at the actual user service level (SaaS).
With IaaS we control deeper into the stack down to the operating system level, and the cloud provider handles the hardware platform, hypervisor, and cloud infrastructure. Thus, it is a little easier to leverage our existing tools and processes with IaaS services by treating them as a direct extension of our existing data centers.
|
