Application operations have long been a task based on the same formula. Considering the level of effectiveness of this formula and the fact that it has been tested thoroughly, you would be surprised that people even consider changing it.
Yet, there are several factors indicating that a change in application operations is essential as the future brings radical changes.
The predominant factor is development. New technology has been developed, and by now probably only a few would be surprised to learn that containerized applications is the future.
However, there are other factors indicating that the way in which companies operate applications will change. Even though current application operations seem to function, there is one unsolved problem: Silos - the separation of development and operations.
A lack of alignment between development and operations may cause challenges which of course can be solved but this may be a costly and resource-demanding process.
- Typically, the objectives of the development department and the operations department are not corresponding for which reason the two departments are only concerned about their own success.
- Lack of communication between the two departments may result in developers not being adequately familiar with the production environment and vice versa, with the operations department not being familiar with the developers’ release-cycle.
- Potentially, the procedures in the two departments are not configured similarly.
Consequently, these challenges – and more alike – may result in costly and time-consuming activities for the company. Someting that might end up as being the major incentive for a new and innovative approach.
DevOps with containerized application operations
So how do we solve this problem? Well, as it turns out we have actually already solved it. We came up with a solution a few years ago concerning the use of containers. Using containers and efficient orchestration engines, such as Kubernetes, enables implementation of the DevOps approach in application operations.
What does this imply? Basically, DevOps are just a closer collaboration between the departments of development and operations. However, using DevOps creates clearer defined boundaries as to which tasks belong to which department, optimizing the correlation of work processes.
As for containerized application operations the operations department is responsible for the infrastructure and the development department for the application. It's that easy. This brings about multiple advantages that might make things easier for both the operations and development department:
- Streamlined application deployment
- Improved scaling of applications
- Simpler management
- Improved shared insight into the stack
Additionally, the operations of containerized applications work wherever you want workloads to appear. On-premise, hybrid or public cloud with scaling both in and out. If Kubernetes, the orchestration engine is even free and based on Open Source code.
One step further - Rancher
With the introduction of containerized application operations, for instance with Docker and Kubernetes, a number of challenges occur:
- As mentioned, Kubernetes is Open Source and free of charge hence no support is provided.
- Lack of integration with code commit - for instance GitHub. Lack of integration may result in extensive turnaround time from code commit to the final container.
- Containers might be built on another base OS than what Kubernetes is running on.
The solution to the challenges is Rancher's suite of open-source, which replaces the part of the stack placed on the infrastructure. In other words: Rancher is able to build container images based on your source code, deploy the images and manage the entire lifecycle of the container:
We know what you are thinking right now. Generally, IT specialists recommend products without considering their relevance for the needs of the specific customer. We promise you that we will do our best to avoid this.
However, in this case we will do it anyway. Partly because the possibilities Rancher offers in regard to containerized application operations with, for instance, Docker and Kubernetes are highly extensive.
Let us emphasize the most important: The only thing Rancher is unable to manage for you is your physical and virtual infrastructure. This will continue to be in the hands of your operations department. The rest is taken care of by the development department enabling them to handle all tasks by using single-pane-of-glass.
In addition, the tasks are easier as Rancher offers several preconfigured options in its service catalogue. These options simply have to be checked off when building a new container – but don’t worry, we offer complete CLI-support.
Is Rancher the right choice for us?
At Netic we are genuinely excited about Rancher. This is no secret. However, we do want to draw attention to the fact that containerized application operations and DevOps can work without Rancher. Though, you should know that choosing to exclude Rancher might bring about potential costs:
- First, lack of support. In a world of OpenSource the difference between a supported product and an unsupported product may make up a great amount of money.
- Lack of an automated pipeline resulting in longer turnaround time from code commit to final container.
- More circumstantial administration and management
- Potential sources of error (*)
(*): An example of a source of error is discrepancy within those glibc libraries, you compile your code on, caused by differences within base OS for the container and the OS Kubernetes is running on. Ultimately, such discrepancy may lead to container crash.
Well, is the technology then fully developed? Yes, it is. The teething troubles of Rancher have been eliminated, and it has been running long enough for the most important customer feedback to be implemented into the solution.
In addition, future operations, especially of complicated applications, will unquestionably be influenced by DevOps. IT organisations will benefit greatly from the advantages DevOps brings. This is the predominant reason why Netic recommends starting now. Acting now will enable technologies and methods to be phased in during an appropriate time period and gradually when organisations have embraced the changes, DevOps can be implemented in a larger scale.