- Hello, and welcome to this
"AWS TechShift: Migrate & Modernise" video miniseries.
This video series is aimed at independent software vendors
who are currently running on premise
and are looking to migrate to the cloud.
It's also aimed at those that are looking to modernize
an existing architecture to become more cloud native.
Through these five short videos
we will explore the benefits
of migrating to AWS and the techniques involved
in modernizing a typical monolithic architecture.
We will do this by introducing a case study application,
and through each of the videos we'll dive deeper
into a specific element of the architecture to improve.
In the first introduction video,
let's again think about the benefits of migration
and introduce our case study.
(upbeat music)
So as an ISV, how will you benefit
from moving your application to the cloud?
Increase agility and performance.
Focus your time on adding new features
and differentiating your application
rather than managing infrastructure and data centers.
We invent on your behalf at AWS
with services such as AI, ML, and analytics
available on demand whenever you are ready,
allowing easy experimentation
and reducing the time to market.
Nearly unlimited scalability.
With AWS, you can scale your application
as your business grows and onboard new customers
without having to worry about capacity challenges,
such as planning and buying new hardware
for your data center.
You can scale within your local region
or go global within minutes.
Improve reliability.
Multiple availability zones within each region
allows you to architect your application
for high availability and improve the uptime
for your end users.
Lower costs: AWS benefits from economies of scales
and our experience in innovation allows us to find new ways
to deliver technology more efficiently.
We pass these cost savings onto you as our customers.
You also get the elasticity with the cloud,
meaning you only pay for what you use.
So if your application has spiky
or unpredictable usage patterns, this allows you to save
over provisioning for peak.
Security is job zero at AWS.
And with AWS, you can build on the most secure
global infrastructure, knowing that you always own your data
including the ability to encrypt it,
move it and manage retention.
AWS also supports more security standards
and compliance certifications than any other offering,
including PCI, DSS, GDPR, and FIPS 140-2.
Now let's introduce our example corporation, which we'll use
as a migration case study for the rest of the video series.
So what application will we be migrating and modernizing?
The application is a simple photo gallery
where users can upload, tag and search photos.
It is developed using Node.js and JavaScript
and has been built to replicate a business
that has been running for many years.
As a result, parts of the application are quite basic.
Some parts are hard coded and some parts are more advanced
as the application has evolved over time.
The application has a HTTP web front
which is a single page application,
and everything runs from a single server,
including the database.
Our unicorn photo gallery application
exists on premise today on a single server
in a data center and end users access it over the internet.
If we were to move this server into AWS
in a lift and shift model, we'd first look to use a service
called Amazon Elastic Cloud Compute, or EC2.
With EC2, we can run our application
as is on a virtual Linux or Windows instance,
running in the cloud, paying per hour that it runs.
This is okay, it's simple and it works,
but there are a few challenges.
Firstly, there is a single instance
in a single availability zone,
meaning that there's no resilience
should the availability zone or the instance fail.
We also can't scale the database separately
from the web tier, as they're all on a single instance.
Ideally we would want to be able
to scale the web tier horizontally by adding more nodes.
We also have to have the EC2 instance running all the time,
no matter what the traffic demand is.
We should scale based on demand as well as offload
some of the requests to static content, such as images,
to a caching layer.
Throughout the rest of the video series
we will look to improve this architecture.
We will introduce more subnets in more availability zones
and improve security using private subnets.
We will also separate out the database layer
using a service called Amazon Aurora.
We will then scale out the web tier
using an auto scaling group and a load balancer.
Finally, we'll move the static web content
to Amazon S3 as an object store
and front this with Amazon CloudFront
as a content delivery network.
Amazon CloudFormation will also be used
to define our infrastructure resources as code.
And that's it for the introduction.
Join us in the next video where we'll look at landing zones
and the VPC structure.
(upbeat music)