Let's talk quickly about how to containerize an app. To be clear, this isn't going to be a tutorial or a lab. I'm not going to walk through containerizing an actual app. However, I'll help you understand the big concepts around containerization and hopefully give you enough that you need to get started.

Containerizing an app isn't as simple as writing a dockerfile that includes instructions on how to get the whole app up and running in a container. I mean, you can do that. It's possible, but if you do, you're not going to get most of the benefits of containers. Containers work best when they're small and do one thing well. This means that you'll want an app to be made out of Microservices. Microservices is when your app is built in independent pieces.

These pieces might written in different programming languages, might have different dependencies. They might even run on different operating systems. All your services need to be written with APIs. This way any individual service can communicate with any other through their API. For instance, a database service exposes an API that let's other services request and write data to it. Then these microservices speak to each other over a network or often over multiple sub networks. Let's take a look at what this means. In an old school physical server, you'd probably be running a LAMP stack.

Each server is running Linux which is running Apache, MySQL, and either PHP or Python. Thus, you're OS, server and networking database and app are all running on the same physical hardware. In a modern, Cloud deployment, we'd split some of those things up. The networking and server functions are handled by the info structure and MySQL and your app are running on different types of Cloud instances, but your entire app might still live on one EC2 instance. For instance, if you're using AWS. In a containerized microservices app, things are split apart even more.

Each different part of your app runs in a different container, so your front end code is separate from your back end code. You might have a microservice that logs people into your app, and then a different microservice to handle communication between users, and yet another microservice to handle shopping and checkout. Microservices do not require containers. You could build out microserviced based app on AWS using EC2 instances.

Containers both make microservices easier and require microservices to get the full benefits from that. Why does your containerized app need to be built as microservices? A few reasons The first is that not everything can be containerized. Containers are designed to be spun up or spun down at anytime. They are ephemeral as opposed to persistent; however, most apps needs to have data that are persistent. You don't want your users to lose all their data every time the container they're on shuts down. You shouldn't be storing any data inside your containers.

The database software might run in a container, but the data has to be stored in a different volume. Another aspect of containers being ephemeral is that they should be stateless. If one container goes down, that should not effect your users at all because any information about their state should be stored outside of the app in data storage.

For instance, if a user is three steps through a five step purchase process and their container they're using goes down, their traffic should seamlessly be picked up by another container and should put them on the fourth step with their payment info, shopping cart, and everything else intact when they move forward.

The reason you want to design your app this way is that your microservices can be scaled horizontally. This means that when you have more traffic hitting your app you can simply spin up more of whichever services are getting a heavy load just like using a load balancer with a Cloud server instances. Just like in that case, your app needs to be designed in such a way that individual instances going up and down won't effect your users.

A place where containers may differ from physical and Cloud servers is that they should generally be immutable. This means that you never want to update your containers themselves. If you have new code to push, you want to do that by spinning up new containers with that code, putting those on the network, and then spinning down the old containers rather than simply pushing that code to the containers that are already running. If you design your app with ephemeral stateless containers in mind this should come fairly easily. It's more of a process change than a technical one. Immutability is a key concept of running containerized systems.

All of this is a lot to keep in mind, so there's a framework for building containerized microservice apps that a lot of businesses use. This is called the 12-Factor Application Framework. These are 12 principles that your app should always follow. It's a guide for how to build your app and what you're building towards. The factors suggest how to treat logs, how to expose microservices to each other, that you should keep your services stateless, and more.

It's a little outside the scope of this course to go through all 12 factors, but a Google search for 12-Factor App will give you a lot more information. Container companies like Docker explicitly suggest that the best containerized apps are 12-Factor Apps. That's what you need to know to get started containerizing an app. It's a large process that requires both technical changes to the app as well as process changes to the way your team works. As we discussed in previous lessons, once the process is finished you can reap many rewards.

Lectures