Headerbild

eBizTalk - Berichten, Unterhalten, Weiterbilden

Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

API Management - Teil 5 - Provisionierung

Veröffentlicht am 30.09.2020 von Hieronymus Deutsch , APIM

Dieser Artikel ist Teil einer Serie zum Thema API Management in großen Unternehmen. Ziel ist es, meine Sicht auf verschiedene Themen zu teilen und die Komplexitäten aufzudecken. In diesem Artikel werde ich Fragestellungen behandeln, die mit der Provisionierung von API Management und APIs zu tun haben. Hierfür nehme ich mir Azure API Management als Beispiel.


Viele Möglichkeiten ein API Management zu provisionieren

Wenn man ein API Management aufsetzen möchte, hat man folgende Möglichkeiten das zu erreichen.

  • Manuell über das Azure Portal
  • Mit PowerShell
  • Über die CLI
  • Mit Hilfe vom Azure Ressource Manager (ARM)
  • Terraform & Ähnlich
  • u.v.m.

Welcher Weg jedoch derjenige ist, der für den Anwendungsfall am Sinnvollsten ist, hängt zu 100% davon ab wie das API Management in Zukunft verwendet werden soll. Hierzu empfehle ich auch Teil 4 von dieser Serie zu lesen. Um die Richtige Entscheidung zu treffen, sollte man sich zu den folgenden Anforderungen eine Antwort suchen:

  • Wie wichtig ist ein schnelles Desaster-Recovery?
  • Werden mehrere Teams das APIM nutzen?
  • Gibt es ein Team, welches die Zuständigkeit inne hat?
  • Brauchen Änderungen am APIM ein vorheriges Approval?
  • Gibt es mehrere Umgebungen (dev, test, prod), die identisch konfiguriert sein müssen?


To IaC or not to IaC

IaC (Infrastructure as Code) ermöglicht, eine gesamte Infrastrukturarchitektur durch die Ausführung eines Skripts zu beschleunigen. Nicht nur können virtuelle Server bereitgestellt werden, sondern auch vorkonfigurierte Datenbanken, Netzwerkinfrastrukturen, Speichersysteme, Lastausgleiche und vieles mehr.


All das kann schnell und einfach für Entwicklungs-, Test- und Produktionsumgebungen konfiguriert werden, was den Softwareentwicklungsprozess wesentlich effizienter machen kann. Außerdem können problemlos Standardinfrastrukturumgebungen in anderen Projekten wiederverwendet werden.

Die Möglichkeit eine gesamte Infrastruktur durch Ausführung eines Skripts zu konfigurieren ist ein großer Vorteil für die, die ein gutes Desaster Recovery benötigen.

Für Hackathons und kleinere Hobby-projekte ist die Komplexität der Konfiguration und auch die organisatorische Hürde sehr gering. Das verleitet gerne dazu, die Cloud-infrastruktur manuell aufzusetzen. Das ist vielleicht für das eine Projekt auch ausreichend. Trotzdem empfehle ich auch hier die Verwendung von IaC. Der Grund dafür ist, dass die meisten Architekturen auf die ein oder andere Weise wiederverwendet werden. Ein Lösung, die im Hackathon entwickelt wurde findet häufig auch Anwendung in der Organisation.

Ich empfehle generell die Verwendung von Provisionierungs-Automatisierung. Für große Unternehmen ist der Nutzen nicht wegzudenken und mitigiert viele Risiken. Desasterf Recovery ist hier vielleicht das offensichtlichste Beispiel. Ein weiteres ist jedoch auch der Transfer von Wissen und Knowhow. Es wäre schlecht, wenn das Wissen über die Konfiguration der Infrastruktur zusammen mit dem Mitarbeiter die Firma verlässt.


Organisatorische Bedenken

Im vorangehenden Kapitel habe ich meine klare Empfehlung ausgesprochen IaC zu verwenden. In großen Firmen, die aus verschiedenen Gründen die einfachsten Sicherheitsanforderungen an die Infrastruktur generell haben, sind beim Einsatz von IaC jedoch einige Dinge zu beachten.

Viele Firmen haben mehrere IT-Entwicklungsprojekte und Teams. Die Frage ergibt sich also in wie weit diese Teams die gleichen Komponenten der Infrastruktur wiederverwenden dürfen, sollten oder können. Ein Team- und Projektübergreifendes API Management zum Beispiel stellt klare Fragen an die Sicherheit. Aber wie viel Kontrolle erhalten die einzelnen Teams auf das API Management? Wie verhindert man, dass Teams sich nicht gegenseitig Probleme bereiten?

Im Folgenden möchte ich 4 Möglichkeiten aufzeigen, die in 1000 Metern Höhe beschreiben, wie API Management in den verschiedenen Teams verwendet werden könnte.

Im ersten und einfachsten Fall verwendet jedes Entwicklungsteam sein eigenes API Management, welches durch das IaC-Tool der Wahl provisioniert wird. Es kann nur das zuständige Team die Konfiguration des API Managements ändern und ist somit auch zu 100% zuständig für die Prozesse die damit einhergehen. Ein Vorteil von dieser Struktur ist, dass Teams sehr unabhängig agieren können, was die Entwicklungsgeschwindigkeit erhöht.

Abbildung 1: Infrastruktur Entwicklungsprozess in unabhängigen Teams

Wenn sich die Organisation dazu entschieden hat, das API Management zu zentralisieren, um zum Beispiel zentrale Kontrolle über die Sicherheitsmaßnahmen und Zugriffssteuerung zu haben oder einfach im Budget einzusparen, dann stellt sich die Frage wie die Entwicklung und Provisionierung des API Managements dann vonstatten geht.

Hier gibt es mehrere Möglichkeiten.

  • Man erlaubt den Teams, ähnlich einer open-source Lösung, an der gemeinsamen Konfiguration des API Managements mitzuwirken.
  • Man erlaubt es ihnen, APIs in ein bestehendes APIM direkt zu provisionieren.
  • Man erlaubt es nur indirekt über eine API die Provisionierung von APIs.

Welche dieser Möglichkeiten die richtige ist hängt von den Anforderungen ab und ist auch zum großen Teil Geschmacksache. Erlauben die Sicherheitsanforderungen es, dass Teams die Definition von APIs der jeweils anderen sehen dürfen? In welchem Ausmaß haben die Teams die Kontrolle über eigene APIs und dürfen von den Funktionalitäten des API Managements Gebrauch machen?

Möglichkeit 1 bedeutet, dass die gesamte Konfiguration vom API Management in, zum Beispiel, einem Git-repository liegt, auf das  die Teams Zugriff haben. Jedes Team würde im Laufe seiner Entwicklungsphasen Änderungen des API Management vorschlagen. Eine Änderung könnte beinhalten, eine weitere API hinzuzufügen oder zu entfernen, könnte aber auch beinhalten, dass bestimmte Protokolle oder Zertifikate verwendet werden müssen. Team A, welches dafür zuständig ist, das API Management und die APIs sauber und sicher zu halten, würde die vorgeschlagenen Änderungen kontrollieren und evaluieren ob die Änderungen auch andere APIs beeinflussen würden. Wenn die Änderung akzeptabel ist, würde die neue Version des Systems oder der Konfiguration angewandt werden.

Möglichkeit 2 entzieht den Teams das Recht, API Management-weite Änderungen zu unternehmen. Die Teams dürfen APIs anlegen, können jedoch nicht mehr konfigurieren, ob das gesamte API Management zum Beispiel isoliert in einem V-netz ist oder nicht. Diese Entscheidung bleibt Team A vorbehalten.

Möglichkeit 3 limitiert die Rechte der Teams weiter. Team A ist in voller Kontrolle des Systems und stellt eine API bereit, die es den Entwicklungsteams ermöglicht ihre API in dem System zu erstellen. Wie diese API aussieht und welche Kontrollmechanismen angewandt werden, um nur sichere APIs in dem System zu erlauben ist Team A überlassen.

Auch wenn diese Methode die höchsten Sicherheitsvorkehrungen erlaubt, ist das Team jedoch so weit eingeschränkt, dass dies einen starken Einfluss auf die Geschwindigkeit hat.


Fazit

Wie ein API Management oder die APIs provisioniert und verwaltet werden sollten hängt stark von den Anforderungen der Firma ab. Dieser Prozess sollte mit dem Zweck des API Managements übereinstimmen. Unterliegen die APIs besonderen Sicherheitsauflagen, die eine unternehmensweite Transparenz nicht erlaubt, dann empfehle ich ein zentralisiertes API Management, welches den Teams nur via einer kontrollierenden API erlaubt, APIs zu konfigurieren. Der Vorteil ist, dass so sichergestellt werden kann, dass APIs sicher sind und auch sicher sind vor unternehminternen Risiken.

Dies ist jedoch meist eine Extremsituation und trifft bei weitem nicht auf alle Firmen zu. Für die Unternehmen, die nicht diesen Auflagen unterliegen, empfehle ich Möglichkeit 1; die Verwendung von Konfigurations-Versionierung eines zentralen API Managements. Dies maximiert Kostenersparnis und gibt zentralisiert Kontrolle über die APIs. API-Strategien können so leichter verfolgt werden.

Wenn man sich gegen die Verwendung von einem zentralisierten API Managements entscheidet umso die Geschwindigkeit der Entwickler-Teams zu erhöhen stellen sich wiederum andere Fragen. Wie verschaffen wir trotzdem eine gute Transparenz innerhalb des Unternehmens, um die Wiederverwendung von bestehenden APIs zu fördern? Darauf werde ich später in dieser Serie auch noch eingehen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz