How to choose the right cloud architecture for your business?

00:00 → 00:02

Stable and high web performance can ensure your client

00:02 → 00:05

satisfaction, and what comes after drives more sales.

00:05 → 00:07

You can achieve that by deciding on the cloud

00:07 → 00:10

architecture appropriate for the project needs.

00:10 → 00:12

Let me show you how to do it.

00:12 → 00:16

Hi, I'm Andrew, and I'm a DevOps engineer at Merixstudio

00:16 → 00:19

In this video, I'm going to advise you on choosing the best cloud

00:19 → 00:23

architecture solution and show you how your product can benefit from it.

00:23 → 00:26

Let's start by discussing the cloud technology provider.

00:26 → 00:29

The most popular are Amazon Web Services, Google Cloud,

00:29 → 00:30

and Microsoft Azure.

00:30 → 00:33

We advise our clients to pick AWS.

00:33 → 00:36

That's because it provides tons of ready to use services,

00:36 → 00:38

where they take care of standard monitoring.

00:38 → 00:42

Most of them can be easily set up for high availability.

00:42 → 00:45

What's more, backups are created automatically.

00:45 → 00:47

In the cloud, the application is spread across virtual

00:47 → 00:50

servers, minimizing the risk of downtime.

00:50 → 00:54

Providers manage availability and ensure very high uptime.

00:54 → 00:55

In case of updates,

00:55 → 00:59

servers can be easily swapped with fresh ones, for example,

00:59 → 01:00

latest security fixes.

01:00 → 01:02

AWS is the most popular solution.

01:02 → 01:04

It's great to build business from the bottom up,

01:04 → 01:07

as it provides countless ready to use solutions that allow you

01:07 → 01:11

to focus on what you want to deliver rather than how to.

01:11 → 01:13

It also means that millions of customers,

01:13 → 01:16

including the fastest growing startups, scale ups,

01:16 → 01:20

and established enterprises, are using AWS to lower costs,

01:20 → 01:22

become more agile, and innovate faster.

01:22 → 01:26

What's more, a lot of AWS services offer a free tier or

01:26 → 01:29

significant discount in the first tier of usage,

01:29 → 01:31

being a go to option for startups.

01:31 → 01:33

So now let me show you the perfect cloud solutions for

01:33 → 01:35

smaller applications.

01:35 → 01:37

It is often the best choice for startups.

01:37 → 01:39

Consider this schema if your application has low traffic

01:39 → 01:41

needs and you're on a budget.

01:41 → 01:44

It is also a great starting point if you don't have a clear

01:44 → 01:46

idea of what you need from an infrastructure,

01:46 → 01:48

as this schema can be easily expanded.

01:48 → 01:50

In this schema, we focus on the application itself:

01:50 → 01:53

emailing database, caching layer, media storage.

01:53 → 01:56

We take those from AWS as managed services to minimize

01:56 → 01:59

time spent on setup and maintenance.

01:59 → 02:01

Heart of the application is served using ECS,

02:01 → 02:03

Elastic Container Service,

02:03 → 02:06

a scalable solution working on Docker images.

02:06 → 02:09

This way we can easily scale our application horizontally,

02:09 → 02:11

allowing for more people to use our application.

02:11 → 02:15

At this point, we typically don't need to worry about the database or

02:15 → 02:18

caching layer, as we can always configure AWS to allocate

02:18 → 02:19

more resources for them.

02:19 → 02:22

But if you're scaling up your business or migrating to the

02:22 → 02:25

cloud with an existing complex application,

02:25 → 02:27

consider the second schema.

02:27 → 02:31

It's a solution for projects requiring high availability and flexibility.

02:31 → 02:35

It's also a good move when the application grows in terms of data.

02:35 → 02:37

You start to think about business intelligence tools.

02:37 → 02:39

You prepare resource heavy background tasks,

02:39 → 02:41

processing data that you collect.

02:41 → 02:45

At this moment, you want to have more flexibility within your application.

02:45 → 02:47

It shouldn't slow down the user experience,

02:47 → 02:49

so the obvious step is to separate resources within the

02:49 → 02:52

cloud to have more control over your environment.

02:52 → 02:55

There are a few differences in this schema compared to the previous one.

02:55 → 02:58

The main difference is that we start to account for AWS Region

02:58 → 02:59

Downtime.

02:59 → 03:00

In the previous schema,

03:00 → 03:03

we had set everything in one location to lower costs in

03:03 → 03:07

exchange for the risk of downtime in case AWS has issues.

03:07 → 03:10

Here, we duplicate application resources across two or more

03:10 → 03:13

regions to be able to keep the application fully online in

03:13 → 03:14

case of region outage.

03:14 → 03:17

Database as well as the caching layer has now replicas,

03:17 → 03:20

which can be triggered to become the main resources if

03:20 → 03:21

one region fails to serve.

03:21 → 03:25

We also spread our Elastic Container Service across regions.

03:25 → 03:28

In addition, you can notice that there are two ECS layers.

03:28 → 03:31

We create a second one purely for heavy background tasks,

03:31 → 03:33

so that they have their own resources to play with and the

03:33 → 03:36

end user experience is intact.

03:36 → 03:38

With the background tasks layer comes a queue.

03:38 → 03:40

It is used to push tasks scheduled for work.

03:40 → 03:43

The last noticeable change is CloudFront.

03:43 → 03:47

This AWS managed service allows us to use edge locations,

03:47 → 03:50

serve static media files faster to people all over the world.

03:50 → 03:51

Okay, so that's basically it.

03:51 → 03:55

I hope I've dispelled your main doubts about cloud architecture.

03:55 → 03:56

But of course, every project is different,

03:56 → 03:58

so if you still have some questions,

03:58 → 04:01

feel free to contact us and let's discuss your project.