Business practices and technology tools change over time, often radically. Applications that support business practices with technology tools often change too slowly, and application modernization is all about bringing things up-to-date. Container technology is certainly one of the most important new technology tools, and refactoring applications to use containers can also make them more responsive to business needs and more agile in addressing business and technology changes in the future. Start by laying out a modern application model, link it to enterprise architecture models of business evolution, and implement it using front- and back-end, containerized software structures.
At the business level, a successful application modernization roadmap is based on improving the worker interface with company data and applications. At the technology level, most are designed to better exploit the inherent resource elasticity and availability in virtualization and the cloud. Your own application modernization roadmap should accomplish both goals, and that starts with organizing applications into workflows that have a distinct presentation front-end and processing back-end structure. This focuses application improvement where it can be seen, and it also prepares your application for componentization.
At the front end of an application, processes focus on supporting the GUI and the worker, and, thus, should scale easily under load and be easily replaced in the case of failure. Further back, transaction processing tasks tend to be serialized by the need to maintain a database, and so replication and replacement are more challenging. Your goal in app mod is to divide your applications to focus the things that can't be easily replicated in the back-end processes, making forward processes free to scale.
Containers can be of enormous value in framing how this division is implemented. Scaling of processes within the same container host, or within a container cluster or "hive," is easier because there's little overhead in spawning multiple copies using containers, and because the process of load balancing and managing quality of experience (QoE) is easier when the instances of a component are kept close.
Zoning app mod behaviors
Most applications, seen from the "front" or GUI side, will have three zones of behavior. In the first, the focus is on presentation, basic format/structure editing and reformatting of information for later processing. This zone requires very little in the way of stored data resources, if any, and so it can be pushed far forward toward the workers and replicated as needed. In fact, this zone is a perfect candidate for public cloud deployment of containers.
The next zone back is where data-driven validation of fields is applied. Here it may be necessary to reference static tabular data for validation (zip codes, states, structured transaction information, etc.). The goal here in container deployment is to think in cluster terms. Clusters should be defined so that all hosts in a given container cluster will have comparable ability to access tabular data resources. That means that replication of processes in this zone won't impact data access performance and QoE.
Cluster planning can pay huge dividends when planning for the connectivity of your container deployments. If application components are assigned to clusters that have been previously connected, and if you manage subnet assignment by application within those clusters, you'll need to do very little beyond the normal container networking steps to establish application connectivity across all the components and with your workers.
The back end of an application is where actual transactional updates and access to core databases take place; therefore, this part has to be run where the data is readily available. Where possible, structure your back-end zone components to do as little as possible beyond their prime database functions. Other related activity that's not directly accessing a database should be pushed forward into the middle zone so it can be more easily replicated in response to increased workloads.
Often, there are multiple repositories of data associated with core applications, and where different applications need different data resources, it's smart to host them in separate clusters and provide the cluster with a common data access capability. Again, policies for component scaling can then add capacity at the processing level without altering the data path much, which makes controlling QoE much easier.
Using container-based app mod
All of this points to cluster-driven planning of a container-based application modernization roadmap. You can start in your data center where the primary data is stored and define one or more clusters there to host the back-end elements. The middle-zone components can also be hosted here -- either as a fall-back resource or as the primary hosting point -- but it's best to create clusters closer to, at least, those workers who are geographically separated from the main data center. Those secondary clusters can host the middle-zone elements and, at the same time, back up even further-distributed clusters that could be in local offices or the public cloud.
Containers should also drive the app mod development and testing process. A properly structured and orchestrated container cluster is a virtual, portable element. That means you can build them to develop and test applications in a very close approximation of your production deployment. With a little care, you can make the two almost identical and improve development efficiency at the same time.
Almost any interactive development environment can run in a container, which means that every developer can be given a container or even a mini-cluster for development and unit testing. Integration teams can then assemble the tested components in another container set, and since container overhead is very low, this multiplication of virtual hosting environments won't be excessively costly.
Containers should be a fundamental part of any enterprise application hosting strategy, and adopting them not only facilitates an application modernization roadmap, but it prepares your IT environment for the future. As always, getting started correctly is critical, so make sure your app mod model is solidly grounded in containers when you start. That will preserve the greatest flexibility in your future application deployments.
Top five .NET framework features for app mod
The best application modernization for your business
Look to middleware for modernization apps