How to eliminate complications in application operations

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 few of us is surprised to learn that the future will be containerized applications.

Another factor bringing on the change in how we operate with application operations is the notion of silos. What is meant by silos is the separation of development and operations. Even though current application operations seem to function, silos are a problem which has not been solved yet.

The lack of alignment within development and operations may lead to complications, which naturally can be solved but this may be costly and resource-intensive.

  • Typically, the objectives of the development department and the operations department are not corresponding.
  • Lack of communication between these departments may result in developers not being adequately familiar with the production environment and vice versa, with the department of operations not being acquainted with the developers’ release-cycle.
  • Potentially, the procedures respectively in the development department and in operations are not configured identically.

Consequently, these complications – and more alike – may result in costly and time-consuming activities for the company, which in the end may serve as the final drive for a new and innovative approach.

DevOps with containerized application operations

So how do we solve this problem? Well, as it turns out we 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 as Kubernetes or AWS ECS enables implementation of the DevOps approach in application operations.

What does this imply? From a basic stand point, 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.

In short, within containerized application operations the operations department is responsible for the infrastructure and the development department of the application. This brings on a set of advantages, namely:

  • Streamlined application deployment
  • Improved scaling of applications
  • Simpler management
  • Improved shared insight into the stack

Additionally, the operations of containerized applications function 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.

Next level advancement – RedHat OpenShift

As a result of the introduction of containerized application operations – for example by using Docker and Kubernetes – difficulties appear:

  • As mentioned, Kubernetes is Open Source and free of charge meaning no support is provided.
  • Lack of automatic pipeline to support fast turnaround from code commit to running container. Lack of integration may result in extensive turnaround time from commit to running container.
  • Disagreement between what the OS Container is based on and the Kubernetes is running on may cause inexplicable errors.

The solution to the complications is RedHat OpenShift, which replaces the part of the stack the infrastructure is based on. In other words: OpenShift is able to construct container images based on your source code, deploy the images and manage the entire lifecycle of the container:

We are well aware of what you are thinking right now. Generally, IT-specialists develop a habit to recommend products without considering the relevance of the products for your needs as customer. We promise you that we will do our best to avoid this.

However, in this case we will do it anyway. Partly because at present time there are no other products solving these difficulties and partly because the possibilities OpenShift provides compared to containerized application operations with Docker and Kubernetes are highly extensive.

Let us emphasize the most important: The only thing OpenShift is unable to manage for you is your physical and virtual infrastructure. This will continuously 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 OpenShift suggests 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. The predefined options are among others Apache Webserver and JBoss.

Is OpenShift the right choice for us?

At Netic we are genuinely excited about RedHat OpenShift. However, we do want to draw attention to the fact that containerized application operations and DevOps can function without RedHat OpenShift. However, choosing to exclude RedHat OpenShift may result in potential costs:

  • Lack of support. In a world of OpenSource the difference between a supported product and one which is not supported may make up a great amount of money.
  • Lack of an automated pipeline resulting in longer turnaround 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, which you compile your code on, caused by the 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 now. The teething troubles of OpenShift have been eliminated and it has by now been operating at an extensive number of customers enabling us to implement the most important customer feedback into the solution.

In addition, future operations of especially complicated applications will unquestionably be influenced by DevOps. IT-organizations will benefit greatly from the advantages DevOps bring on. 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 organizations have embraced the changes, DevOps can be implemented in a larger scale.

 

Please do not hesitate to contact us if you have any questions.