Mar 16, 2019 by Armory
Virtual machines or VMs create a copy of a computer system that makes it possible for a single server to host several VMs that each act as if it were a separate piece of hardware. VMs do not interact with other VMs on the same server at all—each VM is a self-contained unit and contains a copy of everything, from the operating system to libraries and databases.
Containers, on the other hand, share resources with other containers on the host system, including the operating system kernel and libraries. Containers are much lighter than VMs, and take much less time to start. This also makes it possible to pack many more applications into a server—hundreds or thousands of containers can run on a server, while only a couple dozen VMs can run on the same hardware.
Crucially, though, VMs and containers are not an either/or choice. Containers can run on bare metal or on top of VMs, so there are plenty of deployments that use both as part of the overall stack.
Containers offer a number of benefits over running directly on a virtual machine. First of all, containerized applications are portable, and can move between cloud environments or back on to an on-premise datacenter, helping companies avoid vendor lock-in.
Using containers also facilitates building a CI/CD pipeline, releasing more frequent updates and creating repeatable deployment processes. This is possible because of container’s lightweight, agile nature, because each container contains much less code than if updating an entire VM and because containers run in exactly the same environment at every stage of development, so there’s little risk that a containerized application will work perfectly in development and then fail in production.
There isn’t one flow-chart to tell you how to move an application from a virtual machine to containers, because the exact steps will depend on your individual application—does it have state? What are the storage requirements? What about security? Is it being deployed on a public or private cloud?
However, there are two general strategies for containerizing workloads. One involves taking the VM-based, monolithic app and strategically breaking it apart into microservices, then packaging each microservice in a container. This is the ideal way to move forward, but requires more work re-architecting the entire application and isn’t always practical for large enterprise applications.
Secondly, you could package the entire application in a container and deploy the app to a Kubernetes cluster in a ‘lift and shift’ operation.
Regardless, there are a number of problems to solve, most of which do not have one-size-fits-all answers. Here are some examples:
As you start preparing the actual code for a container-based system, it’s best practice to follow the 12-factor principles. These include:
Once you’ve solved those puzzles, there are other containerization best practices to consider—each container should only do one thing, you should embrace automation whenever possible, take steps to avoid cloud clock-in and, of course, continuously test and deliver.
Containers are necessary to take advantage of continuous delivery platforms like Spinnaker, and to work towards continuously improving applications. They help companies ship better software, faster.
Introducing Quick Spin One of the most common challenges that organizations face when implementing a continuous deployment strategy is the time and focus that it takes to set up the tools and processes. But a secure, flexible, resilient and scalable solution is available right now. Want to see if it’s the right tool for your […]
Read more →
Spinnaker is the most powerful continuous delivery tool on the market. DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]
Read more →
Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]
Read more →