One of the questions that often comes up to anybody who's in the cloud space is, what are the differences between virtual machines and container? When should use one versus the other?
Unfortunately the answer is not so simple clear-cut. We can't say you should always use containers or always use virtual machines. But, there are some things to keep in mind.
There are certain kinds of applications which benefit from running in containers or using micro services in general. Microservices means taking an application and decomposing it into smaller parts. This is really good if you need to build a web scale application and you need to have the ability to turn up different dials of performance somewhat independent of each other. For example, take the middleware piece or the front end or the database piece and you need to scale them individually. The other benefit of containers is a consistency between the development environment and the production environment where you can take things easily form one to the other without major alterations. That being said there are some things about containers that are very different. They're not just smaller leaner virtual machines.
Some of the biggest differences have to do with persistent storage. So, in a container needs to have the storage living outside of itself somewhere else. So, if you build an application in containers you need to have the database, that's the persistent part of the application living elsewhere.
The other part gives into container lifecycle management is that you don't patch containers. Because, there's no internal storage, there's no benefit to deploying a patch to the container to bring it down for a while and bring it up. Actually with containers when you have a new version of the container or you need to update it in some way, you actually replace it. There are some ways to do this involving, for example, orchestration tools like kubernetes. They can do rolling updates but the most important concept you need to understand is that when a container gets updated you actually kill the old container and bringing a new one. Because all the data is stored over somewhere else. It's okay to re-attach it to data and that's what get moving forward.
When it comes to think about it from a bigger picture you should ask yourself why do I want to use containers and what'll I benefit from it. In some cases, for example, a CRM application or a Marketing automation application that's used by a department may be easier to leave it inside of a virtual machine. Because it doesn't need to scale, it doesn't have a high rate of change and more importantly it will work on your existing infrastructure.
Containers really going to be beneficial when we have an application that's really important to perform at it's best and a high level of scale or that you're going to be updating it a lot because it's important to the business.
Unfortunately the answer is not so simple clear-cut. We can't say you should always use containers or always use virtual machines. But, there are some things to keep in mind.
There are certain kinds of applications which benefit from running in containers or using micro services in general. Microservices means taking an application and decomposing it into smaller parts. This is really good if you need to build a web scale application and you need to have the ability to turn up different dials of performance somewhat independent of each other. For example, take the middleware piece or the front end or the database piece and you need to scale them individually. The other benefit of containers is a consistency between the development environment and the production environment where you can take things easily form one to the other without major alterations. That being said there are some things about containers that are very different. They're not just smaller leaner virtual machines.
Some of the biggest differences have to do with persistent storage. So, in a container needs to have the storage living outside of itself somewhere else. So, if you build an application in containers you need to have the database, that's the persistent part of the application living elsewhere.
The other part gives into container lifecycle management is that you don't patch containers. Because, there's no internal storage, there's no benefit to deploying a patch to the container to bring it down for a while and bring it up. Actually with containers when you have a new version of the container or you need to update it in some way, you actually replace it. There are some ways to do this involving, for example, orchestration tools like kubernetes. They can do rolling updates but the most important concept you need to understand is that when a container gets updated you actually kill the old container and bringing a new one. Because all the data is stored over somewhere else. It's okay to re-attach it to data and that's what get moving forward.
When it comes to think about it from a bigger picture you should ask yourself why do I want to use containers and what'll I benefit from it. In some cases, for example, a CRM application or a Marketing automation application that's used by a department may be easier to leave it inside of a virtual machine. Because it doesn't need to scale, it doesn't have a high rate of change and more importantly it will work on your existing infrastructure.
Containers really going to be beneficial when we have an application that's really important to perform at it's best and a high level of scale or that you're going to be updating it a lot because it's important to the business.
Comments
Post a Comment