IT professionals can generally evaluate applications based on factors such as the complexity of the code base,...
the number and location of configuration files, the location of related data files, network protocols, installation complexity, licensing and so on. The more complex and distributed each of these factors is, the more difficult it can be to deploy containerized applications.
A single-process code segment that's completely isolated from other code and uses a single configuration file would be a good fit for containers. It should also employ data files from one location and use standard network protocols, such as HTTP/S. In addition, it should support simple installation packages, like .rpm files or direct source code, and it should be distributed freely via open source licensing.
In general, it's relatively easy to compartmentalize and deploy containerized applications that are cleanly divided and straightforward, such as web-based, stateless applications. For example, applications like Apache Tomcat web server or MySQL can be containerized.
By contrast, application code that drives multiple processes, uses multiple configuration files, relies on data saved in multiple places, employs more demanding network protocols -- such as TCP or UDP -- demands more complex installation and touts proprietary licenses can be far more difficult to containerize. For example, applications that require Payment Card Industry Data Security Standard compliance through network isolation, big data workloads, advanced network routing and non-HTTP/S protocols might be suitable for container-based deployment -- but will pose more difficult challenges.
At the far extreme, self-modifying code bases with configuration and data files distributed throughout the file system, dynamic certificates, highly secure or isolated network protocols, like IPsec, complex installation and restrictive vendor licensing can become extraordinarily difficult to sort into containers. For example, ERP, customer relationship management, legacy COBOL and other highly proprietary applications could prove impossible to effectively containerize at this time. Such applications may need to be redesigned and rewritten to support containers.
Still, this is just a general assessment. No two applications are alike, and some applications may respond to containerization better than others. Fortunately, containers make it easy to test application deployments, so IT operations staff and application stakeholders can experiment with a container-based deployment in a lab environment. Testing allows staff to gather performance metrics and evaluate the difficulty, performance and management implications of a container deployment. Once metrics can be objectively evaluated, business leaders can make an informed decision about whether or not to deploy containerized applications.
Overcome networking challenges with Docker deployments
Increase application portability with a PaaS model
Simplify cloud application development with containers
Dig Deeper on Application virtualization
Related Q&A from Stephen J. Bigelow
IT administrators should familiarize themselves with the benefits and limitations of using nested virtualization to run containers in VMs before ... Continue Reading
Many issues cause VMs to become unresponsive, including invoking particular tasks, such as snapshots or migrations, resource configuration and ... Continue Reading
There are many potential causes of network performance problems when it comes to VMs. Familiarize yourself with the most common causes to aid in ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.