DevOps is considered a promising process improvement approach between the development and the operation of a software. It represents a great advantage for developers, operators and customers of softwares. Following the agile software development approach, there is a transformation towards the “digital assembly line” – the code is passed from the idea to the end product with the help of automated processes.
The work steps of the specialists are interlinked. This method results in high productivity, faster time to market and thus a better flow of the initial software idea to the applicable product. In addition to tools and goals for the topic of DevOps, the corresponding mindset is presented and it is necessary for successful implementation.
what business goals can be achieved through DevOps.
When it comes to DevOps, people often only talk about the tools and implementation solutions - but the focus should always be on how the business goals of a software product can be achieved better (or at all). Because DevOps also addresses the specialist side that commissions the software product. As an example, I briefly describe three examples of business goals that can be achieved through the DevOps mindset.
A possible business goal is the robustness of the software, which is naturally reinforced by a strong awareness of the developers of the course of the value chain and its influencing factors. The how and where of software operation (operations) should be just as important as the architecture (development). It is therefore not unreasonable to read this form of equal recognition out of the big O of DevOps.
With regard to value creation, the influence of time can be taken up with the keyword time to market. Its shortening is another business goal. Clearly structured processes and an awareness of them ensure that technical requirements are quickly implemented on the assembly line of agile software development. Thanks to DevOps, well-rehearsed teams are also able to deliver consistent performance and provide reliable estimates when planning new requirements. Constantly looking outside the box at the company enables the development team to build up a broad knowledge base. A good example of this is the following situation: When a lack of knowledge about slow backend systems means that performance bottlenecks are only recognized when a new software requirement goes to market.
Then quick improvements are required, which, however, raise the following two problems:
· On the one hand, developers only gain more precise knowledge of these systems when there are significant failures. Then there is no time to think more about the farm and the ecosystem there. With the aim of finding a "band-aid" for the problem, the source is searched intensively, but only on an ad hoc basis. What is still missing is a deeper insight into the Operations area.
· On the other hand, those responsible in the patch are only looking for a selective solution to the performance bottlenecks, but they are not carrying out a complete revision of the software architecture. Because there is a lack of time and resources after a failed go-live. The specialist side is pushing for a quick placement of the product on the market or in the business process and thus sets the pace. The revision of the architecture that is actually necessary is therefore canceled.
It takes daily contact with how the systems think in order to develop a feeling for them and to incorporate this knowledge into architectural decisions.
We'll add right away that modern software companies with cloud and container-based platforms (keywords: Kubernetes and OpenShift) already have a very transparent DevOps approach and eliminate many weak points. However, they do not prevent the problems caused by unknown weak links in the chain of operations. If suitable monitoring tools are available to find these links, the developers must also learn how to use and interpret these tools.
A third business goal that can be achieved through DevOps is sustainability. This connects to the above two business goals of robustness and time to market. Better knowledge about value creation and the parties involved results in a high-quality software product. The DevOps approach makes it easier for a future, new development team to understand and resume work on this code. The patches mentioned above will then be needed less often.
mindset and knowledge sharing are the ingredients for success for DevOps.
Of course, it does not mean that the problems mentioned will never occur again due to the DevOps idea - but they become much rarer if a well-rehearsed team with a correspondingly high level of DevOps experience is involved. In a way, DevOps is a guide to how a team can achieve this level of alignment. The mindset is especially essential. Because it is the team members who are driven by knowledge sharing that advance the DevOps idea. This means that they not only strive to constantly learn new things and to be aware of their working environment. They also share this knowledge with those around them. DevOps success is demonstrated when a team likes to constantly improve and reflect on their work.
two hurdles in realizing DevOps: management and operations.
There is a lot to consider to find the right catalyst to get the DevOps process rolling. Daily contact with the thinking of the systems requires an opening and willingness to cooperate in two organizational units of a company so that the first step from Dev to Ops can take place: On the one hand, Ops has to move in the direction of Dev and on the other hand, management has to support these efforts .
The willingness of the operations department to provide resources and a platform for cooperative exchange is fundamental for the development department to have an overview of the topic of ops. In day-to-day business, it is important that developers can make direct contact with people in the company. In addition, it must be simple and clear to move around the server landscape via login or front-end tools. In addition to creating a clear technical basis, the company must also be willing to take on the role of a pilot and thus be available to a wide audience for support requests. To accommodate this, developers must be able to provide insights into the interfaces and configurations of their software product.
these tools make the job easier.
One technological development that greatly facilitates DevOps is virtualization. The term "Infrastructure as Code" coined by Kief Morris stands for the new possibilities offered to developers in the cloud age. Thanks to a virtualized infrastructure, direct access to the hardware is no longer necessary. Entire servers can be executed, duplicated or deleted with a single line of code. Central management of the source code with versioning and automated testing of the configuration of virtual machines and the corresponding deployments is also possible. Automation in particular helps to reduce the time required for developers and operators.
For DevOps, the following tools are particularly helpful in linking development and operations:
- Virtualization solutions such as VirtualBox are the be-all and end-all of successful DevOps. They help developers test their code on local virtual machines. This allows you to test how the server environment reacts to the software as early as the development stage.
- Automation solutions such as Puppet, Vagrant or Ansible support developers and operators in concentrating on the essential aspects of their tasks by taking over routine processes themselves. This can be applied to explore, test and execute on both the software and infrastructure side.
- Container platforms such as Docker help to provide containers, i.e. executable virtual summaries of individual applications – including all libraries, utilities and other data, but without an operating system. Containers can be started in the environment of a host operating system and are therefore more resource-efficient than a completely virtualized application environment. In connection with the built-in standardization in scaling, service discovery or load balancing (e.g. with Docker Swarm), working with containers has become essential for DevOps developers.
which skills are needed for DevOps.
The "T-shape" introduced by David Guest gives a clue: The vertical column of the letter "T" symbolizes the special skills of the employee in a defined field; the horizontal bar the ability to work transdisciplinary. For DevOps, a close integration of the requirements of the operator or infrastructure side is necessary. That is why the horizontal is particularly important for the employees. Generalists who are open to a new approach and have the appropriate technologies are in demand. It is relatively easy to learn how to use these, since some of them already have a manageable range of functions or can also be used in a basic version. An equally important skill is the openness to an exchange of knowledge and the ability to
Similar to the mega-topic of agility, the DevOps approach has established itself as a buzzword that hides a collection of requirements and business problems. In agile software development, fixed methods, tools and structures have been developed and established over time. A similar process can be seen in DevOps. Nevertheless, DevOps should not be confused with a job profile. Even if there are now experts who have specialized in DevOps, the topic is located in a cross-section and, analogous to agility, requires a mindset, a cultural change. That's why it's not about individual competencies, skills or even tools - DevOps is a radically new way of working.
a new level for IT.
The term DevOps still raises some question marks among both developers and IT managers. In the long term, however, there is nothing to avoid the topic, because the DevOps approach will in all likelihood become the industry standard in the next few years and is already common practice in some sectors. In order for DevOps to become the standard, developers need to retrain and become more involved with issues related to the operation of the software. The roles established in DevOps as well as tools and specific skills help here.
In particular, it is important to mix all these ingredients in such a way that the parties involved get an appetite for helping to shape the realization of the DevOps idea. The transformation to the "digital assembly line" mentioned at the beginning of the article is reminiscent of the introduction of the assembly line in Henry Ford's car factories. It triggered nothing less than a revolution in industrial production. A similar revolution is currently emerging in the IT world, in which it is very exciting for us as IT consultants to be part of it and to continue to drive this development with and with the customers.