"Hi, everyone.

My name is Greg Cockburn and I am the Head of Hyperscale Cloud here at AC3.

In this series, we are exploring application transformation and taking an application on the journey to cloud nativeness.

In this video, we will explain the first steps you might take on your journey by migrating a simple web-based application to AWS services. We'll be using a combination of platform-as-a-service managed services and some infrastructure as-a-service services, kind of managed by hand.

Our example application currently lives on premises on a virtual machine environment and relies on the underlying virtualisation to maintain high availability.

Let's draw in our application in the data centre. We have our virtualisation layer, our application server, and our database server.

What is the first step in migrating to the cloud?

The first step in migrating to the cloud is to understand the users of your application, what language is being used, if it's maintained in house, if it's maintained by a third party, or if it's a commercial off-the-shelf application.

You might also need to consider whether you've still got the source code, if that source code is around and do you need to make any changes to it?

Other things to consider are the underlying architecture. For example, is it X86 or is it Spark or something else?

The last thing to remember to look at is your database. What engine is it? And is it compatible with the database service that is in AWS? Once you've got that, you need to map it into your AWS services.

Today we've chosen these AWS services to deploy our application into. We've got Aurora down here for our database, and we're using MySQL in this example.

We've got our auto-scaling group for our application server and to front that we've got a load balancer and Route 53. Because we're using an auto-scaling group, we need somewhere to store the sessions. This will be Elasticache, Memcache over here. I'll talk a little bit more detail as we go through. These other services I will cover in a moment.

So, the first thing that we need to do when building architecture is to define a VPC. Then we need to define some subnets. And to make sure that we highly available, we're going to use three availability zones.

Availability zones are a concept in AWS of segregation, usually across different data centres, to ensure that if one data centre isn't available your application can keep running.

How do build this?

To build our application, we're going to use CloudFormation. CloudFormation is an infrastructure as code construct to deploy AWS services.

We're going to define our VPC and our subnets. We want to have three subnets. A public subnet. An application subnet. And our database subnet.

This ensures that the components of our application are segregated.

As part of this, we will join our load balancer to our application auto scaling group. Our auto scaling group might have a number of instances in it, depending on the requirements at the time and I'll delve into a little bit of that later.

Our Elasticache service will be the same with a number of nodes across the different availability zones. The same with our Aurora instance to ensure a high availability.

For session storage, our application auto-scaling group is going to talk to Elasticache, and for data store, it's going to talk to Aurora.

How does a user interact with this service?

Let’s draw our user over here. First thing, the user will do is in DNS lookup.

They will look that up into our Route 53 and get a result which will turn the load balancer.

The load balancer then makes a connection to one of the instances in the auto scaling group, stores a session into Elasticache when it when they log in and retrieves data from the database.

The presentation layer is then rubbered back to the user to display.

How to get the data into the application To get the data into the application, we've got a number of options.

We might use what is called a direct connect. This is a virtual private circuit from our data centre into AWS, and can be of any size from 50 megabits per second to aggregates of 10 gigabits per second, up to a maximum of 100 gigabits per second.

Another option we have is a VPN across the internet. Or we can purely use the internet itself without any link.

Now depending on the types of data that you're trying to get out of your database and into Aurora, you can use the native tools from MySQL and Postgres or if you're trying, or if you have swapping engine or need to keep it available as much as possible, you can use the DMS service down here.

DMS stands for database migration service and this is a service that can take a number of source databases and convert them into an Aurora database migration, database service.

We connect the destination. We connect our source and DMS can do that conversion in here.

How do you make sure your transformation is successful?

To make your transformation a success. I recommend using an AWS partner. I may be a little bit biased, but I recommend using AC3. We are a Well-Architected accredited partner and we look at your architecture through the five pillars of the well-architected framework.

That being operational excellence, security, reliability, performance efficiency and cost optimisation. Let's look at our architecture, through the five pillars.

Operational excellence

We’ve used CloudFormation, so we can look at our environment at any point in time and ensure that it hasn't drifted from the original formation. If we want to make changes, we make it through CloudFormation, and therefore we've got a history of all of the changes made.

Security

We've defined three different subnets, to make sure that we don't have any leakage of information between each of the subnets. And each of those are only containing the information that's required.

Reliability

All of our services are deployed across multiple availability zones, an auto scaling group can move between availability zones as required.

Our Elasticache has multiple nodes that are deployed across the availability zones. And our Aurora database has n plus 1 nodes, where some may be a reader and others may be writers.

Performance efficiency

Our auto scaling group is only sized to what is required by the number of users using it at the time. Because it's auto scaling, you can scale in to maybe even only one instance overnight. If your users aren’t using it at night or to as many users as a required during the day. We can also scale the instances up, if needed.

Our Elasticache and Aurora instances can also be scaled up if we need them to be or scaled-down, if required.

This flows also into our cost optimisation.

Cost optimisation

We're making sure that we're not running any bigger instances than we need or any more.

Lastly because this is a little bit of a different environment to what you've been used to, you might need to use a service such as CodeDeploy.

CodeDeploy will help you make sure that the most recent version, of your code is deployed onto the auto scaling group as the nodes come up and down.

So, this is an example of migrating a very simple web application into AWS and starting that transformation.

Thanks for joining me today on the first in our series on application transformation.

Please join us in the future as we continue our transformation journey.

My name is Greg Cockburn and I'm the Head of Hyperscale Cloud here at AC3. Thank you."