Hello, and welcome to this lecture. We've looked at a lot of the positives of the Cloud and how your organization could utilize this technology to your advantage, but with all the positives, there are some negatives too. And I feel it's important we discuss a few of these to help you in your decision of Cloud adoption. So let's take a look at some of these bottlenecks that you may come across.

The creation of your infrastructure in your services within the Cloud are very dependent on the platforms and versions of those platforms that they provide, and as such can be fairly inflexible. From a compute perspective, if you have some bespoke and in-house developed applications and software that require older platforms, then this could be an issue for your deployment. Cloud providers usually provide the latest operating system software in a few different iterations. Be sure to look into different vendors and the different platforms for infrastructure that each of them provide. However, there are third parties and other users that create their own instance images that are made publicly accessible, that will differ from the vendor's own selection. So be sure to check out the community repositories, such as the AWS Marketplace, for these custom AMIs, Amazon Machine Images.

Also, if you are looking to migrate database systems, be sure to check that the database services and platforms that the Cloud providers offer. You may need to perform some changes in your database tables before they would work within the Cloud. Be sure to check for migration tools available to aid in your database migrations, such as this article, which looks at an unpremised server database migration to an azure SQL database. Or this specific service set up by AWS to help with the database migration, AWS DMS.

Within on-premise environments application services and functions often operate on outdated infrastructure. They rarely get changed and altered as they just work, and people are often afraid to start performing essential maintenance to keep inline with industry standards in the concern that it would no longer work. This is especially true for many bespoke applications. Understand your environment, understand your platforms within your environment, and see how it maps across to what your chosen Cloud provider can offer.

Depending on how your Cloud infrastructure has been architected, you would likely access all your services across the internet. But what happens if your internet connection experiences problems, and your connection to the outside world goes down? You lose all access to your services until your internet connectivity has been restored. You may need to look at increasing the resilience of your internet connection to mitigate these risks. Who would be effected should the link go down? Will any of your customers be impacted, and at what level? How much of an issue would this be to your business?

Again, as your service would be in the Cloud, you need to think about latency through this connection. How does this differ from the latency that your users and customers experience at the moment? Will network connectivity speeds be adversely effected? This could help you decide which services would work better in the Cloud, and which ones may need to remain on premise, depending on the criticality of latency to certain business critical services.

So I would recommend you build high availability into your connectivity to the Cloud if this would effect customer experience. Ensure you have multiple routes of connectivity to your Cloud vendor. Perhaps look at the connection services offered by the vendors, such as AWS direct connect, which provides a dedicated network connection from your on premise data center into the AWS network, which can provide a connection speed of 10 gigabits per second. You could also have a VPN connection as well to offer a fail safe option should you experience any performance issues with your direct connect route.

I know throughout this course and others we have drilled in the fact Cloud computing offers significant cost savings, and it does, it really does. However, if you are not familiar with how Cloud costs are calculated and where they arise from, then you could soon be looking at bills that far exceed your estimate. There are many ways to help ensure your costs are kept to a minimum, and that you are not spending unnecessarily. Ensure you have a Cloud engineer that has a full understanding of Cloud costs and can help you maintain your Cloud spend. There are so many hints and tips, and many articles on how to go about restricting your costs and that in itself could be a whole new course.

One area of spending that some people don't realize or take into consideration as much as they should is that of data transfer costs. When transferring data into the Cloud it's typically free of charge, however, any requests which result in data being moved out of the Cloud incur data transfer costs. Be sure to look at these costs for each of the services that you intend on using, as pricing could be different for each, and even different in different regions across the globe, too.

I would suggest looking at services that could help reduce these data transfer costs, such as AWSCDN, a content delivery network. This would reduce cost by caching a lot of the data from your origin servers, and therefore reduce the amount of data transfer required.

Be sure to look at the different cost calculators that some of the larger public Cloud vendors provide. These can help you get a rough estimate as to what you expect your costings to be.

Your Cloud provider takes on a huge amount of responsibility from a security perspective. They operate and maintain all host hardware and the underlying global infrastructure of their Cloud. They essentially have physical access to the drives where your data, and your customer data, may be stored. Although they are certified and comply to a vast array of different security governance controls, how much can you as an organization and business trust them?

There are, of course, additional steps you can take to help protect any data extraction from anywhere, such as implementing encryption of data at rest, and when in transit. But here I just want to highlight that we are unaware of who is actually responsible for maintaining the host that we use. Now of course the Cloud providers undergo strict background checks when hiring personnel to perform duties that allow them to potential physical access to our data, but it is something to bear in mind.

As your infrastructure is all accessible via the internet this opens up the possibility for an increased attack rate by anyone out there wanting to cause harm and damage. Therefore it's crucial that you have a Cloud security expert when architecting your infrastructure. Failure to apply the correct level of security at all levels of your deployments could open holes that malicious users out in the internet will be keen to exploit. This could lead to significant detrimental effects on your business, and customer base, should any of your data be compromised. Your reputation as a business could be negatively impacted, resulting in a loss of competitive edge within the market, and ultimately having a financial impact on your organization.

Ensure you implement common security boundaries, such as bastion hosts and NAT instances. A bastion host acts as a central connection point in a public subnet of your infrastructure. Connections to this bastion are established from outside of your Cloud network. Once connected, you can use that bastion host to gain RDP or SSH access to your other instances within your private subnets. This is a great way for your support staff to access your private instances from outside of your Cloud network.

A NAT instance allows your private instances, instances inaccessible from the internet, to initiate a connection to the internet to perform essential security patch updates.

Moving to the Cloud isn't going to be as simple as performing a lift and shift, as it probably would be if you were simply to move premises. Compute storage and network aspects of the Cloud are all implemented differently. In addition to this, many of the additional services that you might be keen to use require your applications to be Cloud ready. By this, fewer applications take full advantage of the power of the Cloud, and its scalable possibilities among other features. Your applications need to be designed in a decoupled fashion.

Decoupling the application architecture essentially splits out your processing and data into different elements and components, so building an application as a collection of services helps to build a decoupled application that would be more closely aligned and Cloud ready. Having the ability to scale out specific parts of your application, and having them work independently of each other allows for the flexibility and scalability of the Cloud to take your application to new levels depending on demand.

Ask yourself these questions when decoupling your application, has it been designed with failure in mind?

• Is it comprised of a set of components?
• Can these components communicate independently of one another?
• Can these components be scaled out?
• And is it secure?

As you could imagine, if you wanted to take advantage of these Clouds features for your applications, and they were not constructed in a decoupled framework, then this would take time and investment to accomplish.

By utilizing the Cloud, you now have another vendor to contend with. You have passed responsibility of a part of your business onto someone else, and so you have a responsibility to manage that vendor. One aspect of this would be related to SLAs, how do the Cloud vendor's SLAs work in relation to the SLAs that you currently operate for your customers? Are there open gaps where you may now not meet specific service level agreements due to the fact that your Cloud vendor operates on a slower response time? Will this effect any contractual elements you have with your customers? How will you engage with your vendor should there be any issues with your infrastructure, and how long will it take them to respond? What sort of support cost will there be? Have you factored these support costs into your budgets?

There are a lot of components to consider here, so please bear in mind this additional management that has to take place.

Dependent on the size of your organization and the requirements you have, you may need to speak with the Cloud vendor and establish a relationship with them through an account manager to get answers to these questions. You need to be sure that you have a deep understanding of the SLAs that they have surrounding the infrastructure and services that you're going to use. They will be able to help you mitigate any issues that may arise and offer support and guidance.

It's all well and good being able to migrate services to the Cloud, but it's likely that you'll still have some services on-premise. This would be especially true if you already have an established organization with a data center fully populated. However, how easy is it to integrate the Cloud with your existing on-premise solutions? Will you have services running between Cloud services and the services that are running in your data center? What are the implications of this? Are there any latency issues? You will need an experienced Cloud architect to be able to define some of the restrictions and concerns when it comes to cross-site integration.

There are many services that lend specific configuration for this type of framework, but again, can your existing services and applications work in this specific setup? You will need to ensure the connection between the two facilities is capable of managing the work loads that you expect. Minimizing latency is essential when architecting integration with existing on-premise solutions.

You may need to perform some load testing before migrating your production services to test some of these areas. I would also recommend you map out to define a clear understanding of how your communication paths will work between all your services to optimize your workplace between the Cloud and on-premise. This will allow you to focus on any areas when you feel performance could be a concern.

That brings us to the end of this lecture. Next we're going to be looking at Cloud use cases for different sized organizations.