Hello and welcome to this lecture.

There will, of course, be a number of risks when implementing the cloud. In another course, Should Your Business Move to the Cloud?, we looked at some of the constraints which could also be seen as risks. And here, it looks at some of the technical risks that may arise.

In this section, I want to address it more from a business point of view.

Legislation and Regulation.

Your data may be bound by specific regulations, such as the EU data protection laws, which require specific security controls, retention requirements, et cetera, dependent on the data being stored. Other legislations exist where certain data may have to remain within a specific region and cannot be transferred out of those boundaries.

You need to architect your environment to meet these security requirements and mitigate the risk of data being stored in a geographic location that's restricted. Breaches to this legislation could have a legal impact and lead to additional risks against your organization. So it's fundamental that you're aware of your data privacy and storage location laws and regulations.

Technical Ability.

We briefly covered this in one of the previous lectures, so I won't go into any depth. But it's important to point out that the people you need to manage your current infrastructure may not be willing or keen to learn another technology specialization, especially if it doesn't really interest them on a technical or career level.

This becomes a technical ability risk to the business as you will not have the required work force with the adequate skills to confidently help you with the migration of your services to the cloud.

You need to ensure you have a completely new skill set from your employees to a level that has the knowledge to architect, implement, and administer the environment. Without this, your environment will end up failing from a productivity, security, and objective point of view.

Reliance on a Third Party.

Running services on the cloud removes control from your business. The loss of this control brings risks as you're now dependent on them performing their job effectively to manage the underlying architecture that your services are now running on.

Failure on their part could mean failure on yours and to your customers. This is where architecting a high availability solution between different geographic regions is key for critical workloads within the cloud to help mitigate cloud vendor failures. Failures within the cloud vendors does happen and has happened.

For example, this link on the screen shows you an AWS failure where an availability zone went down. Therefore, to help mitigate this risk for high-impacting services, some enterprise organizations are not choosing to adopt services from multi-cloud vendors, for example, from both AWS and Azure in a multi-vendor cloud configuration.

Inflexibility of Contracts.

When signing up to services by the public cloud vendor, you are bound to their customer agreement and terms of use, including any SLAs they offer for their services. As an example, you can find customer agreements for both AWS and Azure via these links on the screen.

To negotiate any specific term around your own special use cases, especially where it may affect SLAs would be very dependent on your support level with your chosen vendor and the amount of resources you intend to use. You may not be in a position to negotiate any changes, and therefore, you stuck with the SLAs and customer agreement terms that are offered.

If you don't like these conditions, then you can either change your business requirements or look at an alternate provider.

The Wrong Strategy Choice.

Okay, so you've moved to the cloud for specific business benefits and requirements. However, six months later, you are realizing that you're not reaching the benefits or goals that you set out to achieve. In fact, you are spending more on your infrastructure than you thought.

Whether it was a failure in your business plan, project management, or deployment of architecture and cost management, it has failed to meet your expectations.

So now what? Do you revert back to an on-premise solution which would cost additional capex, not to mention the cost of migration again? Or do you perhaps change your cloud deployment model? Perhaps you were using a public cloud model, but it may make better sense to use a hybrid cloud model. Maybe some of your applications and services could be better deployed through a Platform as a Service solution instead of an Infrastructure as a Service solution.

There will always be a risk of did we do it right? And the likelihood is the first time will not be right and you will adapt and change how your cloud services are deployed. You need to factor this learning period into your deployment and understand these changes.

Technology Advances.

The cloud provider is continually working to attain the highest level of technological advancements and this results in an ever-changing flow of their live services.

This doesn't always work in the favor of the business, as your applications and services that are deployed on top of these may have to have a slight modification to keep up with the different feature sets, which could affect your business services.

Shared Infrastructure.

Although the use of shared infrastructure is what helps to maintain a low price point for resources, it also acts as a potential security risk. For workloads that are of high sensitivity, it may require the use of dedicated hosts and tenancy, meaning that no other customer could store data on the same physical host.

The security applied on shared hosts is extremely high and operates at a number of different layers in the host and the hypervisor. However, should any breach to these areas, specifically the hypervisor, then in theory, customers could access each other's data.

Personally, I've not heard of this kind of breach happening within the leading cloud providers, but sometimes your business may not be able to take that risk for data that meets a certain criteria.

You will likely come across many more business risks within your own organization and it's important to define what these are and to understand how to mitigate those risks as much as possible.

That brings us to the end of this lecture. In our final lecture, we shall review some of the important points we have covered so far throughout this course.