Falk Dübbert IT

ein privates blog

16.06.18
von Falk Dübbert
Keine Kommentare

Businesskasparisierung, Hipsterkackscheiße, Klaut

Die neue CEBIT ist zuende gegangen. Sie sollte eine Messe mehr sondern ein “Event” sein, dass eine neue junge Zielgruppe anzieht.


Irgendwie hatte ich den Verdacht, dass bei allen Bildern von der Cebit irgendwo im Hintergrund jemand rumgeisterte und dafür sorgte, dass wenn männlich,weiß zu sehen war, dieser einen Hipsterbart trug.


Ich habe mir das Centrum für Büro- und Informationstechnik dieses Jahr nicht gegeben. Die Aussteller, die mich interessieren würden haben, entweder gute Roadshows oder sind schon ewig nicht mehr vor Ort. Dazu muss ich anmerken, dass meine Interessen fast nur im Bereich Storages, Backup, Infrastrukturausrüstung und Virtualisierung liegen.

Diese Hersteller sind fast vollständig weggeblieben und von denen, die vor Ort waren, erfuhr ich, dass nur wenig Leads auf der Messe erzeugt werden konnten.

Bei den Vortragsthemen “Digitalisiere Dich oder stirb!” kann ich auch nur noch  genervt schnauben.


Denn neben der Definitionsschwäche der BuzzWords erkennen immer mehr Firmen, dass die “Digitale Transformation” doch nicht die Antwort auf alles ist.


In kleinen Firmen sieht der Aufwand, um einen Service bereitzustellen so aus:

image

Bei sehr kleinen Umgebungen kann man das noch mit “dem Admin” regeln. In der Gedankenwelt der Businesskasparles sieht der Aufwand, um einen Cloud-Service bereitzustellen so aus:

image

Die Realität für selbst betriebene Anwendungen sieht in der Regel aber etwas komplexer aus:

image

Komplizierter wird es, wenn man die zuständigen internen Leute mit üblicher Funktionstrennung mit einblendet:


image


Jetzt kommt die Anwendung in die Cloud und viele Elemente müssen nicht mehr lokal vorgehalten werden.

image

Allerdings ist der Cloudanbieter für die roten Kästen und vieles andere nicht zuständig. Typischerweise geht die Anwenderzufriedenheit recht schnell talwärts, wenn wesentliche Bereiche nicht abgedeckt werden.

Die roten Kästchen mit externen aufzufüllen ist hingegen ziemlich teuer. Diese Lücken sind ein Grund, warum Cloud, genau wie Agile Methoden bei ungeeigneten Prozessen nur solange gut geht, wie man nicht die richtigen Fragen stellt.


Ich habe in letzter Zeit viele Firmen von innen gesehen und kann so viel sagen: das Klima ist in den “digitalisierten” mit non-territorialen Büroräumen und intensiver Cloudnutzung nicht das beste. Mitarbeiter erkennen schnell, wenn die achso informelle Collaboration Lounge doch nur eine andere Oberfläche ist und an die Stelle von eingesparten IT-Mitarbeitern der asiatische Großdienstleister mit Callcenter in Rumänien tritt. Dazu kommt natürlich der Gedanke, dass bei dieser Einsparung nicht Schluss sein wird. Ich komme nicht auf die Idee, die Verschwörung der BWLer gegen die Nerds zu behaupten, auch wenn diese Erklärung einfach und nahezu vollständig abdeckend wäre.


In den Zahlen sieht man diese Probleme über lange Zeit nicht. Das fehlende Customizing der ERP und BI wird in Excel nachgebildet. Wenn das Management Schatten-IT macht, ist nämlich gleich was anderes. Die Aufmerksamkeitsspanne von Managern ist eh zu kurz um langfristige Entwicklungen zu erkennen. Weil sie aber erstens ihre Fehler (Mitarbeiter als lästiges Übel betrachtet, Schund produziert, der nicht lange hält, Lösungen “in Software” gesucht) seit den 80ern nicht zu erkennen vermögen und selbst wenn den Gesichtverlust nicht ertragen könnten, wird jetzt digitalisiert und agilisiert.


Die Digitale Transformation ist jetzt in allen Firmen Chefsache mit Casual wear und Sitzkissen im Besprechungsraum.


Die Frage, die man sich immer stellen muss ist die, ob man am Ende mit so flachen Strukturen und, wie sie für Startupszenarien typisch sind wirklich arbeiten und produzieren möchte.
Das Mobiltelefon ersetzt den PC, die App das Programm, die Telco das Gespräch und die Cloud den Serverraum. Aber meiner Ansicht nach ist das nur eine Phase am Ende der Globalisierung. In nicht allzu langer Zeit wird man Produkte nur durch Exzellenz verkaufen. Zum einen kommt der Wandel dorthin aus den Rohstoffpreisen und zum Anderen aus den immer mehr gesättigten Märkten. Die pure tolle Idee wird für ein Produkt der näheren Zukunft also nicht mehr reichen.


Die CeBit, die sich 2003 gerade so eben von den peinlichen New-Economy Kasperletheatern losgesagt hatte, wurde nun also von den “Tsajkkaa Du Schafft es” zu den “Digitalisiere Dich!” - Sprechern getrieben.
Das Problem ist, dass die meisten Digitalisierungs-Päpste bereits mit dem Erklären eines Sampling-Theorems oder mit der Berechnung des Klirrfaktors einer ADA-Wandlung überfordert wären und das sonstige fachliche Niveau auch nicht höher liegt.
Jeder sieht die Probleme, viele können sie benennen, aber es schwingt auch immer die Angst vor dem Verlust mit.
Genau wie VW Gefangener der eigenen Motor-Expertise ist, sind “die Manager” Gefangene ihres Wachstum-Mantras und des Wandel Mantras. Ich glaube, dass das Zeitalter der bedingungslosen Globalisierung und Beschleunigung vorbei ist. Apple wird sein Spitzentelefon nur noch schleppend los, weil der Vorteil gegenüber einem nunmehr 4 Jahre alten iphone 6 eher in Marginalien stattfindet und ein altes iphone nicht mehr so stigmatisierend wirkt wie es 2012 der Fall war. Wobei Apple, was die Exzellenz der Produkte angeht relativ weit vorne mitspielt und auch Mut hat, für einen Fortschritt (auf Kosten der Kunden) ein Produkt in den Sand zu setzen. Haptik und Verarbeitungsqualität liegen dort schon relativ hoch. Ein knarzendes Gehäuse wie bei den ersten bunten iMacs wird man in apple-Produkten eher nicht mehr finden.

Ich sehe immer mehr Werbung für Produkte, bei denen die Werthaltigkeit und Nachhaltigkeit im Vordergrund steht.  Das kann natürlich Targeted Advertising in einer selbstverstärkenden Echokammer sein, aber auch in meinem professionellen Umfeld kommt es immer mehr auf handwerklich gute Lösungen an. Auch hier – wir reden eher von Rechenzentren als Serverräumen – ist es sicher nur ein Ausschnitt, in dem sauberes Arbeiten mit dem Buzzword “defensive computing” wieder chic ist, steht die Investitionssicherheit wieder mehr im Vordergrund. Der Kunde will für seine CapEx was haben, die kalkulierten Laufzeiten gehen wieder rauf und ein Hersteller, der mit Kostenpflicht für Updates nach drei Jahren die Server entwertet, muss nicht mit mehr Aufträgen rechnen. Insgesamt steigt das fachliche Niveau in allen möglichen Bereichen. Ein Cloud-Ansatz, der sauberes Arbeiten mit grenzenloser Skalierbarkeit zu ersetzen versucht, wurde nur kurz gefragt. Cloud wird eigentlich nur noch dort gewünscht, wo die Vorteile durch die Cloud an sich existieren. Eine typische In-Haus-App wie z.B. die FiBu oder ERP legt, spätestens seit dem 25.5. kein CIO bei Verstand in einer public Clod ab und auch die klassischen Tugenden wie Verfügbarkeit. die man im normalen Sprachgebrauch als “Zuverlässigkeit” bezeichnen würde, sind wieder ein hohes Gut geworden, während man sich vor zwei Jahren allein mit der Frage nach den variablen Kosten und der Verfügbarkeit ins alter-weißer-Mann-mit-Kugelschreiber-Aus geschossen hat.

27.05.18
von Falk Dübbert
Keine Kommentare

Failover-Konzept für den Webserver

Am Donnerstag hatte Hetzner auch mal erfahren, dass ein Notstromkonzept nur dann gut ist, wenn man es realistisch testet.

In der Regel werden die Notstromaggregate nur mit ihrer Führungslast getestet, das sind Heizwiderstände die 25% der berechneten Leistung aufnehmen. Eigentlich dienen diese dazu, dass die Stromerzeuger eine Last haben, die die Ausgangsgröße der Regelschleife dämpft und die Fenster für Frequenz und Spannung irgendwie über 10 Sekunden getroffen werden, so dass die Laderegler der USV wieder Strom in die Akkus füllen können.  

Irgendwie hat das alles nicht funktioniert und da es nun das sechste Rechenzentrum in meinem Dunstkreis ist, bei dem innerhalb eines halben Jahres das Notstromkonpzept versagt hat, habe ich mir ein paar Gedanken zu Redundanzen und Failover gemacht. 

Meine Server bei Hetzner sind Webserver und machen auch so etwas wie private Clouds. Die Clouds werden von ihren Anwendern als Backup- und Sync-Tool benutzt. Hier kann man ein paar Einschränkungen hinnehmen, aber einen Tag Business-Hours offline sein auf einer Homepage für einen Verein oder wie hier vier Vereine, löst zuverlässig Fragen nach der Zuverlässigkeit des Hosters aus, auch wenn die Server vorher 4 Jahre lang Tag und Nacht durchliefen. 

  1. Möglichkeit 1 wäre vom selbstbetriebenen Server zurück zu einem "Managed Hoster" zurückzukehren. Aber damit habe ich mir und im Vereinsumfeld einige andere sich schon öfter die Finger gebrochen. Apache-, Perl-, MySQL- und PHP-Upgrades ohne Vorwarnung oder Testmöglichkeit sind nicht das, was man in einem Wochenendprojekt haben will und waren der Grund den Server von der Hardware bis zum Joomla selbst in der Hand zu haben. 
    Aktuell kommt die Unsicherheit bei der Datenerfassung in Sachen DSGVO noch oben drauf. 
  2. Möglichkeit 2 wäre, im DNS einen C-NAME auf einen DDNS-Hostnamen einzutragen und von einem Failover-Host den ersten Host skriptbasiert zu pingen, wenn der Ping scheitert, zieht man den Hostnamen an sich und wäre wieder im Spiel. 
    Allerdings, muss ich zugeben, dass die Erhöhung des Abhängigkeiten-Baum doch recht abschreckend auf mich wirkt. Denn, damit dieses Konstrukt zuverlässig funktioniert, muss der DDNS-Dienstleister und mindestens einer der Webhosts funktionieren. Dazu müssen die Datenbanken der Foren- und Ticketsysteme synchronisiert werden. Für OTRS gibt es einige Beispiele die Server zu clustern, aber bei den Foren unterhalb von Joomla läuft das auf Datenbank-Matching hinaus. Das wäre mir schon von der Sicherheit her viel zu heiß.  
  3. Möglichkeit 3 wäre, einen Webserver "in der Cloud" einzurichten und auf den physischen Hosts nur die File-Clouds zu hosten, die in einer public Cloud zu teuer würden. Aber auch hier spricht die Mathematik dagegen. Bei Azure hatte ein DNS-Ausfall dieses Jahr für einen weltweiten Dienstausfall gesorgt. Bei AWS gibt es Regionen, deren AWS-Verfügbarkeit unter 99% liegen. Public Clouds sind in der Regel weniger leistungsfähig und weniger verfügbar als ein selbst betriebener Server - irgendwo muss die Einsparung ja herkommen -, aber das ist eine Erkenntnis, die bei COOs und CIOs nur sehr langsam durchsickert und selbst wenn, reicht ihnen als Argument die Verantwortung für die Wiederherstellung nicht mehr im eigenen Spielfeld zu haben. Daher pushen immer noch mehr Firmen in die Clouds als sich daraus zurückziehen. 

Mein aktueller Weg ist, den Backup-Server mit dem primären Host zu synchronisieren und beim nächsten Ausfall von Hand den DNS-Eintrag zu ändern. Eine Lösung, die einen manuellen Eingriff erfordert, wäre kommerziell nicht vermittelbar, aber so muss ich keine Status-Seite anbeten oder auf die Bearbeitung eines Ticket warten, sondern habe eine Handlungsoption.  

21.05.18
von Falk Dübbert
Keine Kommentare

Die Verschlüsselung ist doch nicht tot!

Momentan geht bei einigen Leuten in meinem Freundeskreis die Düse, weil "PGP und S-MIME gebrochen" wären. 

Zunächst mal die Verschlüsselung ist nicht gebrochen sondern die Online Nutzung von E-Mail-Programmen mit Verschlüsselung. 

  • Der Angreifer muss die zu entschlüsselnde Nachricht abgefangen oder extrahiert haben. 
  • Die Sicherheitslösung muss defekte Anhänge durchlassen.
  • Das verwendete E-Mail-Programm muss selbst http bzw. https-Verbindungen aufbauen können und dürfen. 
  • Das verwendete E-Mail-Programm muss so eingestellt sein, dass es den Schlüssel selbst anwenden darf.  

Da wird die Sache schon dünner:

  • Mein E-Mail-Provider nutzt Zertifikats-Pinning für seine SMTPs und bietet auch secure-DNS an. 
  • Alle Beispiel-Konstrukte von Schinzel et al schafften es nicht mal durch eine opensource eFa-Email-Sicherheitslösung.
    Barracuda, Sophos und Watchguard verwarfen die defekten Anhänge ebenfalls. 
  • Meine Email-Software darf nichts nachladen. 
  • Selbst mein stinkendes Outlook muss vor dem Entschlüsseln von Mails nach dem Passwort für den Schlüssel fragen. Ich weiß, dass diese Einstellung aufgrund des mangelnden Komforts selten lange durchhält, aber sie ist für Outlook 2007, 2010, 2011, 2013 und 2016 der Standard. 

Also ist E-Fail nur ein weiteres Brett für den Sarg von E-Mail an sich. Das Problem bei Email beginnt ja schon damit, dass sie eben nicht ohne externe Strukturen auskommt und keinen Schutz gegen Manipulation auf Protokollebene bietet.  

 

 

20.05.18
von Falk Dübbert
Keine Kommentare

Der Herr Backupexperte hat VOLL versagt!

Einige werden bemerkt haben, dass ein paar Artikel schwupps gegangen sind. Das liegt daran, dass ich zwei Tage in die Vergangenheit fliegen musste, weil ich um eine Kleinigkeit zu fixen meine Header-Datei in die Grütze manövriert habe. Da zeigte sich, dass ich ein Backup-Experte aber kein Restore-Experte bin. Weil der pending commit schon länger in der Datenbank rumlag, war der letzte lauffähige Stand der Freitag. Die fehlenden Artikel habe ich aus dem Editor hochgeladen.

Der Hintergrund war, dass ich dachte, dass ich im Zuge der DSGVO-Anpassungen irgendwie das Laden des Top Menüs zerbrochen hatte. Das war bislang typischerweise eine offene oder zuviel geschlossene Klammer oder eine TXP:else in einer TXP:IF, die nicht sauber geschlossen wurde. Aber selbst mit Hochladen der Stände von Freitag war da nix zu wollen. Wie sich herausstellte, war das Problem ganz woanders und lag mal wieder an partial cache-updates.

Jetzt sollte das Menü aber wieder zu 66% angezeigt werden.

Nebenbei habe ich das Textpattern auf Version 4.7.0 angehoben und LOG, TEMP und CACHE des NGINX auf eine Ramdisk verlegt. Roaring!

Das neue Textpattern geht mit CSS-Templates anders um, so dass ich vielleicht das eher krude von Wordpress portierte und 6 Jahre alte Yoko-Template loswerden kann. Wenn ich mal Zeit habe.

5.05.18
von Falk Dübbert
Keine Kommentare

Zu kurz!

Heute hat mein Testrack-Projekt kurz mal den Boden getroffen. Mein Rack ist, wie alle allten IT-Schränke zu kurz. Also muss ich was bauen. 

Boden: 2 Bretter OSB 
Front und Rückseite: Zwei Bretter je etwa 8cm breit
Deckel: Ein Brett OSB

Die senkrechten Kanten bekommen noch eine Latte (aus Holz!).

Dazu kommen noch Rollen und zwei Griffe. 

Die Maße lege ich nach, wenn ich die Rackprofile habe.  

3.05.18
von Falk Dübbert
Keine Kommentare

Testumgebung: Naming Scheme

Die vier (ja VIER) ESXi-Hosts werden die folgenden Namen haben:

  • 11-EX6H-Fire
  • 11-EX6H-Earth
  • 11-EX6H-Water
  • 11-EX6H-Air

Sollten es mehr werden, stelle ich auf Planeten (mit Pluto!) um.

Die Netze werden so benannt: 

  • Niflheim (NIF rot, VLAN 1 [native VLAN!!!]) - Internetseite der FW 
  • Muspelheim (MUS orange, VLAN 10) - DMZ 
  • Asgard (ASG blau, VLAN 11) - VSphere, Monitoring und Management
  • Midgard (MID grau VLAN 12) - internes Netz dauerhafter VMs und Systeme
  • Jotunheim (JOT grün, VLAN 13) - filebasierter Storage [NFS, SMB] und ISCSI für Midgard, Vanaheim, Alfheim und Svartalfheim
  • Vanaheim (VAN viollett, VLAN 100 bis 149) - Testumgebungen für Automatisierung etc.
  • Alfheim (ALF gelb, VLAN 150 bis 199) - Testumgebungen Management-Systeme 
  • Svartalfheim - (SVA braun, VLAN 200 bis 255) - Allgemeine Testumgebungen
  • Helheim - (HEL schwarz, VLAN 14) filebasiertes und highlevel Backup aus Midgard

Trunks werden mit weißen Kabeln übertragen. 

Die IPv4-Adressbereiche werden 10.VLAN.0.0 umfassen.
Planung bislang: Diese Adressen lege ich eiskalt auf mein IPv6-Prefix um, wobei ich allerdings jeder Karte quasi 10 Adressen gebe, damit ich für Down und Up getrennte Adressen erhalte. 

Firewallregeln werden dann Qellnetz-Zielnetz-Port-Protokoll-Grund als Namen haben: 

Zum Beispiel "MID001.012-NIF-443+8531-Windowsupdate" wäre die Portfreischaltung für die VM mit der IP 10.12.1.12 in MIDgard ins Internet. Außer in in den zweistelligen VLANs bekommen alle Rechner einen zusammengesetzten Namen aus

VLAN - Betriebssystem - Art des Systems - Nr als Chemisches Element.

OS-KürzelOS NameKürzelArt des Systems
WVPWindows Vista ProAPhysische Appliance z.B. eine Firewall
W07Windows 7PPhysischer Server
W10Windows 10DPhysischer Desktop
W08Windows Server 2008 R2SPhysischer SAN-Storage
W12Windows Server 2012 R2RPhysischer Einplatinencomputer
W16Windows Server 2016XPhysischer Switch
W03Windows Server 2003NNotebook oder Tablet
WXPWindows XPOVirtuelle Appliance
WESWindows 7 for Embedded SystemsVVirtuelle Maschine
W19Windows Server 2019QSmarthome oder IoT-Device
DEBDebian ab SqueezeMIndustrie4.0 Gerät oder Anlage
DE7 Debian bis WheezyUKamera, Alarmanlage 
COLCentOS Linux  HHost 
RH7RedHat 7   
RH6RedHat 6   
FB1Free BSD 11   
FB2Free BSD 12   
OB4Open BSD 4.x   
OB5Open BSD 5.x   
PFSpFsense   
ORLOracle Linux   
SE2Suse Enterprise 12   
EX5VMware ESXi 5   
EX6 VMware ESXi 6   
LNXanderes Linux   
ANDAndroid   
QT5QT5 z.B. in einer Busybox  
WITWindows 10 for IoT    
    
    
    
    
    
    
    
    
    

123W12V-Hydrogen wäre z.B. die erste VM im VLAN 123. 

In den zweistelligen VLANs sind die VMs und Geräte permanent und bekommen die Systeme Namen von nordischen Göttern in englischer Schreibweise. Ich kann ja schlecht in Asgard irgendwelche Griechen rumrennen lassen. 

IPv4-Bereiche teilte ich immer wie folgt:

octet + 1: Standardgateway / Firewall (ich bin von der "Gateway at the bottom"-Fraktion)

octet + 2...9: Netzwerkgeräte - VPN Gateway

octet + 10: DHCP + DNS; bei Windows: der Schemenmaster / erste DC

octet + 11...hälfte des Netzes: allgemeine Server

danach: Clients

Mit IPv6 ist die Sache DEUTLICH komplizierter. Ein Problem ist, dass IPv6 so etwas wie ein "privates Netzwerk" erst nicht, dann halbherzig und nun geflickschustert vorsieht. 
Die Netzkonzepte, die auf eine Perimeter-Zone setzen wie Edge-Core-Network oder Direct-Access, sind in IPv6 kaum oder nicht abbildbar.  

So nun zu den Fragen, die noch keiner gestellt hat:

Ich baue das Testrack nicht nur zum Testen und Lernen, sondern auch um PoCs abbilden zu können. Das geht zum Teil auch auf dem MacBook, aber mal so eben eine kleine Firma mit Schemenmaster, Fileserver und ERP mit Datenbanken abzubilden wird mit 16GB RAM schnell eng. 

Mit einer "richtigen" Lösung, die sich ISO-ähnlichen-Regeln unterwirft und deren VMs ausprechbare Namen haben, habe ich auch gleich sprechende Namen in den Screenshots ohne auf die Peanuts-Charaktere, ACME Corp oder die Contoso GmbH zurückgreifen zu müssen.    

Die Testumgebungen in Vanaheim, Alfheim und Svartalfheim werden sicher nicht alle parallel betrieben. Genaugenommen wird vermutlich immer nur eine oder zwei zur Zeit laufen. Die nächsten VMs ziehe ich dann im nächsten VLAN hoch. Gesichert wird aus den Testumgebungen nichts. Es sei denn, Backup ist Teil des Tests. Alle Skripte landen im GIT.

11.03.18
von Falk Dübbert
Keine Kommentare

Neu-Bestückung Testrack

Bislang habe ich mir beim Testen mit alten Notebooks und einem N54L beholfen. Sowas stößt natürlich schnell an seine Grenzen, wenn es darum geht eine ganze Serverlandschaft oder kompliziertere Setups und Prozesse zu testen. Das Testrack bzw. dessen Neubau steht schon länger auf der ToDo. Der Schrank hat 24Höheneinheiten und ist 86cm tief. 

Meiner alten Doktrin, möglichst wenige Sorten zu haben, sind alle Server HPE DL360 Generation 8 (Allerdings sind 3 Stück -p mit SFF und 2 Stück -e mit LFF), die ich trotz der Nachteile mit normalen U-DIMMs bestücke. Die Hosts haben, abweichend von einem produktiven Aufbau, lokalen Storage und nur Gigabit-Ethernet. 

Die Virtualisierung wird zunächst mit einer VSphere passieren, aber ich werde eine Möglichkeit einbauen, ein oder zwei Hosts auf Openstack umzuschalten oder nested Openstack-Hosts als VM laufen zu lassen. 

testrack

Folgende Dinge will ich mit dem Rack testen / lernen / ausprobieren: 

  • Defensive Computing
    Normalerweise ist ein Testrack nicht der Ort für defensives Computing, aber ich möchte das Testrack so betreiben, dass ich die Praktiken von dort jederzeit auf die produktiven Fragestellungen meiner Kunden abbilden kann. 
    Ich profitiere viel von meiner Erfahrung als Admin, Retter, Macher, Techniker und von meinem Ingenieur-Studium und kann meist gut einschätzen welchen Kompromiss man bei der Gestaltung von IT-Strukturen eingehen kann. Aber mittlerweile bin ich mir sehr sicher, dass man in der IT nicht mehr "pfuschen" kann. Der Haufen "Technical Debt", den man mit Pfusch ansammelt, hat die unangenehme Eigenschaft, dann zu brechen, wenn man es am allerwenigsten gebrauchen kann. IT-Abteilungen und ihre Budgets werden immer kleiner und Applikations-lastiger - damit wird man sich mit Blech, Storage oder Backup und Restore nicht befassen müssen wollen und sie dürfen einfach keine Probleme machen.
  • High-Efficiency Computing
    Das ist, wenn man Footprint-Minimalisierung im positiven Sinn auf die Spitze treibt. Also so arbeitet, wie man in den Achtzigern Computerspiele gemacht hat. Ich sehe, genau wie Tim O'Reilly den baldigen Peak Digital voraus. Alles wird komplexer, bis es einfacher wird. Aktuell haben wir enorm komplexe IT-Umgebungen. Durch die Clouds sind tausende Systeme beteiligt. Bislang ist es so, dass diese Komplexität nur selten bis zum Endkunden durchdringt, aber genau, wie wir bei der Mobilität über CO2 und Stickoxide nachdenken, wird man den Footprint von allem in der IT in den Griff bekommen müssen. 
  • Docker-Automation, Service-Bereitstellung mit Docker unter VMware
    Ich will mehr mit Automation im High-Level-Bereich testen. Meiner Ansicht nach, wird eine interne IT in Zukunft eher wie ein Hoster sein und die Anwendungsentwickler je nach Schutz-Bedarf, Last oder Lebensdauer des Services entscheiden, ob dieser On-Premise oder in einer Cloud gestemmt wird. Dabei ist dann entscheidend, dass diese Entscheidung nicht von einer fehlenden Schnittstelle eingeschränkt wird. 
  • Patching und Updates durch Erzeugen der VMs von gepatchten Templates und schnellen Deployment der Services. 
    Ich bin großer Anhänger von disposable IT. Wenn man das Vernichten seiner gesamten Struktur zum Teil des Prozesses macht, hat man zwangsläufig auch alle Prozesse im Blick. Wenn man zum Beispiel die Betriebssysteme neu erzeugt und anschließend automatisiert die Services darauf wiederherstellt, fällt die Pflicht zum Systembackup.  
  • Orchestrator-Skripte am Ticket-System
  • 360°-Monitoring inkl. Failover-Automation (ist mehr was zum Vorführen) 

Das Hauptproblem wird sein, dass, wenn das Rack fertig ist, es auf dem Dachboden zu heiß für dessen Betrieb ist.