The innovation in the field of app development and app delivery has been progressing at rocket speed in the last few years. The revolution started with the shift from monolithic app architectures to microservices app architectures, initiated by Netflix in 2010, even before the term microservices was officially coined in 2012 and popularized by Martin Fowler in 2014.
After the advent of microservices, entered containers, simplifying the packaging of microservices, and then came Kubernetes which revolutionized the way container applications are deployed, orchestrated, and managed. While all these solutions helped boost digital transformation across the world, they also brought in higher levels of complexities for developers as well as the IT guys.
Many digital companies were fast to catch on and started figuring out ways to hack their way towards efficiently deploying and managing applications on the cloud using Kubernetes. But, despite all their efforts, the wall of confusion between the developers’ teams and IT teams kept on growing. As Kubernetes cluster management and container deployment brought a lot of complexities and a steep learning curve to the table, the expertise of both teams became disjointed from each other.
Thus, maintaining a smooth flow of ideas while working in an agile quick-paced way became difficult. As the gap between the two teams grew bigger and bigger to the extent that they started throwing things back and forth over the wall of confusion, it was more and more obvious that there was a need for a new methodology of working. This gave birth to new ways of working where there is a smooth flow of ideas while working in an agile quick-paced way with continued coordination between teams.
Kubernetes with DevOps
It is understandable that as tools and software we use to build applications evolve, the ways of working with them have to evolve as well. The DevOps methodology of app development and delivery helped fulfill this purpose. When teams were faced with the complexities of Kubernetes, they quickly turned to DevOps to deal with those. It helped increase agility and stability in app delivery to Kubernetes and its management. The DevOps methodology enabled the development and IT Ops teams to work in tandem throughout the entire app service lifecycle. This further led to the addition of new concepts like GitOps as well.
This surely bridged a lot of gaps between both teams but not completely. Despite a very well-structured way of working, the Operations team constantly found themselves overburdened with putting out multiple small-scale fires and were left with no time to work on their own tasks.
The DevOps team was, in principle, meant to manage the cloud infrastructure, monitor Kubernetes clusters, and build tools to enable developers to meet their SLAs. But in reality, they would run around trying to solve every tiny problem occurring during deployment. A lot of these problems would occur at the application level which the DevOps team cannot solve on its own and the developer team, having no idea about the deployment process, is incapable of solving without the assistance of the DevOps team.
Applications sometimes have dependencies that operations don’t know about, and are only discovered at deployment time. This happens because these dependencies are usually communicated through auxiliary channels (most likely a ticketing system) and developers often miss out on listing down everything there. It can be either because they just forgot about it or assumed that some specifics are not important enough to be communicated separately. Even if all the specifications are mentioned in detail by the developers, they frequently underestimate the quantum of work the DevOps team will have to put in for those particular deployment specifications. Often applications are written on a developer system that is significantly different than the production environment, leading to discrepancies which again are only uncovered when the app needs to be released. This also means that there are always unknown risks in bringing an app to production.
Thus, the present situation, though a lot better than before, is still not an ideal one. Both the teams are still constantly looking for hacks to fill in the gaps of understanding between them. DevOps methodologies have surely helped teams evolve in their ways of working with new platforms and software while collaborating efficiently. But these methodologies are not efficient enough to meet the ideal expectations of efficient collaboration. After a certain point, a lot of effort and costs are wasted while trying to further improvise DevOps.
The major challenge of maintaining stability and security while making the applications cost-efficient is a tough one to defeat with just DevOps as we look at it now. While the traditional view of DevOps is very efficient, we need to take a look at a specific portion of DevOps as a separate entity — AppOps.
Enter AppOps - The App-centric approach
DevOps has people, processes, culture, and tools at its center but tools have not been given their due importance. This has to do with the history of technical evolution. At the time DevOps was propounded, there were no tools that were mature enough to make developers self-dependent. The DevOps team was supposed to build these tools as they have the required domain expertise for it. But, they ended up building self-serve tools for themselves. These tools are too complex for developers to understand as they require domain knowledge of DevOps and were used only by the DevOps teams to aid secure and fast app delivery.
With time, the technical complexity of development has also increased. So, to keep up, the developers are either forced to learn Kubernetes along with the new technologies or keep on relying more and more on the DevOps for delivering their applications to the cloud. This increased the burden of the DevOps team and they are constantly misunderstood to be the bottlenecks of the app delivery process. On top of all this, the DevOps team has to spend a lot of extra time debugging the errors occurring solely due to some misunderstood changes done by the development team. When in reality, the bottleneck is the difference in the point of view of both teams.
AppOps offers the tools to enable self-service of application management and operations for developers. It helps the operations team build the guardrails within which developers can operate and thus, streamline application analysis, deployment, and management. It helps simplify how the DevOps team oversees app delivery and management while enabling developers to build, deploy, and test their applications without their help. In short, the DevOps team is no longer putting out small fires. They focus on larger concerns of cloud infrastructure management and Kubernetes cluster deployments.
AppOps removes the wall of confusion through a platform which DevOps can enable developers to "operate what they build" through a self-serve platform.
The idea of AppOps is to bind the components of the application and infrastructure together through tools so that developers can optimize the stability, cost, and security of applications running on top of Kubernetes within the guardrails provided by the DevOps team. The AppOps methodology says that one requires essential tools to bind people and processes together and help them collaborate efficiently and effectively.
AppOps: How?
As mentioned before, imagine there is a platform through which developers can deploy, manage and operationalize applications. If the application fails to run, they can pull it back, debug it and make all the required changes and deploy it again. Thus, the developers are now completely in charge of what they build and deploy instead of being dependent on an external team. This helps developers test their applications in production and create an internal feedback loop.
The operations team will focus on adding the prerequisites required to run the portal and providing the guardrails for the developers to be able to work independently. The portal enables the ops team to have complete visibility of the deployed apps. They can make or revert changes if and when required or even take control of the whole deployment process if the need arises. They will ensure that all the prerequisites required by the developers to deploy their applications are specified and built beforehand or make provisions to let the developers enter all their specifications by themselves.
The developers can take care of all the ad hoc requests that they needed the DevOps team to address allowing the DevOps team to work on higher-value tasks.
This way, the operations team is not constantly chased by the developers to deploy or debug their applications. The developers are no longer dependent on the DevOps team for handling all their deployment needs. They can operate and build as they want to within the provided guardrails.
With such a system in place, the feedback loop is organized and the firefighting is reduced to problem-solving. Whenever there is an infrastructure-related error, the operations team can take charge, and when there is an application-specific error, the developers can work on it. Now, the responsibility of solving problems is distributed based on expertise.
AppOps - The Future is Here
We at Devtron believe that with the adoption of Kubernetes, AppOps is no longer a pipe dream. The future of efficient app delivery through AppOps is here. Kubernetes provides the much-needed abstraction layer on top of disparate infrastructure and APIs so that information can be provided to developers in an easy and understandable format.
Our open-source product — Devtron, has been built with this ideology. It is an open-source software delivery workflow for Kubernetes to help the DevOps and developers team together implement AppOps and deploy applications efficiently.
Top comments (1)
I think they need to work on the name. :)
devops, comes from developer operations, as in developers being involved in operations.
Or maybe I just got lost in the jargon... :D