Check out a free preview of the full Full Stack for Front-End Engineers, v3 course

The "Containers" Lesson is part of the full, Full Stack for Front-End Engineers, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jem discusses microservices and monolith software architectures, containers, how containers relate to cloud computing, and container management services.


Transcript from the "Containers" Lesson

>> Containers, the foundation of modern web applications. So, we talked about containers, they fit in the same bucket as microservices. If we talk about microservices and container. If you talk about how we orchestrate, all these containers together, then how do we balance out the connections going to all these different servers we just created, and how do we deploy all that?

Again, this is its own complex field. We're gonna cover it in a few minutes. So, we're gonna be just enough to be dangerous. Most of you have probably heard of the microservice architecture. It's a software architecture of loosely connected services. The opposite of the microservice architecture is the monolith, that's just one giant PHP file or one giant PHP repo, or Python and Django is usually a popular one.

You can do everything in Django or you can have a mix of both. You can have a monolithic connects to a bunch of microservices, things like that. The picture on the left is an old demo of someone made a Netflix or in a hack day showing all of our microservices connected.

This is many years out of date. So you see the complexity of way over here is the internet, about here is where my team owns, which is And it's really small. The names don't mean anything. They're just gibberish. But that's just the surface level. As you are engineers, we usually stay about here, when in reality we're learning through this course that there's a whole lot behind the things we do that we count on.

The pros and cons of microservices versus monolith. Monolith, it's easy to work in. It's one language generally. Everybody if you're working on the same repo, you know what everybody else is doing. There's not gonna be any large conflict generally, because you're all working in the same file system, same repo.

The pros of microservices are I can write a React application, you can write Angular applications, one can write an application in Java or Groovy. If we don't have to talk to each other at all, we can write applications in our own specialty. The downside of microservices is coordination.

If everybody's writing their own services in their own languages, with their own idea about what the API should look like, how do we get each other to talk to or how do we talk to each other in a way that makes sense? So, there's a trade off, it's that, like we said, Netflix freedom and responsibility, the same applies for microservices.

You have the freedom, but you're responsible for connecting to your partners as well. So, I won't say which one is better or the other. We see microservices becoming more and more popular because they're easier to reason about. We can have people at different levels of expertise. However, you do have to manage microservices, so there's no one size fits all.

The way we are able to create microservices is we use something called containerization. Similar to the concept of virtualization, but virtualization is slicing up a server specifically into these chunks, these distinct parts. Just like we bought our own VPS, Virtual Private Server. Hence, virtualization container goes a little bit farther and it says, hey, what if you have a service?

And we're just like, this is just like our service here, except we're only using a slice of it. And we're using NodeJS, MySQL, Nginx or without using MySQL, SQLite. But this is all one server. But what if instead of that, what if we just broke it up into each of these has its own microservice, its own container.

So now, instead of our server just running, NodeJS and Nginx in one block, it would just run a container that has NodeJS application, and Nginx is an entirely different application. That allows us to say update different things at different times, allows different people to work on different things without interrupting the whole system.

Just like every time we update our Nginx configuration, we had to restart this system which takes us down for a few seconds at a time. What if we can get around that by having a container with Nginx running? We update half the containers, the other half stay up and running.

Then when they're all updated, we just switch traffic over really quickly. And that way there's zero downtime. And these are kind of newer, newish concepts in the world of software engineering, like zero downtime and containerizations, things like that. And really, containers are the core besides virtualization of cloud computing, because now I can buy these VPSs, I can buy these chunks of a server that are running chunks of an application at a time.

And allows to scale out really, really well. And for a lot of people, it's hard to kind of wrap your head around this like why we need containers and virtualization but remember, somewhere like where I work at Netflix, we're running thousands of containers just for our website. We're running thousands of instances of our databases.

You scale all that out, it gets really, really complex. But it's so much more efficient than me creating 100 Ubuntu servers and setting them all up manually and doing the whole thing we just went through in the past couple lessons, that will be a lot of work. Why don't we just wrap it all up in instructions and that way, we have some layer that says it doesn't matter what operating system running on, your program is always going to work because it's just this tiny little container.

And that's what we're going to do today, we're going to create a container. And the great thing about containers are they don't care about what operating system you're running on. So, yeah, we're running on Ubuntu right now, but what if I want to run on OSX? What if I want to run on Red Hat or Fedora or something like that?

Containers can run on anywhere because they're operating system agnostic. It's up to that parsing layer. And for our instances, we use Docker. Docker's the big one you've probably all heard of when it comes to container management. There's also Amazon ECS, Apache Mesos, CoreOS rkt, etc. There's a lot of different solutions these days.

And I touched on this earlier, but containers are super lightweight. They only run the application that you need, nothing else. No other fluff. If they're portable, we can move them around from OS to OS. They're much easier for development, because you can just download my container image and you get up and running very, very quickly.

They're easy to manage. Because I think as we saw when we implemented web sockets and databases, the more things you have put together, the more chances something is gonna go wrong. So if you're only running one application, it's a lot easier to reason about when something breaks. They're faster to start up, because again, it's only that application.

And most importantly, we decouple the application from the infrastructure, which is really important. I've talked a lot about the paved road and saying we're using Ubuntu and Nginx and we're following this really tight path, which makes it easy for us to use other tools. But what if we can just decouple all that entirely, so it doesn't matter what the underlying infrastructure is, what our operating system is, we can just write applications that run anywhere.

That's why containers are really, really awesome.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now