Amazon Web Services (AWS) ist eines der meistgenannten Buzz-Words der letzten Jahre, einer der am schnellsten und stärksten wachsenden IT-Bereiche. Grund genug, darüber etwas mehr zu erfahren. Wir sprechen dazu mit Wolfgang Unger, Certified AWS Solutions Architekt und Managing Technical Consultant bei NTT DATA.
Interviewer: Was ist AWS und warum wird ihm eine so große Bedeutung zugesprochen?
Wolfgang Unger, Certified AWS Solutions Architekt und Managing Technical Consultant bei NTT DATA
Wolfgang Unger: AWS ist das Cloud Computing Business von Amazon, mit dem sie im ersten Quartal diesen Jahres 70% ihres Betriebsergebnisses bestritten. Die Services sind von Anfang an darauf ausgelegt, Kunden außerhalb von Amazon anzusprechen – und mittlerweile sind das Großkunden wie Netflix, AirBnB und Yelp. Den stetig wachsenden Markt teilt sich Amazon mit ca. 30% Marktanteil mit anderen Anbietern, wie Microsoft Azure, Google Cloud, IBM, Alibaba und Oracle, die aktuell alle um den Platz an der Spitze kämpfen.
Interviewer: Welche Aktivitäten gibt es aktuell bei NTT DATA bezüglich AWS ?
Wolfgang Unger: Einiges. Ich habe unsere AWS Community vor über einem Jahr ins Leben gerufen – wir veranstalten regelmäßig Tech-Talks, bei denen AWS relevante Themen vorgestellt werden. Die Community hat bereits über 30 Mitglieder, bestehend aus NTT DATA Experten, Tendenz steigend, und ist sehr aktiv.
Und natürlich haben wir innovative Kunden-Projekte auf AWS: Wir machen Proofes of Concepts für unsere Kunden, spannende Themen wie JenkinsX auf AWS, ECS, EKS, AI und vieles weitere. JenkinsX – Ein Tool für automatisches CI/CD (Continuous Integretion/Deployment). ECS steht für Elastic Container Services, ein Container Management System von AWS und hinter EKS verbirgt sich Elastic Container Services basierend auf Kubernetes.
Interviewer: Welche Projekte und Erfahrungen hat NTT DATA mit AWS ?
Wolfgang Unger: Ich habe zum Beispiel aktuell ein Projekt bei einem großen OEM in Bayern abgeschlossen, bei dem es darum ging On-Premise Services in die Cloud, in diesem Fall AWS zu migrieren. NTT DATA hat die Umstellung nach AWS durchgeführt und im gleichen Rahmen die Microservices mit den Möglichkeiten von AWS weiterentwickelt.
Kernstück waren 3 Spring Boot Microservices, die wir nach AWS ECS migriert haben. Die Services laufen dort in Docker Containern, vergleichbar mit Openshift oder Kubernetes. Dadurch lassen sich diese Services weit besser skalieren und es gibt eine 100%-ige Ausfallsicherheit. Außerdem gibt es bei Deployments keinerlei Downtime. Das heißt, hier kann die Weiterentwicklung der Systeme im laufenden Betrieb vonstattengehen.
Die Rest Methoden der Services werden über den API Gateway nach außen sichtbar gemacht, dort erfolgt auch Authentifizierung, Security usw. So muss die Absicherung der Microservices nicht mehr programmatisch bei jedem einzelnen Microservice gemacht werden, sondern zentral an einer Stelle für alle Microservices.
Die Microcservices werden über AWS Code-Build und Code-Pipeline gebaut und deployed. Die Code-Pipeline funktioniert nach dem AWS Prinzip ‚pay what as you use‘. Die Build-Server sind also nur aktiv, wenn sie etwas zu tun haben, ansonsten sind sie offline und man zahlt nichts dafür. Alle Ressourcen werden über Cloud Formation, also mit dem Infrastructure as Code-Ansatz erzeugt und sind somit leicht auf eine andere Umgebung portierbar.
Des Weiteren sind noch einige andere AWS Services beteiligt, wie SQS, Lambda, KMS usw, die ich jetzt nicht alle aufzählen möchte.
Interviewer: Was sind die Vorteile gegenüber einer On-Premise Lösung?
Wolfgang Unger: Da gibt es einige, aber ich will zwei hervorheben:
Zum einen Skalierbarkeit: Wir können bei AWS weitere Instanzen in Sekundenschnelle hochfahren, vollautomatisiert mit Autoscaling, falls die Last dies erfordert. Bei geringer Auslastung werden diese Instanzen auch genauso schnell wieder herunter gefahren und verursachen keine Kosten. Dies ist bei OnDemand so leicht nicht abzubilden.
Zum anderen Pricing: Wie gerade schon angesprochen, zahlt man nur für Services und Instanzen, die auch laufen.
Beispielsweise werden für den Build und die Build-Pipeline keine eigenen Server benötigt, diese werden nur für den aktiven Job kurzeitig hochgefahren und danach wieder terminiert. Dies spart natürlich deutlich Betriebskosten. Je nach Anforderung können so zwischen 20% – 80% Kosten eingespart werden.
Interviewer: Vielen Dank Wolfgang!