Learn how and why we build net new container-based applications.
So as we talked about earlier, not all applications should exist in containers. Not all net new applications should be built using containers even though it's tempting because it's new technology out there we think it's cool. We're taking a container course and therefore we like to use the knowledge at some point. However, you have to kind of pick and choose your battles in the world of containers. So they need to be designed from the ground up. For containers, that's an advantage and a disadvantage. In other words, you have to take the time to sit down and do an application design to insure that the containers are going to be in good shape and are going to be designed and structured to leverage the best of containers.
They have to be efficient, they have to be distributed, access to data is a bit tricky in containers, as we'll see in a later slide. We have to deal with different security parameters, different tool sets, things are typically new. There are not a lot of people out there who know how to design containers correctly from the ground up. Advantages are a truly distributed application that leverages components in isolation. That's what containers are. The fact of the matter is that we've been building distributed objects and we've been building component-based development for years and those are kind of distributed applications we've been doing using needed features of the particular platforms, and certainly in clouds and containers really standardize that.
They provide us with a truly distributed application that leverages components and they're isolated so they can operate on their own. Scaling provided by orchestration tools so we have tools that such as Docker or Swarm, and Google Kubernetes, and Mesosphere, which is from Apache, that allow us to scale to any number of processes because we're able to orchestrate the use of containers in clusters. And those are really, really important as you'll see later in the presentation and in the course.
Portability can be exceptional, obviously, with containers, so we're able to move them everywhere which is very cool. And we've had this before with, certainly, Java and J2EE, things like that. People want to write to portability, however, there is a trade off that you may be missing some of the native features by writing applications, in this case containers that are portable. However, in Docker I think they've mapped that to the various native capabilities of the runtime operating system that sits in the platform so it's able to take advantage of the native features of the runtime platform even though you're writing to a portable layer of extraction.
Disadvantages, it costs more. You're not going to build a container-based application cheaper than you can without containers. So it's going to add additional money in terms of skills, and tools, and time, and things like that, cost of risk, all that comes into play. It's more complex. You're dealing with complex tools as we saw in the previous section and they have to be accounted for, and they have to be manipulated, and they have to be understood. And lots of things need to occur well and work well at the same time in order for you to get the containers up and running.
Support can vary, but getting better. And so, these are new stuff so we have supports in the Docker world since it's an open source world and lots of people are contributing to it. There can be bugs, there can be support issues, things like that. Mainly things you'll do wrong because it's new technology but you're dealing with brand new technologies. It's not very old, so we have a shakedown period typically with that stuff. We're not at the fourth or fifth generation yet, we're at the first.
- Containers vs. virtual machines
- When vs. when not to use containers
- Building new apps with containers
- Moving existing apps to containers
- Example container applications
- Standards, tools, processes, and skills