Sergey Galushko - Fotolia
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
Regression tests and UAT ensure software quality and both require a sizeable investment. Learn when and how to perform each one, and some tips to get... Continue Reading
Learn the meaning of functional vs. nonfunctional requirements in software engineering, with helpful examples. Then, see how to write both and build ... Continue Reading
Just because software passes functional tests doesn't mean it works. Dig into stress, load, endurance and other performance tests, and their ... Continue Reading