Module 5 Part 2

Welcome to part two of the Introduction to Cloud Computing lecture. In this segment, we are going to talk about cloud infrastructure as well as cloud environments. We will look at some of the motivations that company use to get into the cloud. We will finally look at strategy for cloud adoption, as well as processes for IT infrastructure, migrating software applications and even the entire IT landscape to a cloud environment. In this segment, we are going to talk about cloud infrastructure and cloud environments. Cloud infrastructure looks at how do you actually build up the infrastructure for a cloud using computer hardware as well as networks. In addition, of course, to all the software that is required to create the abstraction layer. In addition to this, we look at a Cloud environment, which is actually the Cloud infrastructure, in addition to all of the tenants, as well as the customers that are utilizing the cloud. Now, enabling all of this is a Cloud infrastructure. The cloud infrastructure is the collection of hardware and software that enables these five essential characteristics of cloud computing. When we think about the cloud infrastructure, we can view that as having both a physical layer as well as an abstraction layer. The physical layer consists of all of our hardware resources and typically includes server storage and network. And the abstraction layer consists of the software that we're going to deploy across the physical layer. This manifests itself, rather, this manifests the five essential cloud characteristics. We take computer hardware and we deploy a software layer called the Cloud Abstraction Layer, which then creates the five essential characteristics of cloud computing that we just discussed. Now in previous lectures, we have talked about how virtualization is one of the building blocks of cloud computing. Cloud infrastructure is typically made up of a virtualized infrastructure where the servers are virtualized, the storage is virtualized, and then on that virtualized system we have virtual machines. The infrastructure as in the virtualized pool of servers, the virtualized pool of storage are connected together through a network. That network essentially allows the infrastructure to work as a single large warehouse scale computer. On top of that, we build virtual machines. These virtual machines um be different, or they can be exactly the same depending on what type of cloud infrastructure is being provisioned. Now, a cloud environment is a very dynamic environment where you would have clients that are initiating access. You would have clients that are leaving. You might have old hardware being brought out, being retired, hardware being taken out for maintenance. You might have new hardware being brought in to add to the resource pool. Collectively, the cloud provider almost looks like a vibrant ecosystem where the computing resources, the underlying hardware resources rapidly changing based on need. Also the user body, if you will. The consumers on the network are dynamically consuming resources as they need them and releasing them when the need goes down. They're also provisioning service on the cloud. There could be decommissioning service on the cloud. It's a very dynamic ecosystem and the key here is that from a client perspective, their interaction with the cloud provider, for the most part, is done in a self service fashion. Let's take a look at the similarities between traditional IT and the cloud using Amazon AWS product product portfolio, if you will. As an example, I'm going to walk you through this diagram from the bottom up. At the lowest layer, we have the storage and databases. Right on the left you have traditional IT, where we might have direct attached storage, that is storage that is directly connected to servers, storage area networks, which is a network of storage devices, network attached storage, where you connect storage devices directly to a network. And then you have the relational databases, as well as other types of databases. When you look at a set up on the Amazon AWS cloud, Amazon offers different types of storage capabilities in the cloud which would behave differently, similar to the way we have different types of storage in a traditional IT. In addition to that, Amazon provides different types of relational database systems where you can provision database management systems in the cloud, moving a level up for compute. In a traditional IT landscape, we have on premises servers, right? We have a number of physical servers that provide the compute capabilities, while in the case of AWS and the Cloud, we have Amazon's AMI which provides the raw compute capability. Or you can create Amazon C two instances, which would be more similar to virtual machines in the cloud. When it comes to networking in a traditional IT data sender or in a traditional IT landscape, we have routers that connect networks together. We have network pipe lines which connect all the different networks and the devices together. And of course, then we have the switch, which is used to move traffic between the devices or switch traffic between devices or a network when you move into the cloud, we have things like elastic load balancing, which is basically a smart virtual network device which will allow you to load balance across multiple compute storage instances. Or you can have an Amazon Virtual Private Cloud where you can actually create a virtual network using cloud capabilities to make it appear as though that cloud is dedicated for the use of the enterprise, although in reality it is still sharing a underlying infrastructure with other tenants or with other customers. And finally, at the security layer, in a traditional IT landscape on premises, we have firewalls, we have access control list, You might have a number of users or rather administrators that manage your security functionality within the Cloud. Actually, this is where it's somewhat similar in that in administrators you might have security groups which are groups of individuals that have the capabilities to do privileged actions on you are cloud instances, you might have network access control list, you might have a comprehensive ID and access management system. Let's now look at building a very simple database for an application, right? To relate this back into what we learned in our application architecture, we are really building the data layer as well as the attached data store for an application. Here we have a compute service which provides the computing capability, right? A virtual machine, if you will, right? We have an application running in that compute instance and this application needs storage. So the storage service in this example is Amazon's three, which is the simple storage where we are basically using it as a batch storage device, right? So these EC two servers will store data to the Amazon S three in batches. So they might take the transaction from the last hour and then store it in Amazon three. In addition to that, the application can use a live database. In this case a non relational database, such as Amazon's Dynamo DB, which will actually form the database engine for that application. Right here we have two types of storage. We have a database where the transactions are written as they happen, and then we have a bad storage device, which basically becomes a copy of the data to provide redundancy and back up. In addition to this, we can use a virtual private cloud, which is essentially a networking service which allows you to take these services that you are provisioned in the AWS cloud and put them into a virtual network such that these devices are believe, if you will. That they are on the same network, although in reality they are not. You are basically creating a virtual network which will allow your compute engine, the database engine, and the data store for backup, all to think that they are directly connected to each other in a local network. As organizations move into the cloud, that has a significant impact on the role of the IT organization within an enterprise. And that's what we are going to examine in this part of class. Now let's take a look at the day to day operations and management responsibilities of running the IT landscape. Comparing it to traditional IT, as well as the three different cloud service models. If you are looking at legacy IT, which is 100% on premises IT capabilities, the entire operational and management responsibilities which is the running of the IT itself, the hardware, the software, the networking storage, as well as a sender, is the responsibility of the cloud consumer when you move to infrastructure as a service, where we are provisioning virtualized capabilities in the cloud. Which means that the cloud consumer installs an operating system and then builds the software stack on top of it. That entire software stack that they build, which would include the operating systems, the databases, the security capabilities, and the applications, are all the responsibility of the consumer. While everything underneath that, which would be the virtualization, all the way to the data sender that hosts the servers, the storage, and the networking would be the responsibility of the cloud service provider. When you move to Platform as a service, if you recall, platform as a Service, the Cloud Consumer builds and deploys applications that are run on the underlying platform. The application that they built is the responsibility of the consumer. The platform and everything underneath, from an operations and management standpoint is the responsibility of the Cloud service provider. Finally, when you move to Software as a Service, where you are as a consumer using full featured software running in the Cloud, the complete operations and management responsibilities rest with the Cloud service provider. Now let's take a look at the division of responsibilities between the IT organization, the Consumers IT organization, and the service provider from a security standpoint. Again, a very similar scenario here, right? When you are running traditional enterprise IT or legacy IT, if you believe in a cloud first world, right? The customer or the customer's IT organization manages the entire IT stack all the way from applications down to the data center. When you look at infrastructure as a service, the customer is responsible for the security related to operating systems, for securing the databases, for actually implementing and managing security controls, as well as security capabilities like identity and access management. As well as looking at the applications themselves and making sure that they are secured. Right, So the customer basically is responsible the security of everything that they have built. A similar vein then, the customer build and deploy applications in the platform as a service model. Those applications that are built by the customer from a security standpoint are the responsibility for the customer. The customer has to actually take responsibility for the security of all the applications that they deploy on the platform, while the security of the platform itself is taken care of by the service provider. Finally, when you go to Software as a Service, the provider is responsible for all of the security related to the entire stack, which includes the hardware, the software, and the networking. Ultimately, every thing in our IT landscape or everything in the IT landscape, is going to be, from a security standpoint, the responsibility of the cloud service provider. In the hybrid cloud operating model, the IT organization becomes a provider as well as a broker, right? So the traditional IT group will exist, but they exist in a lesser capacity with most of the services being taken care of by an IT organization performing the role of provider and broker. They could be a provider if you're running in house private cloud. They would be more of a broker as you negotiate deals with public cloud providers or community cloud providers. And they are also responsible for stitching together the different models of cloud computing that you're going to be using. Let's take a look at the cloud market to understand the drivers. And then talk about how companies, how businesses can actually migrate to the cloud or the process that they can use to migrate to the cloud. When we look at cloud drivers now, the biggest driver would be that there is a possibility of significantly increased return on investment. And this comes from the pay as you go model, or the subscription model, right? Because you're moving from a capital expense to an operational expense, it is easier to come up with the money, right? So it's much lower upfront investment that could lead to a much faster payback. Now, moving things into the cloud, particularly if you're thinking about going into software as a service. You can very rapidly move into a cloud solution compared to actually implementing any solution similar to that in the data center. It provides you with much greater flexibility and scalability and allows companies to really focus on their core competencies than to get tied up with developing, deploying, and running applications, as well as managing and running multiple data centers. Now when you look at this from the standpoint of what are some of the concerns that businesses have in moving into the cloud. At the forefront of that is security control and compliance concerns from a security standpoint, as we have discussed in virtualization, and look at the challenges of a shared computing model. Since many cloud infrastructures are built on top of virtualization technology, it inherits all of the problems, all of the security vulnerabilities that are inherent in virtualization. The second challenge that you have is from a control and compliance standpoint, when you go into the cloud, you have very little control over anything other than exactly what you subscribe to. For example, if you are subscribing to software as a service, then you would have very limited admin level privileges within the software instance. And that would be basically limited to look and feel of changes. For example, if you had to look at our cloud implementation of Canvas versus that of another university, the single biggest thing you will notice is that branding and the colors, but the underlying system is almost exactly the same. The other huge challenge from a compliance standpoint is when your services into the cloud, that does not move the responsibility for compliance. You are allowing or you are getting somebody else to run your services for you while you would still retain all of the responsibility for compliance, and that is a significant cause of concern. Now moving into the cloud also means significant change. Now for the IT organization, this is going to lead to a requirement for a different skill set than what an organization might have in house if they are in that traditional computing model. Probably the single biggest thing to understand moving into the cloud, particularly software as a service, is that although you get full featured software in the cloud, you cannot change it. The software that you get is the software that every other company that has a tenant in that cloud is going to get. If there are some things in there that don't fit your business needs, your ability to change, it would be very limited if there are capabilities or features that you need. Again, your ability to get, that would depend on all of the other or at least the majority of the other consumers also asking for that feature so that the cloud service vendor or the cloud service provider would actually create that capability. Now when you look at cloud revenues, Cloud revenues are growing at a pretty fast space. The pandemic actually had a dramatic growth, led to a dramatic growth in cloud revenues, with a lot of companies moving into cloud based services. When you look at the different services and the revenues coming from It, business process services, business process as a service, for example, this would be where you would outsource your service desk capabilities, right? That was 49,000 $509,000,000 is the projected revenue for 2022 for the next year. Platform as a service, 72,000 million, right? Cloud application services, or As is the single biggest category at 140,000 $629,000,000 Then we have cloud management and security services. So I guess say $18,000,000,000 Infrastructure as a Service is about $81,000,000,000 projected for 2022. Desktop as a Service, which is where you would actually get a full featured desktop computing capability is the smallest slice of the market at about 2 billion. But the total size of the market is very, very big. As we look at this shift from traditional IT spending into the cloud, it is interesting to match where the money is going from the traditional computing into the cloud. When you look at enterprise software, which is CRM, customer relationship management, or enterprise resource planning systems such as Oracle, EBS and SAP. Enterprise software could go into software as a service, platform as a service, or some elements of that would have to go into the management and security part of it because the user account management has to be taken care of outside of those applications. Your data sender systems, right? Again, getting split over public and private computing. We could also have a number of IT services that could move into infrastructure as a service. This is where a lot of servers storage, all of that gets moved into the cloud and then things like the help desk, which would be business process as a service management actually I shouldn't call it change management, change documentation. Change management itself is more of a management function than a technology function, but change of requests processing would go into a business process as a cloud. This has a big impact on IT services. The question to ask here, is it always right to go into the cloud or is cloud always the right choice? Now we live in what is called a cloud first world. That is, by default you have to assume that you are going to go into the cloud and then justify if you are not. With that said, we still want to follow a structured methodology for figuring out which of our services will stand to gain the most from migrating into the cloud, right? We have to identify workloads, that is, we have to identify applications, we have to identify processes that would gain the most by moving into the cloud. If the organization really does not have a need or does not want new or improved IT capabilities, they may not necessarily need the cloud. Going into the cloud does allow the IT team to be significantly more productive and that is on the developer side or on the infrastructure management side. But if it's a mature business that is really not thinking about IT as a core competency, you may not really need the cloud. Now, not all workloads are suited for a cloud solution. And because of this, many organizations will choose hybrid IT. That is, some applications will run on premises, while other applications will run in the cloud. The best example for this would be enterprise ERP systems in large companies. When you look at the Fortune 1,000 size companies, most of them would not be ready to move their ERP system into the cloud because they have concerns about control, concerns about capabilities, and they have concerns about compliance. Plus, if you look at the definition of an ERP system, it runs all of the core business processes in an enterprise. And that would be seen as significantly risky if you move into the cloud. In addition, and this is something that the cloud vendors really don't publicize or actually don't even publicly say the cloud versions of SAP and Oracle EBS, which are between them, the two dominant ERP platforms for large businesses. Their cloud solutions are actually scaled down versions of the on premises solutions. That is, the cloud solution actually does not have all the capabilities of the on premises solution. If you look at a company like Walmart that runs SAP, SAP in the cloud does not have the capability to run an organization of the size and complexity of a Walmart. Although SAP's on premises system does, this actually leads to this hybrid IT model where in many large organizations, the ERP system actually runs in the data center, and a large number of additional systems that they depend on run in the cloud. Now, when you get into mid sized enterprises, then there are ERP systems, including from SAP and Arc, that are perfectly capable of running companies that are in that mid market segment. And what I mean by that is companies that have revenues of $100 million to let's say about $10,000,000,000 Right? Those companies at this point in time would be great candidates for moving almost entirely into the cloud as we look at deciding whether to go into the cloud or not. I have a framework here from Gartner that allows us to take a quick look and this is a very high level view of the benefits of cloud computing and the challenges of cloud computing. And trying to put the prospect of consumer into this two by two matrix. When you look at companies where the challenges are very low and their computing environment is very manageable, they are going to be a great candidate for going into the public cloud if the benefits of going into the cloud are clear and very high. If the benefits are not very clear, the benefits are somewhat low, then a company that will fall into that category. So test out the cloud, should check out the cloud and see if they can actually move some of the services into the cloud. Now if the challenges within an organization are high or the infrastructure and the complexities are unmanageable and they are unable to actually quantify the benefits of going into the cloud, they should stay away from the cloud. And this is where I gave you the example of large scale enterprise ERP systems. At this point in time, the challenges of managing large scale ERP implementation is very high. The benefits of moving into the cloud are low, or in some cases the capabilities just don't exist in the cloud. Don't do it by current estimates. Large scale migration of enterprise class ERP, I'm talking about companies that are, let's say, $100 billion and above in revenue. They are staying away from the cloud now if they are higher, unmanageable. Um, challenges. But the benefits of cloud are clear, companies need to go into the private cloud. Now, here you get all of the benefits of the cloud with a much lower proportion of the risk because you don't have the underlying infrastructure being shared with other consumers or with other tenants. That gives you a little bit more security and a lot more control over the cloud capabilities, those companies should really consider moving into the private cloud. This is a cloud adoption framework from SAP. This framework considers six different actions. The first one is asking the question, why. Why are we moving into the cloud? What do we hope to gain by moving into the cloud? Who are the key stakeholders? Where are we going to host these cloud based solutions? Are we going to do it, build a time line? Finally, how are we going to have measures to show that we are successful? Now, they said take these six actions. And for each of those actions, look at them from five different perspectives. You look at it from the business perspective, where you are focusing on cause, looking at capital expenses, moving to operational expenses, looking at your partnerships. You have to look at your application portfolio, look at the technology that you have. Look at the processes, and we're talking about IT processes. And finally, look at governance. The framework here is for each of the six actions, consider all five perspectives and then iterate multiple times to develop a cloud strategy. I've got the full article linked here for those of you that would like to gain more understanding into this framework. Now, a generic cloud migration framework from Gartner is what I have here. This allows you to actually look at each application in your environment and then determine whether that application is a candidate for migration into the cloud. If it is a candidate for migration into the cloud, then they have to decide what form of cloud computing in terms of the cloud service model and the cloud deployment model is this particular application going to take? Now the key here is starting with a discovery process, where you have to have all of the applications in your environment fully inventory. This is actually easier said than done. If you look at a large company, let's say the size of a commons down the street from us, 50 miles from us. If you look at a company like commons, they're run nearly 1,000 different applications in their environment, although their primary application is Oracle's EBS. In spite of having a large application such as Oracle that handles a good majority of the core business processes, they still have nearly 1,000 different applications within their IT landscape. So we have to go through this cloud migration framework for each of these applications anytime you are given a cloud migration problem. This framework helps you to identify whether a candidate, a particular application is a good candidate for moving into the cloud. And then it helps you answer the question of what exactly are we going to do when we say we are going to move it into the cloud next, if you look at how to choose a cloud model, how to choose the deployment model or the service model, we have a really useful cloud decision framework. I'm not going to walk you through this, this requires a little bit of reflection. So I'm going to leave it up to you to go to the source document and go through the Cloud framework. And this is a very important key thing to understand, right? We are looking at assessing our business and our applications. And then you go through the vendor selection process to figure out which vendor is appropriate for Cloud, and then we have to mitigate our risk and liability. And that then brings us. Steady state operations, right? I'm going to leave it up to you to actually go through and make sure that you understand this decision framework. This is something that many of you may need to refer to fairly frequently. In this slide, we are looking at a cloud adoption framework from different perspectives provided by Amazon AWS. From a business perspective, adopting the cloud should be compliant with IT alignment. That is, we need to make sure that IT is aligned with business needs. And IT investments can be clearly tied or should be capable of being clearly tied to specific business results. Here, from a business standpoint, the business itself, whether that is business managers or accountants, finance or you know, the business leaders who are involved with strategy need to make sure that the movement to the cloud aligns with the business actual needs, right? In other words, that you're not just chasing a fad or doing this because everybody else is doing it. From a people's standpoint, moving into the cloud requires significant levels of training within the IT organization that might require changing from a staff standpoint. As we saw earlier, the IT organization has to adapt to a completely different model of operation, acting much more as a broker. The capabilities of the people that you have in your IT organization need to evolve. They need to be trained. And to some extent you'll also to hire people with knowledge of particularly cloud contracts and vendor negotiations. From a governance standpoint, we want to make sure that the skills as well as the processes within the IT organization align with the goals for the organization itself that are defined by the business strategy, right? So that comes from that business perspective. So basically from a governance standpoint, you're saying are we building an IT organization that has the skills and the business processes which will help the business achieve the goals that they set out to do by migrating into the cloud. Now from an overall platform standpoint, once we make that migration to the cloud, all future IT investments are going to be driven by the fact that we are now in the cloud. It is very important for all the stakeholders to understand the nature of the IT systems as they are being used now and how these systems actually interact with each other. For example, if you are subscribing to software as a service, users need to understand the limitations of software as a service from the perspective of customizing applications, or really the lack of customization capability. Software as a service right? Or if new applications are being built or new applications are being procured, The entities involved in that decision making need to understand how those new systems would interact with the Cloud based architecture from a security standpoint. Moving into the cloud, on the one hand, you could argue, uh, shifts a lot of the security burden over to the cloud provider. But on the other hand, it also means that your IT organization loses quite a bit of control. They are relying on the provider for many of the security capabilities. And they give up the control that they would have on the IT landscape. This makes things like auditing significantly more difficult. And it's very, very important to understand that even when you move into the cloud and the security responsibility gets shifted to the cloud service provider, the liability does not get shifted, right? So for an organization, whether they are in the cloud or not, if there is some kind of a security breach, they still have to take ownership of the liability created by that breach. And finally, from an operations standpoint, huge change in the way the IT organization actually works. They will serve much more as an intermediary between the end users and cloud providers, particularly when it comes to software as a service, right? So we will need to define appropriate operations protocols in terms of how day to day engagement between the end users and the IT landscape that is provisioned in the cloud is going to work overall. As you are moving into the cloud, you have to define a strategy for moving into the cloud. You have to figure out how you are going to migrate all of the workloads into the cloud, right? All of the different applications, different systems storage, all of that needs to go into the cloud. And that has to be done at an individual application level. And finally, we have to look at that cloud adoption from the perspective of all of the different stakeholders that are going to be impacted by this significant change in how the organization consumes technology or makes technology available to its stakeholders. Now I want to leave you with somewhat of a funny list that Gartner put out last year that they call cloud myths. The first one is that cloud is always about money. Then I have mentioned this in previous lectures as well, about how economies of scale actually makes cloud computing much cheaper. But moving into the cloud is not necessarily about saving money. It is much more about business agility, resilience, and flexibility. Now, the flip side of that is that you don't have to be in the cloud to be good, right? Cloud is not the solution to everything as we saw as a cloud strategy. The CEO said, so is not a good strategy, right? A lot of times business leaders would read something in the Wall Street Journal. Or they might go to an industry conference and see that the competitor is moving aggressively in the cloud and say, oh, let's do it too right now. The other thing is, in vendor relationship management, from a risk standpoint, IT tends to be very focused on a single vendor, although single vendors bring their own set of risk with them. Compared to a multi vendor strategy, most organizations actually stick with a preferred partner or two. That same strategy cannot be applied to the cloud because many cloud providers are actually specialists at what they do. And the portfolio of applications that a big organization needs cannot be provided by a single cloud provider, in all likelihood. Cannot be provided by a half a dozen cloud providers, right? It might be a large number of cloud providers that might be necessary depending on what you need. Now, the cloud is not really more secure than on premises, right? The underlying shared infrastructure will essentially make it certain that the cloud cannot be more secure than our on premises network. That doesn't mean that the cloud cannot be made secure, it's just that as rule of thumb, the cloud is always going to be a riskier proposition than on premises solutions. Now the flip side of a single cloud is going into multicloud. The belief that multicloud will prevent lock in with the vendor. And that is not true because many cloud providers have a single solution that may not be matched by others. For example, Canvas does one thing, learning management system, Salesforce does many things, but each one of their solutions are unique and not really easily replicated by other vendors. Now, once you move into the cloud, the job is not over, the job just changes, right? So that's just a first step to get the maximum Andy out of the cloud. Then you need to now start leveraging the new capabilities in the cloud. Enterprises are really not moving back from the public cloud. Enterprises are being very strategic about what applications they put into the public cloud and what applications they put into the private cloud. And finally, most organizations who say that they have a cloud strategy really do, They haven't thought it through well enough. To summarize, we looked at the definition of the cloud. We looked at the five essential characteristics of cloud computing. And that is almost like a litmus test to see if the services that are being offered by a provider are to be called. Cloud Computing looked at the two main actors in this relationship, the Cloud provider and the Cloud subscriber. And the relationship between them in terms of the single tenant model, the multi tenant model as well as the responsibility for compliance, we looked at different cloud deployment models, private public, community, and hybrid. We also came to the conclusion that most large organizations are going to be in a hybrid cloud model that has got significant implications for the IT organization and their role within the enterprise. In the next few modules, we will do a deeper dive into each one of the cloud service models. Thank you all. So I've got the source documents for this lecture here. I would encourage you to actually read some of these documents. They're very well written, very well researched. If you have any questions, I hope to see you at the Q and A session that's coming up. Or if you're unable to attend them, please feel free to send me an e mail. Thanks. Finally, with cloud computing, we have a number of security issues, right? We have a whole module on cloud computing security. So I'm not going to get into this in very great detail. Many of the threats that are associated with cloud computing are similar to what would be associated with traditional computing. But there are a couple of things that I want to point out. The, the two important ones would be insecure application programming interfaces. Web APIs are provided by the cloud provider. You just consume them, but you may not have enough information about how secure that API's are, and also the very fact that you're running on a shared underlying technology creates significant vulnerabilities. In addition to this, from a management standpoint, it's very hard to understand the risk profile associated with cloud computing because unlike on premise computing, you just don't have enough data about IT operations at the service provider. When you look at the technology choices that you have for migrating into the cloud, you have essentially a choice between compute. That is, we need to figure out what is the hosting model for the application. Are we going to run on infrastructure as a service or are we going to run it on a platform, or are we going to get full featured software as a service? We have to look at the data store, right? That is the database, the cache logs, anything else that an application might persist within a storage subsystem. And we also need to look at the messaging technology in our application architecture. We talked about how different components or services of an application communicate to each other through standard interfaces. By exchanging messages, the services can reside in the cloud. They can actually reside in multiple clouds. But then we will need the appropriate messaging technology to enable messages both synchronous and asynchronous between the different components of the application. I have mentioned security as a significant challenge or a significant concern for organizations moving into the cloud. From a security standpoint, there are a number of security requirements that we need to address before we can consider moving into the cloud. First of all, we have to look at identity and access management. The key with identity and access management is that the cloud provider should be able to integrate with whatever enterprise identity access management solution that the consumer has. That is, the cloud provider should have seamless integration with the IAM solution that is used by the consumer. Now from a cyber threat standpoint The Cloud provider needs to be proactive in terms of making sure that any vulnerabilities that are discovered are patched as quickly as possible. They need to have automated capabilities for code review, not just for a single subscriber, but for all subscribers. Because any code vulnerability in any subscriber's application software, or deployed cloud software could create challenges for the entire cloud. From a privacy standpoint, there are a number of significant challenges. For example, the data that belongs to the consumer is actually stored on the provider's website. What capabilities, what protocols, what procedures do they have for handling any sensitive data? For example, if you have personally identifiable information and financial information about your customers in the Cloud, the controls around that data need to be provided by the service provider and your ability to actually implement controls would be somewhat limited from a security operation standpoint. When you move into the cloud, the cloud provider essentially becomes your security operator. And they need to have a very robust security operation center where they have security assessment capabilities, reporting capabilities. And if something were to happen, they would need to have incident management and response capabilities. From a regulatory standpoint, the cloud provider needs to have a security framework that satisfies multiple regulatory requirements. Now, it is important to note here that because cloud providers are, for the most part, private entities, and the regulatory environment, especially in the US, is fairly technology agnostic, And that is, they tend to define regulation in broad generalities rather than specifics. That creates a challenging regulatory environment where there's really not a whole lot that he can do in terms of enforcing policies or regulations on the cloud provider. So you have to depend on third party audits, you have to depend on frameworks such as those provided by the NIST as a way of examining the Cloud providers regulatory stance to see if it would expose the consumer to any undue risk. Now from resiliency availability standpoint, the cloud provider needs to have significant availability defined, that needs to be in the contract. From the cloud consumer standpoint, everything that is in the cloud requires an stable network connection. If the cloud provider is far away or the cloud consumer is in, let's say, a remote location, they need to have the capabilities to at least run their systems for a while if the network goes down. And that does open up the challenge of keeping some data local. From an application development standpoint, the consumer needs to have release and change management policies. Now, the most important burden here, assuming that you are essentially running in a platform as a service model. Things such as application level code reviews, enforcing of software development life cycle processes. Actually managing the change management policies and reporting on them. And offering the capability for user driven change acceptance. All of that would have to be on the part of the service provider. Finally, when it comes to enterprise resource planning, and I've said that this is for the large companies, the final frontier in terms of moving things into the cloud, you have to have proper security zones defined, as we saw in the network architecture classes. We need a proper security zones defined, we need data protection. We also have access provision at the process level. Each process will need to be given specific access to data or to other services. Erp needs to use the original identity and access management platform that is approved by the organization and basically have a strong authentication with single sign on capabilities. And that should be role based.