Q: Hi Martin, what is your position at in2code and what did you do at h-ka.de?
As CTO at in2code, I mainly take care of the technology in the background and our own technical development. One of my main tasks is to promote and consolidate the DevOps principle in the minds of all colleagues.
H-ka.de is a project in which we wanted to go completely new ways. Especially in the area of the servers in the university's data center, which we install, configure and maintain. Our goal was and is a holistic DevOps approach. This included the areas of Infrastructure-as-Code (IaC) and, above all, complete automation with Gitlab CI (Continuous Integration) and the containerization of the entire software stack based on Docker. My job is to design this together with my colleagues and of course to implement it.
Q: Who worked on the infrastructure project?
Many many! Due to the DevOps approach, it is imperative that developers and system administrators work closely together. Thus, the entire team of administrators and a developer were initially busy with the conception and implementation. After the basic features of the infrastructure had been defined and, in some cases, implemented, more and more developers were added one after the other.
Q: What made this project so special?
The aim was a holistic approach that allows everyone involved to work together on the same code, even beyond the various areas of responsibility such as server operating systems and application development. In the end we managed to do that.
Q: What are the advantages of the construct?
The biggest advantage is the entirety of the project in one place. This enables us to roll out and execute changes across the server configuration and application at the same time. An example would be the adaptation of a PHP version, which we can now set centrally at a single point. If we now build, test and deploy the project, the server will be prepared fully automatically and the application will be rolled out with this changed PHP version. Since we of course work with different instances, such as a Develop-. Release and live instance, we can also roll out and test such adjustments via a single instance. Specifically, this also means that developers locally, product owners on a release system and the editors on the live system all work with exactly the same server configuration. Specific errors can now be recognized and eliminated at an early stage.
Another advantage of the Infrastructure-as-Code is that the documentation is always up-to-date. Since no settings, for example on the server, are adjusted by a person via a command on the command line, but are always made via the automatic provisioning, these are always comprehensible for everyone involved. This also avoids the so-called snowflake effect. This describes that the configurations of similar servers continue to differ from one another after a long period of time.
In addition, by using Docker as a container engine, it is possible to run individual instances on different software versions. The instances do not depend on which version of a software is installed directly on the server, but rather brings the required version encapsulated in its own container.
Q: You sound really enthusiastic. What were the hurdles during implementation?
There weren't any major problems, but there were a lot of minor problems (laughs). But that just brings a project of this size with it. In retrospect, it is even more important that communication between the different teams and the different areas of responsibility works well.
By the way: I keep getting asked why we chose this path. My answer is simply: "It is also complex if we do it differently. But now we are making the complexity visible."
Q: Do you have another tip for similar projects?
I would go the same way again: Infrastructure-as-Code and the associated containerization and full automation. Depending on the frequency of use, I would recommend a Kubernetes cluster for large sites in order to be able to distribute loads better and to reduce possible downtimes.