The choice between containerization, DevOps and cloud migration can freeze an IT department's attempts at modernization, because they weigh the technological options before they determine the goal.
Applications should be modernized whenever possible, but it is notoriously difficult to do. Enterprises complain that goals are too technical, business practices are negatively affected and costs overrun expectations. Application modernization projects often become a focus of technical tunnel vision, disconnected from what should be target benefits and from a way to unify and direct application architecture principles.
Good modernization projects arise from a drive to improve worker productivity, reduce IT costs and errors or both. The roles of continuous integration and delivery (CI/CD), DevOps and cloud or containers -- or containers in cloud -- are derived from the project goals, enterprise setup and application architecture.
CI/CD for all app modernization
Productivity enhancement means offering better IT support. The primary trends of app modernization don't directly affect things like IT integration with users' workflows or better functionality, but those trends should be applied to fulfill the goal. People are notoriously bad at projecting how useful something will be when they can't test and try it. For this reason, continuous delivery and continuous development automation practices should lead modernization efforts. This allows the architects to quickly adapt applications to operational experience.
Many enterprises find app modernization driven by CI/CD goals helpful in all cases because it reduces the time required to inject new capabilities into applications, thus improving IT support for business operations. Automating app updates via CI/CD sets up effective consideration of the other key IT trends: containerization, DevOps and cloud migration. However, CI/CD changes development practices enough that it could require an application redesign. It can also expose operations issues, particularly in ensuring that application component changes that affect deployment and configuration are rolled correctly into operations practices.
When cost drives modernization
Cost-driven application modernization projects have a troubled history in IT shops. DevOps adoption, containers and public cloud computing help reduce IT costs, but few enterprises have been able to lay out a strategy that considers all these options in parallel. Many end up focusing on the wrong areas.
To get cost-driven app modernization right, start with DevOps -- deployment and redeployment automation. If an organization already has DevOps methodologies in place, it might want to stay with the product set already in use. If not, there are a variety of prescriptive and declarative configuration management and automation tools available, including Chef and Puppet.
The key to DevOps success is to think in terms of operational states and application events, whether the chosen tool is prescriptive or declarative. Applications should have a small number of specific operating states, such as normal, heavy load or impaired. A set of conditions -- the association between application components, connections and hosting resources -- should be connected with each. The DevOps tool should either define the desired conditions or the steps needed to achieve them, depending on whether the tool is declarative or prescriptive, respectively. Application events are things that signal a change in operating state and thus trigger some DevOps activity.
Application states and events can also be critical to CI/CD; DevOps is likely the best second step in an application modernization project aimed at improving worker productivity as well. In continuous delivery workflows, DevOps has to reflect how new application features develop and deploy, which leads to a focus on how features map to software components.
For either productivity-benefit or cost-driven application modernization, a DevOps assessment will identify the actual elements that get deployed and redeployed, and this is where most modernization planners encounter the critical issue of application componentization. While componentization should be a key part of a continuous delivery strategy, it is possible to support CI/CD without restructuring applications. It's not possible to plan DevOps without app componentization.
This is one reason why DevOps is a lead-in to IT platform decisions around containers and public cloud services. Containers are increasingly tied to component and microservices techniques in development. Componentization is also critical to get the most from the public cloud, because components determine what application elements can scale under load or swap out in a failure.
How developers break up an app
Application componentization divides logic into small pieces so that the parts can be scaled and replaced easily. This benefit must be balanced with the cost and performance overhead associated with having work move through many small pieces as it's processed. Developers componentize an application with consideration of component reuse, which is an on-ramp to microservices adoption. By charting the workflow of an application, architects reveal the point where application front-end activity – per worker, by nature -- and application back-end activity -- transactional, with strong security and compliance requirements -- naturally divide.
Componentization is the only logical place to introduce microservices concepts into a modernization project and sets the boundaries for which components can be considered for microservices. Strictly speaking, microservices are maintained as fully independent elements: They cannot reference each other, nor can they share resources across microservices boundaries. This is critical because DevOps practices must enforce this level of component independence.
DevOps and cloud, container deployment choices
The way an organization uses DevOps for component deployment and redeployment, and the extent to which they deploy microservices, will identify where application modernization project planning should go after DevOps implementation.
Applications with distinct front-end and back-end structures that require considerable agility and resiliency could benefit from a split hosting setup: public cloud services for the front-end portion and containers for the back end. The IT organization must find cloud management tools that integrate the public cloud's front-end elements with the data center back-end platform. These should also be compatible with DevOps decision-making and handoffs. In the back end, container deployment options should easily integrate with the application and current IT operations. Maximize container-based scalability under load -- at least at the contact point with the cloud front end.
If security and compliance requirements tend to keep main processing in the data center, then consider containerization as your next application modernization step.
In whichever order you consider containers, public cloud and DevOps, it's likely that all of them will ultimately play a role in the modernization project. Every technological choice has to eventually accommodate the others and take IT shops to a single, optimized future. Don't get tunnel vision, but be sure you're looking ahead.
Traditional apps become containerization targets
Capacity management with containerized workloads
Migrate to the cloud without black skies
How much will it cost to run in the cloud?