Infrastruktur ≠ Entwickler – Was brauche ich on-premise für ein Cloud-Erlebnis?
Dienste zu konsumieren ist im Jahr 2018 nichts Besonderes mehr. Musik wird online gestreamt, Filme werden über Abos gebucht, Hotelportale werden betrieben ohne ein einziges Zimmer zu besitzen und selbst Zahnpasta kann ich mir online über Portale automatisiert zukommen lassen.
IT zu konsumieren ist daher nicht weit hergeholt und auch die Grundzüge für IT-as-a-Service sind nicht neu und bereits mehrere Jahre alt. Was sich in den letzten 24-48 Monaten allerdings verändert hat, ist die Tatsache, dass nicht die IT entscheidet, was einem Endanwender zur Verfügung gestellt wird, sondern der Endanwender entscheidet, wo er sich welche Dienste einkauft. Kreditkarten und häufig flexible Abrechnungsmodelle innerhalb von Fachabteilungen machen es möglich und somit geht ein nicht unerheblicher Teil des Geschäfts an der IT vorbei.
Was brauche ich also aus Sicht der IT, damit Entwickler sich inhouse wohlfühlen und die eigenen Dienste konsumieren ohne Einbußen bei ihrer Haupttätigkeit, dem Entwickeln, zu haben?
Salopp gesagt: Ich muss 1:1 das anbieten, was für die Entwicklung einer Applikation benötigt wird… Jetzt wird es in vielen Fällen schon etwas komplizierter.
Ich brauche also riesige Rechenzentren, hochautomatisiert, und muss alle Dienste, die weltweit am Markt sind, implementieren?!?!
Die simple Antwort dafür ist: Vielleicht 😉
Wenn man sich mit den Grundzügen der Automatisierung beschäftigt hat, wird man recht schnell feststellen, dass es Dienste gibt, die man problemlos abdecken kann und solche, die erhebliches Engineering bedeuten.
Es stellt sich also wieder mal die Frage: Womit fange ich an? Ab wann sagt ein Entwickler: Ich brauche keine Public Cloud mehr?
Aus der Sicht eines Entwicklers, der zu 90% wenig Ahnung von Infrastruktur hat, gibt es ein Grundbedürfnis: Software entwickeln! Klingt eigentlich recht unspannend, ist aber ziemlich treffend zur Jobbeschreibung.
Wie schreiben eigentlich Softwareentwickler ihren Code?
Da gilt wieder: Viele Wege führen nach Rom. Im Prinzip sind aber nur die Werkzeuge unterschiedlich und der Ansatz ist in den meisten Fällen ziemlich gleich. Als Medium werden primär Entwicklungsumgebungen verwendet, die je nach Programmiersprache unterschiedlich sind.
Wenn ein klassischer Java Entwickler eher Eclipse, IntelliJ IDEA oder NetBeans bevorzugt, agiert ein Ruby Entwickler häufig mit VIM oder JetBrains. Es gibt also Unterschiede welche Umgebung verwendet wird. Am Ende des Tages ist Rom das Ziel und das bedeutet: Ich will Bytecode auf einem Betriebssystem ausführen und eine Applikation zum Laufen bringen!
Aus Infrastruktursicht muss ich mir also die Frage stellen: Wie stelle ich das alles in nahezu Echtzeit bereit?
Cisco bietet dafür das nötige Werkzeug. Mit CloudCenter sind wir in der Lage einem Entwickler genau diese Development-Ansicht zu ermöglichen. Der Administrator hat dabei weiterhin die volle Kontrolle über die Infrastruktur und kann gemeinsam nach DevOps Prinzipien mit den Entwicklern an der Infrastruktur arbeiten. Ein möglicher Ansatz ist in der folgenden Abbildung dargestellt:
Der Entwickler muss also lediglich seinen Sourcecode herunterladen, ihn bearbeiten und am Ende wieder hochladen. Das alles kann er aus seiner Entwicklungsumgebung machen und somit hat er keine Berührungspunkte zur Infrastruktur. Klingt irgendwie nach Public Cloud on-premise oder?
Ist es auch!
Tags:
