DCHQ Seeks to Make Full Stack Deploy Possible
We are used to thinking of applications as just their code. But in order for communication to increase, bugs to decrease, feed the thirst for speed, and respond to security risks, the application needs to be considered as all of it’s moving parts. This includes infrastructure, system level configurations, and code. Full stack deployments are not a new idea in the modern delivery pipeline, but their execution is rare. Can DCHQ bring full stack deployments to the enterprise?
For small development shops full stack is easy. Especially when you consider that many of the recent applications are 100% platform as a service PaaS, which dramatically reduces the stack size. But this is still less common.Today most applications are run and deployed on IaaS.And most often that infrastructure is owned by IT solely, and fairly static. In the Enterprise especially. Which ultimately slows down everything.
In the last 10 years there is a lot that has been done to make full stack deployments possible. Virtualization, namely introduced the ability to templatize entire stacks with images, and deploy and destroy those images on a whim. And more recently of course, there is Docker. Who brings an even more rapid and compact version of the same thing.
The problem with Docker is that it lacks a lot of the management, networking, and oversight needed to take individual containers to an enterprise wide full stack deployment process. However at the same time without containers, full stack deployments would be severely limited.
Today DCHQ announced new functionality to their platform. Features that allow Enterprises to move in the spirit of a startup, and on-board the use of Docker containers without massive modifications to their processes and existing infrastructure. Even built, and run on Docker itself, the tool combines a web interface, and Docker containers that help control where instances are in the wild, what is running on them, their history, and allow updating the instances on-demand as needed.
But the latest release does one very important thing. It goes far beyond Docker Network functionality, and introduces a whole new set of networking features called Weave. Weave, essentially an SDN, will automatically connect via an agent to all new containers provisioned. Docker network functionality admittedly has been weak. And for now limited to containers only running on the same host, without a lot of manual effort to extend beyond that. To get beyond limited use cases, networking is something that must be addressed.
What is especially neat about how Weave does this is the the scripts are setup to know dynamically where the host is, and automatically all container variables. For example if you have a container running a node for your backend, and you need a connection string to it. You can reference it dynamically, without needing to look up the details of that instance.
Networking is nice, but it’s impact is even bigger. Because of Weave the container can live beyond individual host operating systems, even beyond cloud services and data centers! And because they have an on-premise version, this is an instant hybrid container solution. Granted you could do this all on your own with an independent SDN and associated management tool. But then you would not have the additional auditing and management capabilities DCHQ provides.
Enterprises do not drop everything and start over when they learn about modern development. But they still want to embrace the mentality of DevOps: more frequent and faster releases at a higher quality. And there is no reason they should be locked out. However most often the tools, aka Docker, do not directly facilitate their needs, so it will take tools like DCHQ to make it happen.
My concern about DCHQ’s new functionality is that it might encourage old habits. Allowing enterprises to forgo the steps necessary to build better communication and processes. This is because it is so easy to slip stream into existing ones, only now with containers. Really the enterprise doesn’t even need to know the containers are there.
I’m very happy with this trend of more mature Docker, and container driven pipelines. And in the next few years full stack deployments will be a must, if not for the security concerns around applications alone. Anything that makes full stack deployments easier is a cool tool in my mind.
