Several weeks ago, I visited a Global 50 manufacturer. This organization had a very complex supply chain and manufacturing sites, as well as relationships with suppliers around the world. It had to govern the data exchanged between suppliers, customers and even internal organizations. And it was not appropriate for everyone to see everything.
In the middle of this conversation, the manufacturer discussed the depth of its cloud and cloud provider relationships, as well as the issues that the multi-cloud posed to its organization. Given that, I decided that it was time to dig into the multi-cloud with the #CIOChat.
How many layers of cloud do you have internally and externally?
CIOs had different responses depending on the complexity of their organizations. Some said that they did not really think they had a "cloud fabric". These CIOs use a small number of cloud providers. For them, there are few internal and external suppliers. Given this, they do not believe that there are layers unless an organization runs in hybrid mode (under multiple clouds) or that silos of data are located in the cloud. whole of the company.
Other CIOs, however, say that they are full of complexity. An IOC Higher Education has started the discussion stating that I suspect we have an official number of cloud providers, and that this number is not the number actually used. CIOs working in complex cloud environments say they like to express the problem in the form of cloud layers. They say they publish services and consume services. And then our services consume services. It's not like a fluffy cloud blanket. It's more like branched constellations.
These CIOs openly asked how many points and services they were connecting to? It's not as simple as layers. They suggest that a very large percentage of cloud traffic does not pass through local endpoints. It's from cloud to cloud. These CIOs report using dozens of SaaS products for which their implementation is opaque or cloudy. They say to add to this number Office 365, AWS, Google, Azure and more. Internally, they can use VMware, but the complexity increases beyond this point.
For this reason, IT managers say that they need to educate their users. There are easily "dozens" of sanctioned cloud apps in most organizations. According to the ISD, the problem is that as much as 10% of data downloads in a typical enterprise go to unauthorized cloud applications. CIOs believe that these workloads are probably spread over more clouds than anyone else realizes. SaaS providers must count to a certain level, including when you integrate them, and when you evaluate their capabilities and security. Most organizations use multiple clouds externally. To be clear, the CIO says that the use of the internal cloud can be linked to hybrid implementations. At this point, IT leaders shared the fact that when a major breakdown had occurred at Amazon, a year or two ago, it was shocking to see how much of their SaaS services had been affected. Obviously, there was no plan of urgency.
The use of management fabrics
The CIOs viewed ecosystems as the key word. An IT manager said he used a combination of Global Map Fabric from MapR and Pivotal Cloud Foundry (PCF) to extend and simplify their data architecture across five public cloud offerings and multiple geographic data centers. These multi-cloud data structures are designed to ensure scalability.
CIOs say that the use of management tissue is on the rise. It's a growing space and a corollary to security, as Gartner and others have pointed out. CIOs suggest the need for cloud security posture management (CSPM). An IOC suggested that it was a remarkable example of the complexity of the conversation surrounding the cloud. An IT manager admitted when he spoke multi-cloud that he tended to think of IaaS / PaaS providers but not SaaS providers. This is clearly a mistake because of the need for applications to connect higher level business capabilities.
CIOs believe that few companies can afford to bear the costs of true multi-cloud duplication strategies for the availability of a single application. Instead, you need big bets placed on a central cloud service provider and an ecosystem of secondary providers around that. An information systems manager described the problem of vendors relying on vendors who rely on vendors. An information systems manager, exasperated, said, "We thought it was difficult for our data centers to manage relational databases to map issues of interdependence. "
CIO suggests that urban sprawl looks more like branches. So, if the trunk (eg, Amazon) is affected, what does it mean for service delivery? And what should be our response to business continuity after understanding this impact? According to the DSI, with the right structure, the multi-cloud becomes a revenue-generating component built into your environment. This allows customers to choose the cloud with the right levels of service at the right price and the right use case.
CIOs suggest that the emergence of internal and external ecosystems is what drives people to adopt multi-cloud strategies. No more time for a one-stop shop. Many CIOs are increasingly opposed to blocking providers. The fabrics help stimulate innovation while guaranteeing flexibility. And now, instances and cloud containers are associated with constant, real-time costs.
How do you audit and govern the use of the cloud in relation to the service model and strategies?
CIOs claim that they primarily use a structure as a policy enforcement mechanism. The objectives of the policy should relate to data security and governance. CIOs with business leaders need to define a basic IT strategy and use it to drive their achievements. They need to partner with procurement and other areas to provide some control and then leverage it to control the company's data. However, many companies do not have the ability to accurately forecast cloud demand.
In the meantime, it is important that CISOs consider using the FAIR Institute model for risk identification. This can provide great information to better quantify risk, even when the data is uncertain. Overall, this requires due diligence on what has been defined and how it has changed over time. The data must be protected by cloud. Disaster recovery should also be done by cloud. This increases the complexity but should limit the scope of the failures. Auditing is clearly one of the most difficult aspects of the cloud for regulated functions subject to compliance requirements.
Some CIOs believe that the audit should be identical to the one you would perform to audit and manage your private data center. If you do not have a consistent audit service model, it will be very difficult to scale your system if you switch to a multi-cloud model. There will always be slight adjustments, but you need consistency. For small and medium businesses that have opted for the cloud, managing multiple clouds is tantamount to trying to find the ends of the wire after kittens have dropped into the thread shop.
Managing disaster recovery in the complexity of multi-cloud?
CIOs point out that the cloud allows IT organizations to design in case of failure, but too many of them still treat it as their old data center. The cloud makes it easier, not harder, when the cloud is properly implemented.
CIOs insist that treating the cloud as a physical infrastructure is a mistake. The focus on infrastructure as a code makes full backups less important. It also makes it easier to rebuild an infrastructure than code it and keep it somewhere. CIOs say you have to agree from the outset the agreement with each provider: geographic diversity, schedule, testing and recovery. Cloud service providers are working very hard to solve this problem – especially the largest cloud service provider. For this reason, CIOs suggest that AWS invests in the Guard Duty security console. CIO, SkyHigh and CWS, can give universal visibility to the audit.
An information systems manager has said here, whatever your management design, I'm not sure we do it. This can be a big problem on site because of the extension of polyglot persistence, local storage versus SAN over hyperconverged network, and so on. Cloud reminds CIOs of the beginning of spreading virtual machines.
An IOC asked a question about disaster recovery. They said we had no backup. This is a mesh of pointers and metadata. Each provider makes it poor to incredible. If you can not select * in the table, you must trust the providers.
That said, the DSI advises you to frequently test your system to ensure that disaster recovery and business continuity are integrated (with real data). Most cloud providers have API integrations that you can use for DRaaS. This will also help with audits. If this does not generate revenue for your business, you should outsource it. If you are considering a disaster recovery in a cloud world, you are far behind and you are asking for a world of injury. Today, data management is essential and much more sophisticated.
Does the regulation force multinational companies to create an increasingly complex multi-cloud fabric?
CIOs say that most multinationals already have complex structures to manage before public cloud options. The cloud simplifies the process in some ways, but makes it more complicated in other respects. What could force the multi-cloud is when you have a sovereignty problem in a country where your cloud service provider is not chosen.
Regulations often force regional complexity between suppliers. When you start important activities in "red flag" countries, you must have a higher level of thinking. The cloud was the tactical response to the GDPR for some organizations that could not assess quality (on time) on-site. In general, regulation is at the origin of technology and does not take enough into account what we are working with.
AWS does not know your applications. AWS does not know your business. You do. But they can then locate most of the main sites and comply with new privacy laws.
The multi-cloud will only complicate IT management. Although public clouds promise a lot – better scalability, better security, the list goes on, this creates a risk for CIOs who do not know the architecture of their business or when a failure of their provider could affect customers. It seems to me at least that it is time to develop the existing concepts of CMDB and Asset Management. I look forward to the reflection of ITIL 4 on this topic.
This article is published as part of the Contributor IDG network. Vouloirjoindre?