Containers are all the rage, but many organizations are still hesitant to make the transition from servers and VMs to containers. Depending on which stat you read, container adoption today stands anywhere between 25% and 52%.
Either way, this means at least 50% of organizations are still working to make the shift to containers. Your organization may be one of the many that have been quietly (and skeptically) observing all the buzz, and waiting for the opportune time to jump on the container bandwagon.
If this is you, you may be wondering when the time is right to make the shift. Here are some ways you can tell…
1. A checklist of warning signs
“If it ain’t broken, don’t fix it” is often the motto of IT teams with too much on their plates. If you’ve not made the shift to containers yet, you probably have this mindset, too. For any change to happen, you need to first realize that the setup you have right now is not working. If you run all your applications on hardware servers or VMs today, it’s likely your apps are closely tied with the hardware, innovation is slow, and you’ve seen indications that this model isn’t working. But perhaps a checklist of all the warning signs will help you see the full extent of the problem you face. Take a moment to go through this checklist and tick off the number of issues you currently deal with in your organization:
- Developers duplicate their efforts.
- Testing is always last-minute.
- Low test coverage
- Testing is mostly manual, slow, and error-prone.
- QA spends a lot of time waiting on Dev for “finished” code to be tested.
- Code goes back and forth between Dev and QA to fix bugs.
- Releases are always delayed.
- You release every month or quarter, and want to release more frequently.
- You discover most bugs after release.
- Dev blames Ops for a lack of innovation.
- Ops blames Dev for a lack of reliability.
- You want to bring portability across the pipeline so Ops deploys exactly what QA tests, which is what Dev built.
- Your infrastructure crumbles during traffic spikes.
- Your organization has decided to go mobile-first.
- Product features are restricted by engineering and Ops capabilities.
- You’ve been a victim of a data breach, and the attacker had easy access to your system.
- Your infrastructure costs are hitting the roof.
- Your competitors are already leveraging containers.
- You want to bring uniformity to the toolset your developers use.
- You want to modernize your legacy applications and databases.
This list covers the entire SDLC, and every team involved in software delivery. As you can guess, of the 20 points here, the closer you are to 20, the more likely you need a shift to containers.
You can ignore these warning signs and continue the way you always have, but over time, these issues will only escalate, and have bigger consequences. On the other hand, doing something to change will pay off in many ways. Containers help solve issues at every part of development.
2. You’ve begun moving to the cloud
Most organizations today run hybrid infrastructure setups—They have an in-house data center, and leverage one or more public cloud platforms like AWS. If you still operate exclusively on hardware servers that you maintain, you have more to gain by moving these workloads to cloud-based VMs like AWS EC2. A sudden switch from servers to containers may be too drastic, but VMs in the cloud make a perfect segue between hardware servers and cloud-based containers.
Additionally, the tooling around cloud VMs is very mature today, and is easier to manage than tooling for containers. Some tools like Jenkins for CI or a test automation tool like Sauce Labs are common, whether you use VMs or containers. However, most container tooling today is in a state of rapid evolution, and it can be overwhelming if you dive right into containers from running an in-house data center.
If you already use the cloud, you know the benefits it brings you over traditional hardware. These include ease of use, cost savings, scale-out elasticity, lower maintenance and management, faster setup times, and on and on. But containers are better than VMs in the cloud in all these ways and more. If you already run some workloads in the cloud, and are happy with the results, you should go further and adopt containers. It’s just the logical next step in the evolution of your infrastructure.
On the other hand, if you’ve not yet adopted the cloud, the best approach is to identify a few quick wins you can achieve by moving some of your workloads from hardware servers to VMs in the cloud. Pick a leading cloud vendor like AWS or Azure, and become familiar with all the tooling in their platform. This is an important step in your journey to eventually running your applications on containers.
3. You’ve started to adopt a DevOps culture
Changing your infrastructure can make a big difference in how you build and ship applications, but to truly make progress, you need to change the development culture you foster in your organization. Traditional development models like Waterfall result in bottlenecks at every step. As an alternative, organizations have found that a modern approach like DevOps results in huge gains. DevOps aims to bring together Dev, QA, and IT teams in a collaborative approach to software development. It focuses on faster releases, which are made possible by automating tasks at every step of the development pipeline. Rather than having large siloed teams, DevOps encourages small cross-functional teams that each manage one section, feature, or service of a larger application. DevOps is first a change of culture, then a change in people (or teams), and finally a change in tools. Bringing in this cultural change in your development organization is foundational if you want to adopt modern technologies like containers.
Adopting containers is a journey. It starts with seeing the warning signs that your hardware server setup or VM setup isn’t working, and you need more agility, speed, and reliability in your software development. (Use the checklist above as a guide.) Apart from this, two steps that prepare your organization for the transition to containers are first a transition to the cloud, and then adopting the DevOps model of software delivery. If you already build applications in cloud VMs using the DevOps approach, even if you don’t do it perfectly well, your organization is ready for containers.
- Container Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog
Twistlock 18.11 Release NotesRead the Blog
5 Questions to Ask When Choosing a Cloud Native Security Platform for DevOpsRead the Blog