Enterprises are once again faced with a major shift in the application development technology landscape. And, once again, it appears that adopting this technology correctly is imperative for business success and growth. In the two previous installments in this series, we looked at two technologies that are at the core of the “new” development model, container technology and micro-service application architectures. We covered these because they are the model by which most developers are effectively using container techniques today. For Enterprises, this may have a major impact on the ability and decision to leverage containers, and we’ll explore this concept in this installment.
Why Enterprise Applications are not “Container Ready”
When one talks of deploying Enterprise Applications, regardless of the underlying software development technology, there is often an expectation of the capabilities needed to support such an application. For the most part, these expectations can be collapsed to include external security support in the form of a firewall or VPN service to restrict and control access, and resilient infrastructure including redundant network and storage access, replicated and backed up “enterprise grade” storage, and often external redundancy services such as server load balancing support. And the resiliency and redundancy support wasn’t there to support horizontal application scale, rather it was assumed that scale would happen principally by increasing the capacity of the individual hardware components.
Much of this infrastructure in the past was also manually configured as well, leading to much of the cost associated with the deployment of these applications. When one then also looked at the application deployment and management services, a similar overhead is often found, in that the application assumes a certain environment, and is built with the assumption that other aspects of the service will handle much of the reliability aspects of the application, so that was never part of the application development paradigm.
What does a Container Ready Application Look Like?
When we then contrast this picture with that of the container infrastructure and management paradigm, we see that there is a fairly large impedance mismatch. In our first installment in this series, we covered a bit of the history of containers and how the container model (as it exists today) was built and tuned to support horizontally distributed application architectures that were being built on non-resilient infrastructure (to manage overall system cost). This is a bit at odds with the requirements of most enterprise applications from the architecture perspective. In addition, these distributed applications were good candidates for the microservice architecture, fitting again as well as one would expect with the concept of packing/distributing/and managing these applications in a container space.
Migrating an old Enterprise App to new Container Infrastructure
So the mismatch between enterprise and “web scale” applications is clear, but this doesn’t mean that an application can’t be implemented in a container world, or even better be morphed into a micro-service architecture model over time. Firstly, there’s the question of resilience vs. the potentially unmanaged nature of the container deployment model. There are a number of solutions that now exist to support the operations of a containerized application, from the service management and scheduling now available in all of the current container management and orchestration tools (Docker-swarm, Kubernetes, Rancher, Mesos DC/OS, etc.), to more complete cloud level management services that look at multiple applications in the same way that the container orchestrators look at individual applications (Docker-cloud, Ubernetes, Rancher cloud, Mesos DC/OS, etc.). This can help manage the disconnect between the initial system architecture’s expectation of reliability, and the actual model within most container environments.the mismatch between enterprise and “web scale” applications is clear Click To Tweet
Another aspect is that of storage, where a re-architecture may be required. Container services can map to persistent storage, but the model tends to map more directly to a shared/distributed model, rather than the direct connected model of the past. This is principally due to the simpler resource placement schedulers that don’t restrict the placement as tightly as would otherwise be required, and at least today do not support automatically mapping direct attached storage paths beyond those mapping to a local file system location. This means that some aspects of the application (such as a high performance database) may be better deployed on an alternative infrastructure, such as an IaaS cloud or even dedicated infrastructure until the data services can be mapped to the tools available in the cloud space.
The Critical role of (REST) APIs
With the basics of the infrastructure resiliency managed, or mitigated for the near term, it’s possible to look more directly at the application. Applications that have made use of the RESTful model for client interaction are already ahead of the game in enabling containerization of the application, and those that haven’t used these models, can often be migrated, so long as the client application doesn’t expect an always available static connection to the application service. It is these sorts of applications which will require significant rework to be able to map to containerization, and may in many cases be better suited to being re-developed or having a major refactorization effort applied to better fit with the models behind containerization of applications.
Applications that are RESTful in their interface, have horizontal scaling as a part of their architecture, and preferably have a segregated but distributed storage service (e.g. a separate database service) are the best candidates for enabling containers in the enterprise. Other applications can be containerized, but only if they can be managed in a way that addresses the inherently unstable nature of the container environment. In many cases, a refactorization of the application can enable a container based deployment workflow, and in doing so, will enable the development teams to build and package at the container level from the beginning of the migration effort.value (of #containers) lies in the longer term ability to move applications and application components into service layers Click To Tweet
The real value of containers is not just the fact that for many the seem to be a new and exciting way of packaging and delivering applications. Rather the value lies in the longer term ability to move applications and application components into service layers from which additional applications can be derived without having to rebuild the entire infrastructure layer. This is the promise of the micro-services architecture concept, and the supporting operations and deployment services built around the concept of containers.