H-KA: Rebranding, Relaunch and Infrastructure-as-Code

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.

Q: Hi Sandra, may we disturb you for a moment? What are you doing at in2code and especially in this project?

I have been with in2code since 2014 - over 7 years now. As a product owner or project manager, I roughly take care of everyone :)
Starting with the needs analysis together with the customer through the conception to the support of complex programming, I am involved in all steps and the central contact person and organizational point. Here it is particularly important to me that all stakeholders speak the same "language" and that in the end what the customer had in mind comes out. We achieve this with agile project management methods, which are always individually tailored to the individual customer. In this project, for example, there was a firmly defined feature set, which was also adapted and supplemented in the ongoing development.

Q: How many people were involved in this project in total?

On our side? Since it was a really big project, two complete Scrum teams from our company were involved. There are 8 developers (frontend and backend), 3 server managers, 1 quality assurance and 2 supporting editors. And I of course. So, looking back, you can say that 30 hands were very busy and we didn't get bored.

Q: When you think back to the project, what was the biggest challenge from your point of view?

There was another party in this project, the CD Agency, which had to be brought together with the technical requirements and functions. That brought special challenges and a lot of testing and communication, but in the end it worked quite well. In some cases, the requirements changed during the project, so that features were rebuilt or expanded, but that's exactly what we work agile for. And finally, the project started on a completely green field, which means that everything really had to be created from scratch: central data sets for facilities, backend user groups, content and files and all of this in parallel with development. Martin has probably already lost a few words about the challenges with the new "Dockerization".

Q: Right, he did. What are you particularly proud of?

To the teamwork. Karlsruhe University of Applied Sciences is one of our oldest customers and this is already the third launch that we are going through together. Every time there are new challenges, but every time we also manage to look back on a successful project. Over the years we have been able to continually dismantle technical schools. It is one of the cleanest and most clearly structured TYPO3 systems that we as support customers are allowed to look after. I am proud that we have such a good cooperation and so much trust in one another.

Q: And finally: What did you take away for yourself from this project?

I learned that a new corporate design can always bring new functions with it. At first the thought was that the existing functions should be taken over and "just" get a new layout. But the new design has resulted in completely new requirements, so that we have now integrated our course finder from scratch and equipped the person directory with many new features and LDAP import functions. But that's exactly what I particularly enjoy: Developing and fulfilling wishes together with the customer.

Thanks Martin and Sandra for the brief insight.

Everything about the new corporate design of H-KA can be found in the university's official press release.