In Zeiten immer kleiner werdender und schneller evolutionierender Softwaresysteme rückt ein bislang eher stiefmütterlich betrachteter Arbeitsteil eines Entwicklungsteams mehr und mehr in den Fokus: der stabile Softwarebetrieb.

Bisher haben wir NoSQL-Datenbanken und ihre junge Evolutionsgeschichte betrachtet. Wir haben Parallelen zur Entwicklung der relationalen Systeme aufgezeigt und NoSQL-Systeme gemäß der üblichen Klassifikation diskutiert. Dieser dritte und letzte Teil unserer kleinen Reise greift einige Punkte noch einmal auf, um aktuelle Trends zu beleuchten. Wir schauen insbesondere auf Multi-Modell-Datenbanken und NewSQL-Systeme. Abschließend wagen wir ein paar Thesen über mögliche Entwicklungen in der nahen und mittelfernen Zukunft.

Die Welt der Speichertechnologien befindet sich momentan im Umbruch. NoSQL-Datenbanken adressieren Probleme, für die relationale Datenbanken nicht geeignet sind. Wir werden hierauf dezidierter eingehen. Die Lösungsmechanismen der NoSQL-Datenbanken kommen allerdings nicht ohne Nebeneffekte daher. Wir wollen Parallelen zu den Entwicklungen ab den 1970er Jahren aufzeigen und versuchen zu motivieren, dass aus diesen Entwicklungen gelernt werden kann.

Not only SQL, kurz NoSQL, ist eine noch relativ junge Disziplin der Informatik, die sich mit Datenspeicherungstechnologien beschäftigt. NoSQL befindet sich in beständigem Wandel, was es schwer macht, eine strenge Definition zu geben. In dieser dreiteiligen Artikelserie wollen wir versuchen, die bisherige Entwicklung in groben Zügen nachzuvollziehen. Wir beginnen mit einem Rückblick auf die relationalen Datenbanksysteme.

Nachdem wir im ersten Teil der Serie „Production-ready?“ darauf abzielten, den Entwicklern aufzuzeigen, wie sie dem Betrieb das Leben einfacher machen können, und im zweiten Teil die Vorbereitungen des Betriebs besprochen wurden, wollen wir uns in diesem letzten Teil der Miniserie dem Thema Produktion widmen. Wie können die gesammelten Produktionsdaten der Entwicklung weiterhelfen?

Im ersten Teil dieser Serie ging es um das Zusammenspiel zwischen Entwicklern und Betreibern rund um das Themengebiet des Loggings, und wir konnten aufzeigen, wie wichtig es bereits während der Entwicklung ist, gemeinsam zu arbeiten und sich abzustimmen. Dieses Mal werden wir uns mit der Phase der Produktionsvorbereitung beschäftigen. Die Entwicklung hat die benötigen Features und Storys umgesetzt und bereitet sich nun auf die Produktion vor. Was muss ein Team in dieser Situation leisten, um sicherstellen zu können, dass alle relevanten Schrauben korrekt sitzen? Welche Themen müssen berücksichtigt werden, und welche Tools kann man zur Unterstützung einsetzen?

Reactive Programming, Microservices, Message-oriented Middleware und andere moderne Architekturansätze fordern von Entwicklern heutzutage bei der Auswahl ihrer Tools mehr Weitblick, mehr (Ein-)Blick in die Produktion und deren Anforderungen, als noch vor einigen Jahren. Alle diese Ansätze bringen üblicherweise die Möglichkeit einer besseren Verteilung der gesamten Anwendung mit sich. Dies hat aber beträchtliche Auswirkungen auf den Betrieb von Anwendungen dieser Art.

Dogmatismus wie auch Pragmatismus werden oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen und hoffentlich spannend diskutieren. Heute geht es um die beiden Haltungen: “Softwarearchitekten sind zu teuer, sowas muss ein erfahrenes Team selbst hinbekommen” vs. ­“Mein Team soll seine Fachdomäne verstehen und muss keine Technologie-Experten hervorbringen”

Im letzten Teil der Kolumne Be pragmatic, not dogmatic! haben wir über typsichere Schnittstellen, deren Vorteile aber auch deren Nachteile gesprochen. Dabei wurde festgestellt, dass die Homogenität der Systeme das wichtigste Entscheidungskriterium ist und es deshalb wohl keinen goldenen Weg geben kann. 

In diesem Teil werde ich ein Dilemma besprechen, welches mir seit Jahren immer wieder begegnet: die Tatsache, dass Systemgrenzen nicht erkannt oder aber nicht eingehalten werden. Wer kennt das nicht: Man schaut sich eine Software an und stellt fest, dass man eigentlich drei unterschiedliche Systeme in einem vor sich hat…

Im letzten Teil der Kolumne „Modernes Tooling versus etablierte Best Practices“ ging es um die Einsatzgebiete und den Sinn sogenannter Blueprint-Architekturplänen in Firmen. Blueprints schaffen einheitliche Systemumgebungen, die schnell und effizient pflegbar und wartbar sind. Allerdings schaffen sie auch Entwicklungszyklen, die merklich langsamer und auch weniger agil sind. Man spannt den Bogen also entweder bei den Entwicklern oder aber im Betrieb ein wenig mehr. 😉

In diesem Teil werde ich ein technisches, eigentlich sehr einfaches, aber doch spannendes Thema, welches mich die letzten 10 Jahre immer wieder anstrengt, diskutieren: Vorteile und Nachteile von typsicheren Schnittstellen. 

Dogmatismus als auch Pragmatismus werden oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen und hoffentlich spannend diskutieren.

Im letzten Teil der Kolumne „Be pragmatic, not dogmatic!“ wurde diskutiert, inwiefern sich die Meinungen von Sponsor und Entwicklungsteam zum Thema Test, Stage oder Production-Deployments unterscheiden. Dieses Mal wollen wir die Differenzen zwischen Entwicklungsteam und betreuendem Maintenance-Team beleuchten. Es geht um die Einhaltung von Prozessen und Zuständigkeitsgrenzen bei kritischen Produktionszuständen.

Dogmatismus wie auch Pragmatismus werden oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen und hoffentlich spannend diskutieren.

Im letzten Teil der Kolumne ging es um Dogmen versus pragmatisches Vorgehen bei der Einhaltung von Architekturvorgaben. Doch Dogmen als auch pragmatisches Vorgehen finden sich nicht nur in der Implementierung der Entwicklung wieder, sondern auch in den Prozessen rund um die Entwicklung! Steigen wir also in den zweiten, dieses Mal nicht sonderlich entwicklungslastigen Erfahrungsbericht ein.

Dogmatismus wie auch Pragmatismus wird oft als Ausrede für verschiedene Unarten innerhalb der Softwareentwicklung genutzt. In dieser Kolumne wollen wir verschiedene Beispiele für beides vorstellen – und hoffentlich spannend darüber diskutieren!