Joachim Arrasz

Joachim Arrasz
Joachim Arrasz ist als Software- und Systemarchitekt in Karlsruhe bei der synyx GmbH & Co. KG als Leiter der CodeClinic tätig. Darüber hinaus twittert (@arrasz) und bloggt er gerne (http://blog.synyx.de/)
Beiträge dieses Autors

Eine kleine Reise durch NoSQL: NewSQL und Ausblick

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.

Eine kleine Reise durch NoSQL: Nach SQL kommt NoSQL

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.

Eine kleine Reise durch NoSQL

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.

Softwareprojekte vor dem Livegang: Production-ready?

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?

Die Kunst des Logging: Production ready?

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.

“Softwarearchitekten sind zu teuer, sowas muss ein erfahrenes Team selbst hinbekommen”

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”

"Modulare Anwendungen sind nur für größere Projekte gut – sonst lohnt sich der Mehraufwand nicht!"

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…

"Ein String ist immer ein String, oder doch ein Passwort?"

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. 

Modernes Tooling versus etablierte Best Practices

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.

Be pragmatic, not dogmatic! "Sitzen wir nicht alle im selben (Software)-Boot?"

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.

Be pragmatic, not dogmatic: Die zwei Gesichter der Agilität

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.

Be pragmatic, not dogmatic!

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!