DEV Community: Dominik Pabst

DevOps: Beyond a Modified SDLC Model - More than a Hashtag and an Illustration

Dominik Pabst — Mon, 18 Sep 2023 10:07:38 +0000

The term "DevOps" is ubiquitous these days and has become something of a buzzword. Originally, it came about because it could be conveniently used as a hashtag on Twitter to track discussions related to software development and operations. Nevertheless, DevOps encompasses far more depth and significance than merely a passing trend.

The power of visualisations

We often rely on illustrations to explain complex concepts. One example is the "DevOps Infinity Loop", which many of us have seen in presentations and discussions. This illustration gives the impression that different stages in the cycle can be directly attributed to either development or operations. However, the reality is much more nuanced.

While such representations are visually appealing, they often oversimplify the complexity of DevOps, reducing it to a level that does not do justice to the depth and diversity of the methodology. These portrayals can lead to misunderstandings and give the impression that DevOps is limited to a linear sequence of steps.

DevOps as a philosophy and culture

In reality, DevOps is much more than that. It is a philosophy and culture of collaboration, continuous learning and continuous improvement. DevOps aims to break down the silos between development and operations, but that doesn't mean it's limited to just those two areas. DevOps is a call for collaboration and the application of principles throughout the organisation.
The strength of DevOps is its versatility and adaptability. It allows principles and tools to be applied based on an organisation's specific needs and goals.

DevOps beyond a modified SDLC model

While it's true that DevOps is often associated with the integration of development and operations within the Software Development Life Cycle (SDLC), it's important to recognise that DevOps is not just a modified version of the SDLC.
The SDLC focuses primarily on the phases of software development, from planning and design to coding, testing, deployment and maintenance. DevOps, on the other hand, extends its reach beyond these phases to encompass a broader set of practices and principles.
DevOps involves a cultural shift that encourages collaboration, communication, and shared responsibility across all facets of the organisation. It promotes a mindset of automation, continuous integration, continuous delivery and continuous monitoring that goes over and above the boundaries of traditional SDLC models.
In addition, DevOps recognises the importance of feedback loops, both internal and external, to drive continuous improvement. It encourages teams to work closely together to streamline processes, reduce bottlenecks and improve the overall efficiency of the entire software development and deployment pipeline.

Embrace the lack of a strict framework

One of the unique aspects of DevOps is the lack of a strict framework; however, this also opens the door to potential misinterpretations. In many illustrations of the infinite loop, you often see only 'Dev' and 'Ops', with the occasional 'Security' thrown in. This has led to calls for the resulting in variations such as DevSecOps or even further modified DevBizOps to include the Business aspects.
Nonetheless, it's important to understand that the core idea behind the DevOps movement is the integration of the entire organisation and every aspect of software development.

Conclusion

So let's not stop at the surface level of DevOps, which often involves hashtags and visual representations. It's about understanding the principles behind DevOps and applying them to our unique challenges and goals. DevOps is a journey of collaboration, innovation, and continuous improvement.

The Secret of Santa's Success: Collaboro and DevOps

Dominik Pabst — Sun, 11 Dec 2022 12:40:52 +0000

Once upon a time, in the bustling workshop at the North Pole, there was an elf named Collaboro.
Collaboro was a hardworking and dedicated elf, and he was known throughout the workshop for his skill and expertise.
One day, Santa Claus called a meeting of all the elves in the workshop. He explained that he was worried that the toy production process was not running as smoothly as it should. There were delays, mistakes, and misunderstandings, and Santa was concerned that they would not be able to make and deliver all the toys in time for Christmas.

Collaboro stepped forward and offered to help. He explained that the problem was that the elves and the reindeer were not working together effectively. They were each focusing on their own tasks, without much communication or collaboration.
Collaboro suggested that they try a new way of working, called DevOps.

DevOps, he explained, was a philosophy and a set of practices that emphasized collaboration and communication. By working together, the elves and the reindeer could improve the speed and quality of toy production.
The other elves were skeptical at first. They were used to working on their own, and they were not sure that DevOps would be any better. But Collaboro was persuasive, and he convinced them to give it a try.
And it worked! The elves and the reindeer began to work together more closely, sharing ideas and collaborating on projects. As a result, the toy production process became more efficient and effective.
Santa was delighted, and he praised Collaboro for his great idea.

The elves were also satisfied. Many of them had heard the term DevOps before, and many had opinions about it, but only now, after Collaboro explained the background and all work together with this knowledge, did they realize that DevOps was not a specific tool or technology. It was a way of working that helped them collaborate more effectively.
They also learned that DevOps was not a replacement for their traditional methods, but rather a way to improve and enhance them. And they discovered that DevOps was not just for the elves, but for all of the workers in the workshop, regardless of their role or responsibilities.

Thanks to Collaboro and DevOps, the workshop was able to produce more toys in less time, and the town was filled with joy on Christmas morning as the happy children opened their gifts.

And they all lived happily ever after, learning the true meaning of DevOps: that collaboration and communication are key to success.

The end.

DevOps: 7 myths that hinder your transformation

Dominik Pabst — Tue, 08 Nov 2022 07:57:29 +0000

Many myths circulate around the DevOps movement. This is no surprise, considering how popular and also inflationary the term has become in recent years and is thus also used at almost every opportunity. So today we want to take a closer look at a few of the most critical "narratives" so you know what DevOps is all about and how to properly implement it. In this blog post, we'll take a closer look.

Myth 1: DevOps is only for Dev and Ops

Although the term originally started out as “only” for Dev and Ops, this was due to the background that the biggest problems were seen there at the time. The so-called Wall of Confusion had the greatest effect on the two disciplines at the time DevOps was created. Nevertheless, we are in a constantly changing and more extensive world. Where once one developer was responsible for the entire product lifecycle, today there needs to be dedicated experts for each of the disciplines (Dev, Ops, QA, Sec, Agile, etc.). This increasing complexity requires extraordinary communication to continue to productively deliver secure and high quality software. Accordingly, it quickly becomes apparent that DevOps must not be applied to just two of the now myriad areas. Otherwise, we run the risk of creating the very things we actually wanted to break down with DevOps: poor communication, silos, an “us and them” mentality, etc.

At the heart of the issue is often the naming of the process. DevOps as a portmanteau word implies that it is just Dev and Ops. Thus, myths like this are bound to happen. This is one of the reasons why we want to migrate the term DevOps within Novatec more and more to “perfect Flow”. Last but not least, this helps us to establish and continuously improve the holistic transformation process not only for us internally, but also for our customers.

Myth 2: DevOps is just a tool

The market around DevOps is growing steadily. This is not least due to the fact that the term has been strongly popularized in recent years. Tools like Azure DevOps specifically try to address the needs of completing a DevOps transformation. The focus of Azure DevOps here tends to be to make all the necessary individual tools, which are required for the development of the entire product lifecycle, usable centrally in one place. The common assumption now is “if I use Azure DevOps, I do DevOps”. Unfortunately, this is not correct, as the process towards a DevOps organized company is much more difficult and complex.

While Azure DevOps is enormously helpful, it only covers a large part of the technical aspects in that context. Equally important in this context are the cultural conditions that must be met in order to ensure a transformation. Without an adaptation of the internal processes and structures to match the new technical conditions, various positive opportunities will be disregarded. Within Novatec, we view DevOps under the three pillars: Business, Culture and Technology. If we act purely on the tool or technical level, we lose the trinity and thus two thirds of the topic.

Myth 3: DevOps Engineer

The eternal search for the egg-laying willy-nilly also exists in the DevOps context, of course. Historically, the basic approach behind the DevOps Engineer was a good one. It was to fill a newly created gap around the field of automation. DevOps Engineers are therefore developers who have put their focus on automation or Ops’ers who have a stronger focus on development. Due to the ever-increasing complexity, the field of activity of a DevOps Engineer is therefore also growing.

The core of the problem is therefore on the one hand the very inflated DevOps term, which cannot be fully understood in its entirety, and on the other hand the desire to fill the aforementioned gaps as broadly as possible. Unfortunately, this problem also extends to recruiting. How do I find exactly the one DevOps engineer I need specifically for pipelines, for example?
Job descriptions such as “DevOps Engineer with a focus on pipelines” are helpful here in order to narrow down the market accordingly. It is therefore important to structure the overloaded term neatly into categories, to cut it and thus provide space for a precise job description.

Myth 4: I can create a DevOps team and then “run” DevOps

Similar to the DevOps Engineer myth listed earlier, simply launching a DevOps team causes silos to build up, which we originally wanted to reduce and prevent. By having a dedicated DevOps team, we deliberately compartmentalize the benefits around DevOps, encapsulating them in one team and, exaggeratedly speaking, “locking it away.” Not only does this help us block the transparency, collaboration and knowledge sharing we want, but it also puts another bar on inter-team communication. Where before there was an operations team and a development team that could not adequately communicate with each other, now there are three teams that can do so even less. Thus, nothing was gained except a semblance of DevOps.

Myth 5: DevOps is a finite process

DevOps, or the so-called “DevOps transformation,” is a constantly changing, iterative process. There will always be the opportunity for new improvements and new ideas. Processes can be further streamlined, silos further broken down, and communication channels further improved. A simpler way to imagine it is to think of DevOps as a freight train that first needs to be refueled, starts its journey, but never fully reaches its destination. The DevOps train has many stops along the way where it delivers its goods for the respective locations where they will (hopefully) hit fertile ground. At each stop, the train must be refueled so that it doesn’t come to a stop halfway through its journey. This fertile ground often simply means having an openness within a team to new changes.

The continued refueling of our DevOps train ensures that the transformation receives the necessary backing. The interesting and exciting thing about this analogy is that no two DevOps trains look the same or even exclusively travel the same routes. For every company that wants to establish DevOps, the starting point and all the stops in between look different. Each company has its own personal characteristics and problems, which need to be solved in a differentiated manner in a process that is always moving forward. Once again, the journey is the destination!

Myth 6: I can integrate the same processes as Amazon, Google, Netflix and Co.

As already started under “Myth 5”, every company has to find its own way. It would be wonderful if there was only this one process to follow to successfully establish a DevOps transformation. That would make our day-to-day work as DevOps consultants much easier. But unfortunately, this is not the case. Unique structures, processes, problems, communication channels, company policies, etc. ensure that every transformation must be rethought, carefully planned and ultimately tailored precisely to the needs. Where does the shoe currently pinch the most? For example, to ensure the necessary management buy-in, it makes sense to solve the greatest pain and at the same time generate the greatest added value. Such decisions set a clear direction that is unique to each company.

Myth 7: DevOps vs Agile

Both DevOps and Agile are mindsets that can be used for software development. DevOps builds on and leverages Agile concepts in many ways. Nevertheless, you don’t have to be Agile to be able to establish DevOps. Of course, it helps enormously and follows the natural flow of processes. However, there has to be the space within a company to apply agile methodologies. In some industries, it is still not possible due to external circumstances to cut work packages into individual parts and process them in defined cycles. Therefore, the reality here is still that the waterfall methodology in project management has its raison d’être for just such companies.

Nevertheless, we advise it: If external circumstances permit, Agile and DevOps should be used together. DevOps works particularly well with Agile because the basic principles of small teams delivering software iteratively can be used as a foundation to not only prototype DevOps at the start of a transformation, but also to align it for long-term scalability.

Conclusion:

We hope we’ve been able to dispel a few of the myths surrounding DevOps. Our concern is that our readers familiarize themselves exactly with the possible myths before starting a transformation and hopefully avoid them completely. Studies such as those conducted by DORA or Puppet clearly show that the above-mentioned stumbling blocks are not only enormously time-consuming, but also very expensive. In the worst case scenario, the pitfalls highlighted will burn the concept to the ground, unfortunately bringing the DevOps train to a longer-term or even final halt.

Feel free to let us know which DevOps myths you’ve stumbled across so far.
By the way, there will be more blog posts about DevOps topics here in the future. So: Stay tuned!

DevOps: 7 Mythen die deine Transformation verhindern (German)

Dominik Pabst — Tue, 08 Nov 2022 07:48:47 +0000

Um die DevOps-Bewegung kursieren viele Mythen. Das ist keine Überraschung, wenn man bedenkt, wie populär und auch inflationär der Begriff in den letzten Jahren geworden ist und dadurch auch nahezu bei jeder Gelegenheit verwendet wird. Daher möchten wir heute ein paar der kritischsten "Erzählungen" genauer unter die Lupe nehmen, damit Du weißt, worum es bei DevOps geht und wie man es richtig ein/umsetzt. In diesem Blogpost setzen wir uns damit auseinander.

Mythos 1: DevOps ist nur für Dev und Ops

Der Begriff begann zwar im ursprünglichen Sinne „nur“ mit Dev und Ops, allerdings war das dem Hintergrund geschuldet, dass zur dortigen Zeit die größten Probleme gesehen wurden. Die sogenannte Wall of Confusion hatte zur Entstehungszeit von DevOps den größten Effekt bei den beiden Fachrichtungen. Nichtsdestotrotz befinden wir uns in einer sich stetig wandelnden und umfangreicher werdenden Welt. Wo früher noch ein Entwickler für den gesamten Produktlebenszyklus zuständig war, braucht es heute dedizierte Experten für die jeweiligen Fachbereiche (Dev, Ops, QA, Sec, Agile, etc.). Diese steigende Komplexität erfordert eine außerordentliche Kommunikation, um weiterhin produktiv sichere und qualitativ hochwertige Software auszuliefern. Demnach wird schnell ersichtlich, dass DevOps nicht nur für zwei der mittlerweile unzähligen Bereiche angewendet werden darf. Ansonsten laufen wir Gefahr, eben das zu erzeugen, was wir mit DevOps eigentlich auflösen wollten: schlechte Kommunikation, Silos, eine „wir und die“ Mentalität, etc.

Im Kern der Problematik steht oftmals die Benamung des Prozesses. DevOps als Kofferwort impliziert, dass es sich nur um Dev und Ops handelt. Damit sind Mythen wie diese vorprogrammiert. Das ist einer der Gründe, warum wir den Begriff DevOps innerhalb der Novatec mehr und mehr zum “perfect Flow” migrieren wollen. Das hilft uns nicht zuletzt dabei, den ganzheitlichen Transformationsprozess für uns intern, sondern auch bei unseren Kunden zu etablieren und stetig zu verbessern.

Mythos 2: DevOps ist nur ein Tool

Der Markt rundum DevOps wächst stetig an. Das liegt nicht zuletzt daran, dass der Begriff in den vergangenen Jahren stark popularisiert wurde. Tools wie Azure DevOps versuchen gezielt auf die Bedürfnisse bei der Vollziehung einer DevOps Transformation einzugehen. Der Mittelpunkt von Azure DevOps ist hierbei tendenziell alle notwendigen einzelnen Tools, welche zur Entwicklung des gesamten Produktlebenszyklus notwendig sind, zentral an einem Ort nutzbar zu machen. Die häufige Annahme ist nun: “Wenn ich Azure DevOps nutze, mache ich DevOps”. Das ist leider nicht korrekt, da der Prozess hin zu einem DevOps organisierten Unternehmen wesentlich schwieriger und komplexer ist.

Azure DevOps ist zwar enorm hilfreich, deckt in dem Kontext allerdings nur einen Großteil der technischen Aspekte ab. Ebenso wichtig sind in diesem Rahmen die kulturellen Gegebenheiten, welche erfüllt sein müssen, um eine Transformation zu gewährleisten. Ohne eine Anpassung der firmeninternen Prozesse und Strukturen, um diese mit den neuen technischen Gegebenheiten zu matchen, werden diverse positive Chancen außer Acht gelassen. Innerhalb der Novatec betrachten wir DevOps unter den drei Säulen: Business, Kultur und Technik. Wird nun rein auf der Tool- bzw. technischen Ebene agiert, verlieren wir die Trinität und damit zwei Drittel der Thematik.

Mythos 3: DevOps Engineer

Das ewige Suchen nach der Eier legenden Wollmilchsau existiert natürlich auch im DevOps Kontext. Historisch betrachtet war der Grundansatz hinter dem DevOps Engineer ein guter Gedanke. Es galt eine neu entstandene Lücke rundum den Bereich der Automatisierung zu füllen. DevOps Engineers sind daher Entwickler, welche ihren Fokus auf die Automatisierung gesetzt haben oder Ops’ler welche einen stärken Fokus auf die Entwicklung legen. Durch die immer weiter wachsende Komplexität wächst daher auch das Aufgabenfeld eines DevOps Engineers.

Im Kern des Problems liegt daher auf der einen Seite der sehr aufgeblasene DevOps Begriff welcher in seiner Gesamtheit nicht vollends verstanden werden kann und auf der anderen Seite der Wunsch, die zuvor genannten Lücken so breit wie möglich zu befüllen. Die Problematik zieht sich damit leider auch in das Recruiting. Wie finde ich genau den einen DevOps Engineer, welchen ich spezifisch für bspw. Pipelines benötige?
Hilfreich sind hier Job Bezeichnungen wie “DevOps Engineer mit Fokus auf Pipelines”, um den Markt entsprechend einzugrenzen. Es gilt daher den überladenen Begriff sauber in Kategorien zu strukturieren, zu schneiden und damit Raum für eine genau Aufgabenbeschreibung zu sorgen.

Mythos 4: Ich kann ein DevOps-Team gründen und “betreibe” dann DevOps

Ähnlich wie der zuvor aufgeführte Mythos des DevOps Engineers verursacht die bloße Einführung eines DevOps Teams den Aufbau von Silos, welche wir ursprünglich reduzieren und verhindern wollten. Durch ein dediziertes DevOps Team grenzen wir die Vorteile rundum DevOps bewusst ab, kapseln sie in einem Team und sperren es, übertrieben gesprochen „weg“. Das trägt nicht nur dazu bei, dass wir die gewünschte Transparenz, Zusammenarbeit und den Wissensaustausch blockieren, sondern auch einen weiteren Riegel für die Kommunikation zwischen den einzelnen Teams schieben. Wo es zuvor ein Operationsteam und ein Entwicklungsteam gab, welche nicht ausreichend miteinander kommunizieren konnten, existieren nun drei Teams, welche das noch viel weniger können. Damit wurde nichts gewonnen außer einem Schein an DevOps.

Mythos 5: DevOps ist ein endlicher Prozess

DevOps bzw. die sogenannte “DevOps Transformation” ist ein sich stetig wandelnder, iterativer Prozess. Es wird immer die Chance für neue Verbesserungen und neue Ideen geben. Prozesse können weiter verschlankt, Silos weiter aufgebrochen und Kommunikationswege weiter verbessert werden. Einfacher vorzustellen geht es, indem wir DevOps als einen Güterzug betrachten, der zunächst betankt werden muss, seine Reise antritt, aber sein Ziel nie vollends erreicht. Der DevOps-Zug hat viele Zwischenhaltestellen, bei denen er seine Güter für die jeweiligen Orte abliefert, wo sie auf (hoffentlich) fruchtbaren Boden stoßen. An jeder Haltestelle muss der Zug neu betankt werden, damit er nicht auf halber Strecke zum Stopp kommt. Dieser fruchtbare Boden bedeutet oftmals schlicht eine Offenheit innerhalb eines Teams für neue Veränderungen zu besitzen.

Die weiterführende Betankung unseres DevOps-Zugs sorgt dafür, dass die Transformation den nötigen Rückhalt erhält. Das interessante und spannende an dieser Analogie ist, dass kein DevOps-Zug gleich aussieht oder gar ausschließlich die gleichen Routen fährt. Für jedes Unternehmen, welches DevOps etablieren möchte, sieht der Startpunkt sowie alle Zwischenstopps unterschiedlich aus. Jede Firma hat ihre persönlichen Eigenheiten und Probleme, welche es differenziert in einem sich immer weiter bewegenden Prozess zu lösen gilt. Vielmehr ist auch hier wieder der Weg das Ziel!

Mythos 6: Ich kann die gleichen Prozesse wie Amazon, Google, Netflix und Co. integrieren

Wie bereits unter dem “Mythos 5” begonnen, muss jede Firma ihren eigenen Weg finden. Es wäre wundervoll, wenn es nur diesen einen Prozess gäbe, an welchen man sich für die erfolgreiche Etablierung einer DevOps Transformation halten müsste. Das würde unseren Arbeitsalltag als DevOps Berater erheblich erleichtern. Doch leider ist dem nicht so. Einzigartige Strukturen, Prozesse, Probleme, Kommunikationswege, Firmenpolitiken, etc. sorgen dafür, dass jede Transformation neu gedacht, sorgfältig geplant und letztlich genau auf die Bedürfnisse zugeschnitten werden muss. Wo drückt der Schuh aktuell am meisten? Um beispielsweise das notwendige Management-Buyin sicherzustellen, macht es Sinn, den größten Schmerz zu lösen und zeitgleich den größten Mehrwert zu erzeugen. Durch solche Entscheidungen wird eine klare Richtung eingeschlagen, welche einzigartig für jede Firma ist.

Mythos 7: DevOps vs Agile

Sowohl DevOps als auch Agile sind Mindsets, welche für die Entwicklung von Software genutzt werden können. DevOps baut in vielerlei Hinsichten auf Konzepten von Agile auf und nutzt diese. Nichtsdestotrotz muss man nicht agil sein, um DevOps etablieren zu können. Selbstverständlich hilft es enorm und folgt dem natürlichen Flow der Prozesse. Allerdings muss es innerhalb einer Firma auch den Raum für die Anwendung von agilen Methodiken geben. In einigen Branchen ist es noch immer durch äußere Gegebenheiten nicht möglich, Arbeitspakete in einzelne Teile zu schneiden und diese in definierten Zyklen abzuarbeiten. Daher ist hier die Realität noch immer, dass die Wasserfallmethodik im Projektmanagement für eben solche Firmen ihre Daseinsberechtigung besitzt.

Dennoch raten wir dazu: Wenn es die äußeren Gegebenheiten zulassen, sollten Agile und DevOps gemeinsam genutzt werden. DevOps funktioniert besonders gut mit Agile, da die Grundprinzipien kleiner Teams, welche iterativ Software ausliefern, als Fundament genutzt werden kann, um DevOps nicht nur zum Beginn einer Transformation zu prototypisieren, sondern auch langfristig skalierbar auszurichten.

Fazit:

Wir hoffen, wir konnten ein wenig mit einigen der Mythen rundum DevOps aufräumen. Unser Anliegen ist, dass sich unsere Leser vor dem Beginn einer Transformation genau mit den möglichen Mythen vertraut machen und diese hoffentlich vollends vermeiden. Studien wie von DORA oder Puppet durchgeführt, zeigen deutlich, dass die oben genannten Stolpersteine nicht nur enorm zeitintensiv, sondern auch sehr teuer sind. Im schlimmsten Fall wird mit den aufgezeigten Fallgruben der Begriff vollends verbrannt, wodurch der DevOps-Zug leider zum längerfristigen oder gar finalen Stopp kommt.

Lass uns gerne wissen, über welche DevOps Mythen du bisher gestolpert bist.
In Zukunft werden hier übrigens noch weitere Blogbeiträge rundum DevOps Themen erscheinen. Also: Stay tuned!

Understanding Infrastructure as Code in less than 10 minutes

Dominik Pabst — Fri, 19 Mar 2021 09:48:06 +0000

In this article, you will learn about the basics, origins and phases of Infrastructure as Code. In addition, we show you small code examples to give you a first impression of the different tools and thus reduce your inhibitions to use them to a minimum. With this overview, you will easily be able to put together the right tooling for your project, we promise!

The manual configuration of server landscapes poses several challenges for IT professionals, for example due to the ever-increasing complexity and the associated demands on IT infrastructure.

The Infrastructure as Code (IaC) approach offers an alternative, in which servers are provisioned, configured and managed by machine-readable scripts, for example.

IaC can be defined as the formal description of infrastructures, such as servers, databases, network components, etc. In addition, the Infrastructure as Code approach can be implemented using a variety of software tools/frameworks.

NOTE: Due to the fact that one could fill several books with the topic "What is and what comprises IT infrastructure" alone, we have decided to focus on servers as placeholders of infrastructure in this article. It does not matter whether it is a bare-metal, containerised or virtualised server.

Where does Infrastructure as Code come from?

"Only those who know the past can understand the present and shape the future" - August Bebel

Let's travel back in time 15-20 years and take a look at software companies like Adobe, Atlassian or Facebook. From today's perspective, very successful companies. But they also started small once. To be able to sell their digital products, they first operated individual servers and got by with little hardware. Gradually, they built smaller data centres. Initially self-operated, they later bought the administration and hardware from other service providers. Over the years, the server landscape in the data centres grew steadily in order to be able to guarantee stable operation for a growing number of users. Many completely underestimate how many servers are necessary. For example, in 2009, just 5 years after the launch of their social network, Facebook announced that they were running more than 30,000 servers!

Provisioning, configuration & deployment used to be quite slow

Even if a company only needs to deploy a few dozen servers, organisational challenges quickly arise. Hardware has to be ordered and installed in the server rooms when scaling up. Establishing a reliable network connection is just as important. Thanks to cloud providers, such as AWS, Azure or Google, the effort is much smaller today. Servers are accessible via the internet within minutes of being ordered. They can also be connected to virtual networks, load balancers, etc. by configuration.

But after providing the bare server, you are not done yet. Usually, each server has to be set up for a specific purpose: The configuration includes, for example, user administration, the installation of dependencies, runtime environments and other tasks to operate software applications on top.

Once a server is ready, the actual software can be installed. Today, such a deployment usually happens automatically. At least the DevOps movement has made it clear that such process steps should ideally be fully automated:

More about DevOps at Novatec Consulting GmbH

Deployments both of software and servers are not one-off or infrequent activities. In a larger landscape, old servers are constantly being removed, new ones added or existing ones adapted. This creates a natural life cycle of servers.

Automation to prevent errors and configuration drift

The steps described above are carried out for each new server. However, the operation of the "old" servers and the further development of the products should of course continue. Due to the considerable effort for server setup, without IaC, modifying or reusing old servers instead of creating a new one can be tempting. It can easily happen that a "test machine" is turned into a new "productive instance". Sometimes runtime environments have to be changed urgently or other tooling has to be installed.

Such undocumented ad-hoc changes always lead to problems in the long run. This is called "configuration drift", i.e. when the server's standard configuration is deviated from. Due to the long running time of the servers, more and more old burdens are gradually accumulated. Step by step, these servers mutate into so-called snowflake servers - each one unique and therefore almost impossible to maintain:

„The result is a unique snowflake – good for a ski resort, bad for a data center.“ – Martin Fowler

Due to this fact, the Phoenix server pattern established itself, which wants to put an end to this circumstance. "Like the Phoenix from the ashes", a server is to be virtually burnt down and recreated at regular intervals:

„A server should be like a phoenix, regularly rising from the ashes“ – Martin Fowler

However, this would be extremely time-consuming without automating the infrastructure. In the past, attempts were made to realize this automation using shell scripts. However, it quickly became clear that such scripts are not the right tool due to their high complexity and poor portability. In 1993, the first IaC tool was developed with the "CFEngine" project. CFEngine offers an interface that is independent of the operating system and thus abstracts the differences between the various Linux distributions. With its declarative and domain-specific description language, the tool simplifies the configuration of servers immensely. Today, many similar solutions exist, as the following timeline shows:

All these tools attempt to simplify and accelerate while increasing code quality and readability. Many tackle this difficult endeavour with the help of principles and practices from software development. The tools specialize in different phases, which we will explain in more detail below.

The different phases

When applying IaC, a distinction is made between two phases. Each phase covers specific work:

Initial Setup Phase
- Provisioning of the infrastructure
- Configuration of the infrastructure
- Initial installation of software
- Initial configuration of software
Maintaining Phase
- Adjusting the infrastructure
- Removal and addition of components
- Software Updates
- Reconfiguration of software

To abstract it a bit, we will talk about the initial infrastructure setup and the initial application setup and management. This covers both phases completely. Depending on the approach and tool, the focus is more on the infrastructure or the application side. Docker images, for example, are used more as deployables rather than as an infrastructure component, which is why it is located on the right-hand side in the following image. The graphic can always look different depending on the perspective and is not meant as something absolute.

The different types of IaC

There are many different types of IaC. Each has its own advantages and disadvantages. So depending on the application, it is important to discover which tools and methods can generate the greatest added value. In the following, we present the most common types and demonstrate them with a small code snippet.

Scripts

The most basic way to automate something is to write a script. In doing so, the steps of the otherwise manually performed task are written in the preferred script language and then executed in the target environment. The following bash script installs a web server and starts it.

#!/bin/bash 
# Update Package Manager
sudo apt-get update 
# Install Apache sudo apt-get install -y apache2 
# Start Apache 
sudo service apache2 start

Popular scripting languages:

Bash
Python
Ruby
Powershell

Configuration Management Tools

Configuration management tools are designed to install and manage software on existing servers. For example, here is an Ansible role that configures the same Apache web server as the Bash script above:

- hosts: apache
sudo: yes
tasks:
- name: install apache2
apt: name=apache2 update_cache=yes state=latest

Popular configuration management tools:

CFEngine
Ansible
Chef
Puppet
Saltstack

Templating Tools

An alternative to configuration management tools are templating tools, such as Docker, Packer and Vagrant. Rather than launching a series of instances and configuring them by running the same code on each one, the idea behind templating tools is to create an image. This “snapshot” of the operating system, software and any files can thus be delivered as a standalone artefact in the form of an image. Here is an example of a Dockerfile as a template for an Ubuntu-based image for a web server:

FROM ubuntu:latest
RUN apt-get -y update &amp;&amp; \
    apt-get install -y apache2 
ENTRYPOINT ["/usr/sbin/apache2"]
CMD ["-D", "FOREGROUND"]

Orchestration Tools

Templating tools are great for creating VMs and containers, but how can you manage many of them efficiently? This is where tools like Kubernetes, Amazon ECS, Docker Swarm or Nomad come into play. Since these tools are very complex and provide an enormous range of functionality, we will not go into more detail about how they work here. The behaviour of a Kubernetes cluster can be defined by code. This includes, for example, how your Docker containers should be executed, how many instances should be kept running and how to proceed with a rollout.

Provisioning Tools

Provisioning tools like Terraform, AWS CloudFormation and Pulumi are mainly meant for describing and creating cloud infrastructure. In fact, you can use them to create not only servers, but also caches, load balancers, firewall settings, routing rules and pretty much any other aspect of an IT infrastructure. Often configuration management or templating tools and provisioning tools intertwine. For example, Terraform can create a VM that is then set up with Puppet.

Conclusion

Choosing the right IaC toolchain is not easy, as there is no one-size fits all solution. The advantages of established configuration management, provisioning and/or orchestration are apparent. While even small projects benefit greatly from the IaC approach, it is not always worth employing powerful orchestration tools for small projects. If you have a clearly defined goal and want to introduce one of the above-mentioned types of IaC in your project, you can easily work your way through the requirements and step by step find the best setup.

With this overview, it should be easier for you to make the right choice for your project. If you still have questions, please ask them in the comments. You are also welcome to present your current setup in the comments, we are very curious to know which and why you are using your particular setup.

Infrastructure as Code in weniger als 10 Minuten verstehen (German)

Dominik Pabst — Mon, 15 Mar 2021 15:51:11 +0000

In diesem Artikel lernst du die Grundlagen, Herkunft und Phasen von Infrastructure as Code kennen. Darüber hinaus zeigen wir dir kleinere Codebeispiele, um einen ersten Eindruck der verschiedenen Tools zu geben und somit deine Hemmschwelle zur Nutzung auf ein Minimum zu reduzieren. Durch den gewonnenen Überblick wirst du problemlos das richtige Tooling für dein Projekt zusammenstellen können, versprochen!

Die manuelle Konfiguration von Server-Landschaften stellt IT-Fachkräfte vor mehrere Herausforderungen, zum Beispiel aufgrund der immer weiter ansteigenden Komplexität und der damit verbundenen Anforderungen an IT-Infrastruktur.

Der Infrastructure as Code (IaC) Ansatz bietet eine Alternative, in dem Server zum Beispiel durch maschinenlesbare Skripte provisioniert, konfiguriert und gemanagt werden.

IaC lässt sich als die formale Beschreibung von Infrastrukturen wie beispielsweise Server, Datenbanken, Netzwerkkomponenten usw. definieren. Zudem lässt sich der Infrastructure as Code Ansatz mittels einer Vielzahl von Software Tools / Frameworks umsetzen.

HINWEIS: Aufgrund der Tatsache, dass man alleinig mit dem Thema “Was ist und was umfasst IT-Infrastruktur” diverse Bücher füllen könnte, haben wir uns dazu entschlossen, in diesem Artikel stark vereinfacht den Blick auf Server als Platzhalter von Infrastruktur zu richten. Dabei spielt es keine Rolle, ob es sich um einen Bare-Metal-, containerisierten oder virtualisierten Server handelt.

Woher kommt Infrastructure as Code?

„Nur wer die Vergangenheit kennt, kann die Gegenwart verstehen und die Zukunft gestalten“ – August Bebel

Lass uns 15-20 Jahre in der Zeit zurückreisen und einen Blick auf Softwarefirmen wie Adobe, Atlassian oder Facebook werfen. Aus der heutigen Sicht sehr erfolgreiche Unternehmen. Doch auch diese haben einmal klein angefangen. Um ihre digitalen Produkte verkaufen zu können, betrieben sie erst einzelne Server und kamen mit wenig Hardware aus. Nach und nach wurden daraus kleinere Rechenzentren. Zunächst selbst betrieben, kaufte man sich später die Verwaltung und Hardware von anderen Dienstleistern ein. Mit den Jahren wuchs die Serverlandschaft in den Rechenzentren stetig weiter, um einen stabilen Betrieb für wachsende Nutzerzahlen gewährleisten zu können. Man unterschätzt vollkommen, wieviele Server nötig sind. So verkündete Facebook 2009, gerade 5 Jahre nach Start ihres sozialen Netzwerkes, dass sie mehr als 30.000 Server betrieben!

Provisionierung, Konfiguration & Deployment war mal ziemlich langsam

Selbst wenn eine Firma lediglich einige Dutzend Server bereitstellen muss, kommt es schnell zu organisatorischen Herausforderungen. Dies beginnt damit, dass beim Hochskalieren neue Server-Hardware bestellt und in den Serverräumen verbaut werden muss. Dazu gehört auch die Anbindung ans Netzwerk. Dank Cloud-Providern, wie beispielsweise AWS, Azure oder Google, ist dies heute mit einem geringeren Aufwand verbunden. Server sind schon Minuten nach der Bestellung über das Internet erreichbar. Ebenso können sie direkt konfigurativ an virtuelle Netzwerke, Loadbalancer, etc. … angebunden werden.

Doch nach dem Bereitstellen des blanken Servers ist man noch nicht fertig. Üblicherweise muss jeder Server zweckgebunden eingerichtet werden: Die Konfiguration beinhaltet zum Beispiel Benutzerverwaltung oder die Installation von Abhängigkeiten, wie Laufzeitumgebungen und sonstige Arbeiten, die später für den Betrieb der Software notwendig sind.

Ist ein Server einmal bereit, kann die eigentliche Software installiert werden. Ein solches Deployment passiert heute auch meist automatisch. Zumindest hat die DevOps-Bewegung klar gemacht, dass solche Prozessschritte idealerweise vollautomatisiert ablaufen sollten.

Das sind keine einmaligen oder seltenen Tätigkeiten. Bei einer größeren Landschaft werden ständig alte Server entfernt, neue hinzugefügt oder bestehende angepasst. So entsteht ein fast natürlicher Lebenszyklus von Servern.

Automatisierung gegen Fehler und Configuration Drift

Bei jedem neuen Server werden die oben beschriebene Schritte abgehandelt. Doch der Betrieb der „alten“ Server sowie die Weiterentwicklung der Produkte soll natürlich weitergehen. Durch den erheblichen Mehraufwand kann es ohne IaC dazu verführen, an Stelle eines neuen Servers, alte Server zu modifizieren oder zweckzuentfremden. Dabei kann es leicht passieren, dass aus einer „Testmaschine“ eine neue „Produktiv-Instanz“ gemacht wird. Manchmal müssen auch ganz dringend Laufzeitumgebungen verändert oder generell ein anderes Tooling installiert werden.

Solche nicht dokumentierten Ad-Hoc Änderungen führen langfristig immer zu Problemen. Man redet hierbei von einem „Configuration Drift“, also von dem Zeitpunkt, ab dem man von der Standardkonfiguration des Servers abweicht. Durch die lange Laufzeit der Server sammeln sich nach und nach immer mehr Altlasten an. Schritt für Schritt mutieren diese Server zu sogenannten Snowflake-Servern – jeder ein Unikat und damit fast unmöglich zu warten:

„The result is a unique snowflake – good for a ski resort, bad for a data center.“ – Martin Fowler

Aufgrund dieser Tatsache etablierte sich das Phoenix-Server-Pattern, welches diesem Umstand ein Ende setzen will. „Wie der Phoenix aus der Asche“, soll ein Server virtuell abgebrannt und in regelmäßigen Abständen neu aufgesetzt werden:

„A server should be like a phoenix, regularly rising from the ashes“ – Martin Fowler

Doch auch dies wäre ohne Automatisierung der Infrastruktur äußerst aufwendig. Früher versuchte man noch die Automatisierung mit Shell-Skripten abzubilden. Schnell wurde jedoch klar, dass diese Scripte durch ihre oftmals hohe Komplexität und die dadurch schlechte Portierfähigkeit auf die verschiedensten Serversysteme nicht das Mittel der Wahl sein konnten. 1993 dann wurde mit dem Projekt „CFEngine“ das erste IaC Tool entwickelt. CFEngine bietet eine vom Betriebssystem unabhängige Schnittstelle und abstrahiert damit die Unterschiede der verschiedenen Linux Distributionen. Mit seiner deklarativen und domänenspezifischen Beschreibungssprache vereinfacht das Tool die Konfiguration von Servern ungemein. Heute existieren viele ähnliche Lösungen, wie die nachfolgende Grafik beispielhaft zeigt:

All diese Tools versuchen durch die Automatisierung von Infrastruktur unter Zuhilfenahme von Prinzipien und Praktiken aus der Softwareentwicklung, dieses komplexe Unterfangen zu vereinfachen, zu beschleunigen und wartbar zu machen. Dabei spezialisieren sich die Tools auf verschiedene Phasen, welche wir dir nachfolgend genauer erläutern.

Die verschiedenen Phasen

Wenn man IaC anwendet, unterscheidet man zwischen zwei Phasen. Jede Phase deckt bestimmte Arbeiten ab:

Initiale Setup Phase
- Provisionierung der Infrastruktur
- Konfiguration der Infrastruktur
- Initiales Installieren von Software
- Initiale Konfiguration von Software
Maintaining Phase
- Anpassen der Infrastruktur
- Entfernen und Hinzufügen von Komponenten
- Software Updates
- Rekonfiguration von Software

Um es ein wenig zu abstrahieren, reden wir nachfolgend vom initialen Infrastruktur- sowie vom initialen Applikations Setup und deren Managements. Dies deckt dann die beiden Phasen komplett ab. Je nach Betrachtungsweise und Tool liegt eher die Infrastruktur- oder die Applikationsseite im Fokus. Docker beispielsweise wird vermehrt als eine Art Deployable verwendet, als wirklich als eine Infrastrukturkomponente, weswegen es im nachfolgenden Bild auf der rechten Seite angesiedelt ist. Die Grafik kann je nach Betrachtungswinkel immer wieder anders aussehen und repräsentiert derzeit nur unsere Sichtweise.

Die verschiedenen Arten von IaC

Es existieren die verschiedensten Arten von IaC. Jede bringt spezifische Vor- und Nachteile mit sich und so ist es je nach Anwendungsfall abzuwägen, welche Art von IaC gerade den größten Mehrwert generieren kann. Nachfolgend stellen wir dir die häufigsten Arten vor und reichern diese mit einem kleinen Codesnippet an.

Scripte

Der einfachste Weg, etwas zu automatisieren, ist das Schreiben eines Scripts. Dabei werden die Teilschritte, der sonst manuell durchgeführten Aufgabe, in der bevorzugten Skriptsprache abgebildet und danach in der Zielumgebung ausgeführt. Das nachfolgende Bash-Script installiert einen Webserver und startet diesen.

#!/bin/bash

# Update Package Manager
sudo apt-get update

# Install Apache
sudo apt-get install -y apache2

# Start Apache
sudo service apache2 start

Beliebte Skriptsprachen:

Konfigurations-Management Tools

Konfigurations-Management Tools sind dafür konzipiert, Software auf vorhandenen Servern zu installieren und zu verwalten. Hier ist zum Beispiel eine Ansible-Rolle, die denselben Apache-Webserver, wie das obige Bash-Skript, konfiguriert:

- hosts: apache
sudo: yes
tasks:
- name: install apache2
apt: name=apache2 update_cache=yes state=latest

Beliebte Konfigurations-Management Tools:

Templating Tools

Eine Alternative zu Konfigurations-Management Tools sind Templating Tools, wie Docker, Packer und Vagrant. Anstatt eine Reihe von Instanzen zu starten und sie durch Ausführen desselben Codes auf jedem einzelnen zu konfigurieren, besteht die Idee hinter Templating-Tools darin, ein Abbild zu erstellen. Diese „Momentaufnahme“ des Betriebssystems, der Software und jeglicher Dateien kann so als eigenständiges Artefakt in Form eines Images ausgeliefert werden. Hier ein Beispiel eines Dockerfiles als Template für ein Ubuntu-basiertes Image für einen Webserver:

FROM ubuntu:latest
RUN apt-get -y update &amp;&amp; \
    apt-get install -y apache2 
ENTRYPOINT ["/usr/sbin/apache2"]
CMD ["-D", "FOREGROUND"]

Orchestrierungs-Tools

Templating Tools eignen sich hervorragend für die Erstellung von VMs und Containern, aber wie kannst du diese effizient verwalten? An dieser Stelle kommen Tools wie Kubernetes, Amazon ECS, Docker Swarm oder Nomad ins Spiel. Da diese Tools sehr komplex sind und eine enorme Bandbreite an Funktionalität mit sich bringen, werden wir an dieser Stelle nicht tiefer auf die Funktionsweise eingehen. So kann das Verhalten eines Kubernetes-Clusters durch Code definiert werden. Das umfasst beispielsweise wie deine Docker-Container ausgeführt, wie viele Instanzen vorgehalten und wie bei einem Rollout vorgegangen werden soll.

Provisioning-Tools

Provisioning-Tools wie Terraform, AWS CloudFormation und Pulumi sind hauptsächlich für die Beschreibung und Erstellung von Cloud-Infrastruktur gedacht. Tatsächlich kannst du mit ihnen nicht nur Server, sondern auch Caches, Load Balancer, Firewall-Einstellungen, Routing-Regeln und so ziemlich jeder andere Aspekt einer IT-Infrastruktur erstellen. Oft greifen Konfigurations-Management oder Templating-Tools und Provisionierungs-Tools ineinander. So kann Terraform beispielsweise eine VM erstellen, die anschließend mit Puppet bespielt wird.

Fazit

Die Wahl zur passenden IaC Toolchain ist nicht einfach, da es keine pauschalen Antworten darauf gibt oder geben kann. Die Vorteile eines etablierten Konfigurations-Management-, Provisionierungs- und/oder Orchestrierungs-Tools sind nicht von der Hand zu weisen. Während der IaC-Ansatz seine Vorteile fast immer ausspielen kann, lohnt es sich bei kleinen Projekten nicht immer gleich zum mächtigen Orchestrierungs-Tool zu greifen. Hast du das Ziel klar definiert und möchtest eine der oben genannten Arten von IaC einführen, so kannst du dich gut an den Anforderungen des Gesamtzieles entlanghangeln und dann das richtige Tool-Setup zusammenstellen.

Mit diesem Überblick sollte es dir auf jeden Fall leichter fallen, die richtige Wahl für dein Projekt zu treffen. Sollten Fragen offen geblieben sein, dann stell diese doch bitte gleich in den Kommentaren. Gerne kannst du auch dein derzeitiges Setup in den Kommentaren vorstellen, wir sind sehr gespannt, welche und vorallem warum du auf folgendes Setup setzt.