In some ways, cloud computing has been a victim of its own success. Cloud-based services and infrastructure became so popular and easy to adopt that many organizations ended up adding multiple cloud solutions haphazardly and disjointedly. In fact, much of the so-called “shadow IT’ phenomenon was driven in recent years by business units selecting and deploying cloud services with little or no input from their organizations’ IT departments.
Even as many enterprises – through design or default – have become multicloud users, however, most also continue to run many legacy applications that were never designed for cloud deployment. True, organizations have migrated some of those legacy applications from on-premises data centers to public cloud platforms, but the monolithic apps retain many characteristics and limitations that prevent them from exploiting the cloud’s full potential.
Burdened with complex digital estates that encompass a wide variety of legacy software along with a mixture of different cloud services, what are organizations to do? Many hope to modernize and rationalize their multi-faceted IT environments by moving to containerized cloud-native solutions. But how and where should they embark on such efforts?
In contemplating how to best proceed, it’s important that organizations understand that the adoption of cloud-native technologies doesn’t have to be an all-or-nothing proposition. Most notably, there may often be little reason – or budget – to take an existing monolithic application and recreate it as a cloud-native collection of Kubernetes orchestrated containers.
Instead, an IT department may determine that the best solution is to simply put a wrapper around the entire application so that it gains some of the portability and integration characteristics that the container model provides. Or, say, in the case of a three-tier Java enterprise application – consisting of an application server, a database, and a router – it may make sense to wrap and present each of the major elements as a standard container. In this way, each wrapped element can be modified and scaled as needed independent of the other tiers.
For some applications, including new applications built from scratch, the best approach will mean creating them as collections of containerized microservices that can be easily mixed and matched with one another, as well as independently updated and scaled. The challenge will often be determining which containerization strategies are the best for each application in question.
HCL Software faced this very challenge when it decided to pursue and promote a cloud-native vision five years ago. The company had a collection of existing software assets, and was growing its product portfolio via both internal development and acquisitions. About a year and a half ago, HCL began to develop a cloud-native maturity model to help it position different applications on the cloud-native spectrum and determine how to best move them forward to become part of the HCL Solution Factory (SoFy) containerized product portfolio.
Today, HCL’s battle-tested and refined cloud-native maturity model focuses on six critical cloud-native attributes:
- Cloud-native Platform Support
For each of these focus areas, HCL has identified three maturity levels, each with its own defined attributes. For example, in the Containerization area, maturity levels begin with the packaging of existing products, services, and APIs into containers, and ultimately progress to the use of non-privileged containers and single-process containers.
HCL’s cloud-native maturity model has given the company a standard way to create containerized products, as well as a framework for supporting its cloud-native development. Other organizations could gain significant benefits by adopting the model’s definitions and descriptions to guide their own cloud-native initiatives.
For information about HCL Software’s cloud-native portfolio, its maturity model, and its ability to help your organization realize the full benefits of cloud computing, visit.