\nDiese sind: Versionsverwaltung via Git, Deployment mittels Docker und Orchestrierung durch Kubernetes.<\/p>\n
![\"\"](\"https:\/\/www.f-i-ts.de\/blog\/wp-content\/uploads\/2020\/08\/Cloud-Native-\u00dcbersicht1.jpg\")
<\/a>Unsere FI-TS Finance Cloud Native unterst\u00fctzt agile Software-Entwicklung & DevOps auf Basis Kubernetes f\u00fcr Neuentwicklungen.<\/p><\/div>\n
<\/h2>\n
<\/p>\n
1. Kern-Element: Git
\nVersionsverwaltung f\u00fcr Entwicklung und Betrieb<\/strong><\/h2>\nIn den letzten Jahren hat Git allen anderen Versionsverwaltungssystemen den Rang abgelaufen.
\nAuch Anbieter wie Microsoft, die urspr\u00fcnglich eigene L\u00f6sungen hatten, haben ihre Tools und oft
\n(wie etwa auch im Fall von Microsoft) sogar den Konzern auf die Nutzung von Git umgestellt.<\/p>\n
Git wurde durch Linus Torvalds initiiert, und zwar um die Weiterentwicklung des Linux-Kernels besser steuern zu k\u00f6nnen. Da Linux seit jeher weltweit durch viele unabh\u00e4ngig Entwickler vorangetrieben wird, wurde gro\u00dfer Wert auf eine dezentrale Verwaltung der Software-Repositories gelegt, au\u00dferdem sollten eine sehr hohe Sicherheitsstufe
\n(um versehentliche sowie absichtliche Verf\u00e4lschungen zu vermeiden) und eine starke Effizienz gegeben sein. Urspr\u00fcnglich erfolgte der Austausch von \u00c4nderungen (Patches) \u00fcber Mailinglisten, doch bald verbreitete sich die Nutzung von Austauschplattformen wie GitHub, GitLab oder Bitbucket: Diese bieten neben der \u00fcbersichtlicheren Darstellung der Inhalte und \u00c4nderungen auch Workflow-Funktionen f\u00fcr die Zusammenarbeit.<\/p>\n
Inzwischen wird Git dabei nicht nur zur reinen Softwareentwicklung, sondern auch f\u00fcr das Management der Spezifikationen von \u201eInfrastructure as Code\u201c genutzt, also der automatischen Verwaltung und Bereitstellung technischer Komponenten via Rechenzentrum. Hier geht es um Werkzeuge, die nach einer Beschreibung des gew\u00fcnschten Zustands der Infrastruktur in Dateien (\u00e4hnlich dem Software-Quellcode) die technischen Komponenten automatisch konfigurieren, um den Zielzustand herzustellen. Wird dies mit den inzwischen g\u00e4ngigen Workflows im Git-Kontext kombiniert, spricht man \u00fcbrigens, angelehnt an den Begriff DevOps, auch von GitOps \u2013 ein Begriff, dessen Existenz ganz nebenbei auch belegt, wie g\u00e4ngig das Verfahren inzwischen ist.<\/p>\n
FI-TS ist in diesem Bereich l\u00e4ngst sehr erfahren:<\/strong> Wir betreiben seit einigen Jahren ein internes GitLab, und zwar f\u00fcr den Austausch zwischen den Entwicklern unserer Kunden oder externer Software-Lieferanten und unseren eigenen Entwicklern sowie f\u00fcr \u201eInfrastructure as Code\u201c. F\u00fcr die Verteilung der Software und die Herstellung des gew\u00fcnschten Zielzustands kommt derzeit meist Ansible zum Einsatz.<\/p>\n <\/p>\n
![\"\"](\"https:\/\/www.f-i-ts.de\/blog\/wp-content\/uploads\/2020\/08\/Cloud-Native-Git-1024x926.jpg\")
<\/a>Direkte Einblicke in das FI-TS GitLab.<\/p><\/div>\n
<\/h2>\n
<\/p>\n
2. Kern-Element: <\/strong>Docker-Container
\nLego-Bausteine f\u00fcr das Deployment der Anwendungen<\/strong><\/h2>\nDas zweite Kernelement ist Docker. Es ist ebenfalls schon seit einigen Jahren bei uns im Einsatz.
\nDocker erm\u00f6glicht das Verpacken von Anwendungen in sogenannte Docker-Images. Diese enthalten nicht nur die Anwendungsartefakte, sondern auch s\u00e4mtliche Bibliotheken \u2013 inklusive jener des Betriebssystems. Sie sind also stets in sich komplett und funktionieren. Ein weiterer Clou: Um die Erstellung der Images zu vereinfachen, k\u00f6nnen diese voneinander erben. So muss nicht f\u00fcr jede Software, die im Image konfiguriert werden soll, die Basis neu aufgesetzt werden, sondern es ist m\u00f6glich, diese zentral zu pflegen und dann nur noch die \u00c4nderungen zu speichern. Immer gilt dabei: Die Images werden nach Erstellung in einer Docker-Registry bereitgestellt, von der sie auf die eigentlichen Server heruntergeladen werden k\u00f6nnen.<\/p>\n
Der gro\u00dfe Vorteil von Docker ist, dass es ebenso flexibel wie einfach, ebenso \u00fcbersichtlich wie unabh\u00e4ngig funktioniert. Besonders hervorzuheben ist: Die Installation und der Start von Software werden deutlich unaufw\u00e4ndiger, da die Images auch alle Software-Komponenten beinhalten, die f\u00fcr die Installation notwendig sind. Nur dadurch kann man etwa zuverl\u00e4ssig davon ausgehen, dass die Konfiguration, die der Entwickler z. B. auf seinem Laptop erfolgreich getestet hat, auch auf dem Server im Rechenzentrum l\u00e4uft.<\/p>\n
<\/p>\n
3. Kern-Element: <\/strong>Kubernetes <\/strong>
\n<\/strong>Orchestrierungs-L\u00f6sung<\/strong><\/h2>\nNeu bei FI-TS ist das dritte Kernelement, es besteht in einem Service-Angebot, das durch Kubernetes umgesetzt wird: Kubernetes \u00fcbernimmt die automatische Verteilung der Container \u00fcber eine Server-Farm und sorgt dabei im Betrieb f\u00fcr eine effiziente Steuerung der Ressourcen und f\u00fcr Ausfallsicherheit.<\/p>\n
Urspr\u00fcnglich von Google entworfen, hat sich Kubernetes mittlerweile allgemein als De-facto-Standard in Cloud-Rechenzentren durchgesetzt. Damit kann die Technologie als zukunftssicher bezeichnet werden. Und dadurch sind auch Anwendungs-Umgebungen, die f\u00fcr ein automatisches Deployment auf dieser Plattform vorbereitet sind, vergleichsweise einfach zwischen Anbietern zu migrieren.<\/p>\n
Hinzu kommt: Der Kubernetes-Architektur ist deutlich anzumerken, dass sie bei einem der gro\u00dfen Cloud-Anbieter entwickelt wurde, sie ist sehr ausgereift und umfassend. Beispielsweise wurden Mechanismen zur Hochverf\u00fcgbarkeit komplett in die Software integriert. So wird es etwa m\u00f6glich, auf teure Enterprise-Hardware zu verzichten und stattdessen g\u00fcnstige x86-Hardware von nahezu beliebigen Herstellern zu verwenden, denn Kubernetes kompensiert die mit der kosteng\u00fcnstigeren Wahl \u00fcblicherweise einhergehenden Nachteile auf Ebene der Software.<\/p>\n
FI-TS hat diesen Paradigmenwechsel als Anlass daf\u00fcr genommen, eine komplett neue Umgebung im eigenen Rechenzentrum aufzubauen, die genau auf den Einsatz von Kubernetes im Bankenumfeld abgestimmt ist. In insgesamt drei FI-TS Rechenzentren wurden sogenannte \u201eCloud Native\u201c-Partitionen errichtet, in denen innerhalb weniger Minuten Netzsegmente und physische Server f\u00fcr den neuen Kubernetes-Service der FI-TS provisioniert werden k\u00f6nnen. Hierbei hat sich FI-TS dazu entschieden, auf Virtualisierung zu verzichten und stattdessen einen \u201eBare Metal\u201c-Ansatz f\u00fcr die Systeme zu verfolgen. Denn so l\u00e4sst sich eine besonders starke Trennung der verschiedenen Mandanten und Umgebungen realisieren. Dass wir hiermit gro\u00dfe Potenziale sinnvoll nutzen, ist leicht nachzuvollziehen: Der von uns verwendete Ansatz findet allgemein immer mehr Anklang im Markt. Kein Wunder, denn Komplexit\u00e4t und Kosten lassen sich vermeiden, unter anderem da viele Aufgaben, die bisher \u00fcber Virtualisierung-Software realisiert wurden, in Kubernetes zu integrieren sind.<\/p>\n
<\/p>\n
Die f\u00fcr die Server-Bereitstellung notwendige Steuerungssoftware wurde von FI-TS selbst entwickelt
\nund inzwischen als Open Source ver\u00f6ffentlicht. Details hierzu finden Sie auf der Metal-Stack-Webseite<\/a>.<\/p><\/blockquote>\nF\u00fcr jeden unserer Cloud-Services gilt: Er ist dynamisch, sicher und compliant.<\/p>\n
<\/p>\n
\nAuch Anbieter wie Microsoft, die urspr\u00fcnglich eigene L\u00f6sungen hatten, haben ihre Tools und oft
\n(wie etwa auch im Fall von Microsoft) sogar den Konzern auf die Nutzung von Git umgestellt.<\/p>\n
\n(um versehentliche sowie absichtliche Verf\u00e4lschungen zu vermeiden) und eine starke Effizienz gegeben sein. Urspr\u00fcnglich erfolgte der Austausch von \u00c4nderungen (Patches) \u00fcber Mailinglisten, doch bald verbreitete sich die Nutzung von Austauschplattformen wie GitHub, GitLab oder Bitbucket: Diese bieten neben der \u00fcbersichtlicheren Darstellung der Inhalte und \u00c4nderungen auch Workflow-Funktionen f\u00fcr die Zusammenarbeit.<\/p>\n
<\/p>\n
<\/a>Direkte Einblicke in das FI-TS GitLab.<\/p><\/div>\n
<\/h2>\n
<\/p>\n
2. Kern-Element: <\/strong>Docker-Container
\nLego-Bausteine f\u00fcr das Deployment der Anwendungen<\/strong><\/h2>\nDas zweite Kernelement ist Docker. Es ist ebenfalls schon seit einigen Jahren bei uns im Einsatz.
\nDocker erm\u00f6glicht das Verpacken von Anwendungen in sogenannte Docker-Images. Diese enthalten nicht nur die Anwendungsartefakte, sondern auch s\u00e4mtliche Bibliotheken \u2013 inklusive jener des Betriebssystems. Sie sind also stets in sich komplett und funktionieren. Ein weiterer Clou: Um die Erstellung der Images zu vereinfachen, k\u00f6nnen diese voneinander erben. So muss nicht f\u00fcr jede Software, die im Image konfiguriert werden soll, die Basis neu aufgesetzt werden, sondern es ist m\u00f6glich, diese zentral zu pflegen und dann nur noch die \u00c4nderungen zu speichern. Immer gilt dabei: Die Images werden nach Erstellung in einer Docker-Registry bereitgestellt, von der sie auf die eigentlichen Server heruntergeladen werden k\u00f6nnen.<\/p>\n
Der gro\u00dfe Vorteil von Docker ist, dass es ebenso flexibel wie einfach, ebenso \u00fcbersichtlich wie unabh\u00e4ngig funktioniert. Besonders hervorzuheben ist: Die Installation und der Start von Software werden deutlich unaufw\u00e4ndiger, da die Images auch alle Software-Komponenten beinhalten, die f\u00fcr die Installation notwendig sind. Nur dadurch kann man etwa zuverl\u00e4ssig davon ausgehen, dass die Konfiguration, die der Entwickler z. B. auf seinem Laptop erfolgreich getestet hat, auch auf dem Server im Rechenzentrum l\u00e4uft.<\/p>\n
<\/p>\n
3. Kern-Element: <\/strong>Kubernetes <\/strong>
\n<\/strong>Orchestrierungs-L\u00f6sung<\/strong><\/h2>\nNeu bei FI-TS ist das dritte Kernelement, es besteht in einem Service-Angebot, das durch Kubernetes umgesetzt wird: Kubernetes \u00fcbernimmt die automatische Verteilung der Container \u00fcber eine Server-Farm und sorgt dabei im Betrieb f\u00fcr eine effiziente Steuerung der Ressourcen und f\u00fcr Ausfallsicherheit.<\/p>\n
Urspr\u00fcnglich von Google entworfen, hat sich Kubernetes mittlerweile allgemein als De-facto-Standard in Cloud-Rechenzentren durchgesetzt. Damit kann die Technologie als zukunftssicher bezeichnet werden. Und dadurch sind auch Anwendungs-Umgebungen, die f\u00fcr ein automatisches Deployment auf dieser Plattform vorbereitet sind, vergleichsweise einfach zwischen Anbietern zu migrieren.<\/p>\n
Hinzu kommt: Der Kubernetes-Architektur ist deutlich anzumerken, dass sie bei einem der gro\u00dfen Cloud-Anbieter entwickelt wurde, sie ist sehr ausgereift und umfassend. Beispielsweise wurden Mechanismen zur Hochverf\u00fcgbarkeit komplett in die Software integriert. So wird es etwa m\u00f6glich, auf teure Enterprise-Hardware zu verzichten und stattdessen g\u00fcnstige x86-Hardware von nahezu beliebigen Herstellern zu verwenden, denn Kubernetes kompensiert die mit der kosteng\u00fcnstigeren Wahl \u00fcblicherweise einhergehenden Nachteile auf Ebene der Software.<\/p>\n
FI-TS hat diesen Paradigmenwechsel als Anlass daf\u00fcr genommen, eine komplett neue Umgebung im eigenen Rechenzentrum aufzubauen, die genau auf den Einsatz von Kubernetes im Bankenumfeld abgestimmt ist. In insgesamt drei FI-TS Rechenzentren wurden sogenannte \u201eCloud Native\u201c-Partitionen errichtet, in denen innerhalb weniger Minuten Netzsegmente und physische Server f\u00fcr den neuen Kubernetes-Service der FI-TS provisioniert werden k\u00f6nnen. Hierbei hat sich FI-TS dazu entschieden, auf Virtualisierung zu verzichten und stattdessen einen \u201eBare Metal\u201c-Ansatz f\u00fcr die Systeme zu verfolgen. Denn so l\u00e4sst sich eine besonders starke Trennung der verschiedenen Mandanten und Umgebungen realisieren. Dass wir hiermit gro\u00dfe Potenziale sinnvoll nutzen, ist leicht nachzuvollziehen: Der von uns verwendete Ansatz findet allgemein immer mehr Anklang im Markt. Kein Wunder, denn Komplexit\u00e4t und Kosten lassen sich vermeiden, unter anderem da viele Aufgaben, die bisher \u00fcber Virtualisierung-Software realisiert wurden, in Kubernetes zu integrieren sind.<\/p>\n
<\/p>\n
Die f\u00fcr die Server-Bereitstellung notwendige Steuerungssoftware wurde von FI-TS selbst entwickelt
\nund inzwischen als Open Source ver\u00f6ffentlicht. Details hierzu finden Sie auf der Metal-Stack-Webseite<\/a>.<\/p><\/blockquote>\nF\u00fcr jeden unserer Cloud-Services gilt: Er ist dynamisch, sicher und compliant.<\/p>\n
<\/p>\n
\nDocker erm\u00f6glicht das Verpacken von Anwendungen in sogenannte Docker-Images. Diese enthalten nicht nur die Anwendungsartefakte, sondern auch s\u00e4mtliche Bibliotheken \u2013 inklusive jener des Betriebssystems. Sie sind also stets in sich komplett und funktionieren. Ein weiterer Clou: Um die Erstellung der Images zu vereinfachen, k\u00f6nnen diese voneinander erben. So muss nicht f\u00fcr jede Software, die im Image konfiguriert werden soll, die Basis neu aufgesetzt werden, sondern es ist m\u00f6glich, diese zentral zu pflegen und dann nur noch die \u00c4nderungen zu speichern. Immer gilt dabei: Die Images werden nach Erstellung in einer Docker-Registry bereitgestellt, von der sie auf die eigentlichen Server heruntergeladen werden k\u00f6nnen.<\/p>\n
\n<\/strong>Orchestrierungs-L\u00f6sung<\/strong><\/h2>\n
Neu bei FI-TS ist das dritte Kernelement, es besteht in einem Service-Angebot, das durch Kubernetes umgesetzt wird: Kubernetes \u00fcbernimmt die automatische Verteilung der Container \u00fcber eine Server-Farm und sorgt dabei im Betrieb f\u00fcr eine effiziente Steuerung der Ressourcen und f\u00fcr Ausfallsicherheit.<\/p>\n
Urspr\u00fcnglich von Google entworfen, hat sich Kubernetes mittlerweile allgemein als De-facto-Standard in Cloud-Rechenzentren durchgesetzt. Damit kann die Technologie als zukunftssicher bezeichnet werden. Und dadurch sind auch Anwendungs-Umgebungen, die f\u00fcr ein automatisches Deployment auf dieser Plattform vorbereitet sind, vergleichsweise einfach zwischen Anbietern zu migrieren.<\/p>\n
Hinzu kommt: Der Kubernetes-Architektur ist deutlich anzumerken, dass sie bei einem der gro\u00dfen Cloud-Anbieter entwickelt wurde, sie ist sehr ausgereift und umfassend. Beispielsweise wurden Mechanismen zur Hochverf\u00fcgbarkeit komplett in die Software integriert. So wird es etwa m\u00f6glich, auf teure Enterprise-Hardware zu verzichten und stattdessen g\u00fcnstige x86-Hardware von nahezu beliebigen Herstellern zu verwenden, denn Kubernetes kompensiert die mit der kosteng\u00fcnstigeren Wahl \u00fcblicherweise einhergehenden Nachteile auf Ebene der Software.<\/p>\n
FI-TS hat diesen Paradigmenwechsel als Anlass daf\u00fcr genommen, eine komplett neue Umgebung im eigenen Rechenzentrum aufzubauen, die genau auf den Einsatz von Kubernetes im Bankenumfeld abgestimmt ist. In insgesamt drei FI-TS Rechenzentren wurden sogenannte \u201eCloud Native\u201c-Partitionen errichtet, in denen innerhalb weniger Minuten Netzsegmente und physische Server f\u00fcr den neuen Kubernetes-Service der FI-TS provisioniert werden k\u00f6nnen. Hierbei hat sich FI-TS dazu entschieden, auf Virtualisierung zu verzichten und stattdessen einen \u201eBare Metal\u201c-Ansatz f\u00fcr die Systeme zu verfolgen. Denn so l\u00e4sst sich eine besonders starke Trennung der verschiedenen Mandanten und Umgebungen realisieren. Dass wir hiermit gro\u00dfe Potenziale sinnvoll nutzen, ist leicht nachzuvollziehen: Der von uns verwendete Ansatz findet allgemein immer mehr Anklang im Markt. Kein Wunder, denn Komplexit\u00e4t und Kosten lassen sich vermeiden, unter anderem da viele Aufgaben, die bisher \u00fcber Virtualisierung-Software realisiert wurden, in Kubernetes zu integrieren sind.<\/p>\n
<\/p>\n
Die f\u00fcr die Server-Bereitstellung notwendige Steuerungssoftware wurde von FI-TS selbst entwickelt
\nund inzwischen als Open Source ver\u00f6ffentlicht. Details hierzu finden Sie auf der Metal-Stack-Webseite<\/a>.<\/p><\/blockquote>\nF\u00fcr jeden unserer Cloud-Services gilt: Er ist dynamisch, sicher und compliant.<\/p>\n
<\/p>\n