PaaS - DevOps - Agile Platforms meet Agile Development

Was genau ist eigentlich PaaS wie Bluemix?

Bluemix ist eine der neuen Platform-as-a-Service (PaaS) welche von IBM angeboten wird.
Wobei IBM hier verschieden Softwarekomponenten (Microservices) kombiniert.
Diese können eigene IBM Software sein, aber auch von 3. Party und offene,
selbst erstellte Services und Technologien sein.

Es ist also eine auf offenen basiernden Standards basierende Cloud-Platform
um Programme (Webapplikationen) zu:


         entwickeln > ausführen > verwalten
Das wird im allgemeinen als: DevOps = Development & Operation zusammen gefasst.

Bluemix ist eine neue Platform-as-a-Service (PaaS) welche von IBM angeboten wird.
Es kombiniert (Micro-) Services von IBM, 3-party und andere offene Technologien
welche man für die eigene Webapplikation verwenden kann.

My Journey with IBM Bluemix Cloud Platform

Cloud Technologien werden die Zukunft im Internet sein.
Davon betroffen ist auch die Entwicklunsgumgebung,
wie Programmiertools (IDE) und Server Runtimes also auch die gesamte IT-Infrastruktur.

Nun konnte ich die IBM Bluemix Cloud Platform "Bluemix" testen,
um heraus zu finden:

Nachdem ich etwas vertrauter mit der Umgebung in der Cloud Platform Bluemix wurde,
habe ich angefangen die Vor- und Nachteile für mich zu analysieren.

Die größte Frage dabei für mich:
  • Wie kann ich die bestehenden Backendsysteme (Infrastruktur) mit der Cloud Platform verbinden?
  • Ist das data-hosting auch in deutschland möglich?
In dem Artikel über Agiles IT-Projektmanagement bin Ich schon auf die Problematik eingegangen,
dass viele IT-Firmen, die europa- oder weltweit agieren,
oft eine größere Herausforderung darin haben,
die jeweiligen Datenschutzgesetze der Länder zu beachten,
als mit der Entwicklung und Programmierung der eigentlichen Applikation selbst.

Die IBM Cloud Service Platform

bietet hier zumindest schon mal die 3 verschiedenen Methoden/Modelle an,
wie man die IBM Bluemix PaaS nutzen kann:

  • Public Cloud
  • Hybrid or Dedicated Cloud
  • Private or On-Premise Cloud
Die Kommunikation der Web- Applikationen und Microservices
läuft im Grunde außschließlich über WebServices (REST, SOARP etc.)

Also das bestehende Backend sollte zumindest in der Lage sein,
per Webservice zu kommunizieren,
will oder kann man das in einer Firma nicht, wird es schon kompliziert.

Die normale SAP Business Suite ist nicht für Webservices ausgelegt.
Hier hilt nur eine Erweiterung, Beispielsweise der der SAP NetWeaver Gateway,
welcher REST-Webservices für OData Service bereit stellt.

Oder von einem andern Anbieter, Bsp. PEGA (Pegasystems)
Welche einen PRPC Integrator for SAP anbieten.
Das ist ein SOAP connector, basierend auf der XML Struktur mit WSDL.
Dieser WebService kommuniziert mit der SAP via NetWeaverXI/PI oder einem SOAP Adapter.

Dann gäbe es noch alternativ EAI Lösungen,
die einen SOAP Webservice einen request & respose mit der SAP ermöglichen.
(sind aber nicht so zuverlässig...)
Wie und womit? - ist mir als Entwickler im Grunde egal, zumindest zweitrangig.

Und da wären wir schon bei einem Hauptargument,
bzw. der Bezeichnung: DevOps
  • DevOps = Development & Operation (ein einziges System/Platform für die Entwicklung und betreiben von Applikationen)

1. Vorteil einer Cloud Platform - Agilität

  • Agilität - Ich als Entwickler/Programmierer muss mir keine Gedanken um die Hardware und Infrastruktur machen!
    und bin dennoch agil für alles was ist und noch kommt
Wenn eine neue WebApplikation erstellt werden soll,
dann will ich als Entwickler nicht viel Zeit in die Infrastruktur stecken,
und mir überlegen müssen:
  • welche oder wie viel Webserver oder Datenbankserver ich brauche?
  • Welche Firewalls und WAF (web application firewall) habe oder brache ich?
  • Und wie viel kostet mich das ganze?
  • Auch beim Datenaustausch mit 3. Anbieter will ich mir keine Gedanken mehr machen müssen, wenn alles sauber über einen Webservice zu realisieren ist
  • Oder SSO ist ein großes Thema, warum also nicht bestehen Standarts in der PaaS nutzen?

Agile Tools für das Projektmanagement in der Cloud (DevOps) Dadurch, dass man nicht lokal mit der IDE arbeitet,
sondern mit der WebIDE in DevOps,
stehen viele moderne Werkzeuge für SCRUM IT-Projectmanagement im DevOps bereit.

Der SCRUM-Master kann manuell die eingehenden Arbeitspakete und Anfragen in den Story-Cards sammeln.
Diese überträgt er dan in der Cloud in das "Incoming Work" Verzeichnis.
Worauf das ganze SCRUM-Team Zugriff hat. (da es ja in der Cloud, also im DevOps liegt)

Im Grunde sammelt (verwaltet) das ganze SCRUM-Team
die Arbeitspakete und Anfragen im Produkt-Backlog.

Diese werden dann im ganzen SCRUM-Team während der SPRINT-Meetings besprochen und eingeteilt.

Somit stehen dem Scrum-Master (Project Leader) wichtige agile-Tools im DevOps zur Verfügung,
womit er die ganze SPRINT-Planung in der Cloud machen kann.

2. Vorteil einer Cloud Platform - Zeitersparnis

  • Zeitersparnis - Man kann also schnell mit der Entwicklung loslegen, und spart wertvolle Zeit bei der Planung
Ohne also die Details zu wissen oder zu planen,
  • welche Hardwarekapazitäten ich brauche?
  • Wo und welche URL muss ich registrieren?
  • SSL/TLS Zertifizierungen auf dem Websever
  • und wieviel das alles kostet?
kann man schon direkt mit der Entwicklung/Programmierung der Applikation in der Cloud Platform anfangen.
So langsam verstehe ich besser,
welche Möglichkeiten und Perspektiven
eine konsistente und flexible Cloud-Umgebung für die Entwicklung
und das Roll-Out von IT-Applikationen in der Cloud bietet.

3. Vorteil bei der Cloud Platform - Skalierbarkeit

  • Skalierbarkeit - man kann jederzeit die Serverkapazitäten erweitern oder verkleinern,
    also die Applikation mit hunderten instances skalieren, oder Datenbanken nutzen ?
Im Grunde stehen hunderte Server-Instanzen bereit,
die ich jederzeit dazu oder weg skalieren kann.

4. Vorteil bei der Cloud Platform - Unabhängigkeit

  • Unabhängigkeit - die Entwicklungsplatform (Application Runtime) ist frei wählbar
Man kann wählen,
ob man mit JAVA, Node.JS, C# oder ASP.NET, PHP, Pyton, Ruby usw. die Anwendung entwicklen möchte.
Die unabhängigkeit, die frei wählbare Application Runtime, ist auch vorteilhaft,
wenn man eine bereits bestehen Applikation komplett übernehmen will.
Hier wird in der Regel die Software und die Hardware gekauft,
damit man die Appliaktion im eigenen Rechencenter (eigene Infrastruktur) weiter betreiben und weiter entwickeln kann.

Dank der Cloud Platform, würde es also reichen, nur die Software zu kaufen
und die agile Cloud-Infrastruktur zu nutzen.
Und gleichzeitig eine Kostenersparnis hat,
da man nur die Kapazitäten in der Cloud kauft, welche wirklich benötigt werden.

5.Vorteil bei der Cloud Platform - Kostenkontrolle und Kostentransparenz

  • Kostenkontrolle und Kostentransparenz - ich sehe auf der Platform schon,
    wie viel mich die Dienste oder Services kosten, und kann bei Bedarf auch reduzieren,
    wenn bestimmte Serverkapazitäten (Cluster) nicht gebraucht werden.

6. Vorteil bei der Cloud Platform - Microservices

  • Microservices und 3. Party Applikationen - der Catalog von Bluemix.
Das ist eine große Toolbox (Werkzeugkasten) bereits entwickelter Applikationen,
die man in die eigene Applikation implementieren kann,
ohne das Rad neu erfinden zu müssen.

Dabei handelt es sich einerseits um IBM WebServices oder von 3. Anbieter.

Hier sehe ich das größte Potenzial, also einen wesentlichen Vorteil,
bei der Nutzung einer solchen Cloud Platform.

IBM bietet in seinem Katalog eigene entwickeldete Services (Microservices) und von 3. Anbieter (3. Party) an.
(combine IBM's software, third-party and open technologies.)
Man könnte aber auch seine eigenen WebServices anbieten (share Webservice).

Ich möchte hier nicht alle aufzählen,
aber mal ein paar Microservices vorstellen:

7. Vorteil bei der Cloud Platform - Security

Die in der PaaS Cloud gehosted Applikation,
läßt sich leicht mit einem SSL/TLS-Zertikat in der Infrastruktur erweitern.
  • Add SSL-certificates to your App
In meinem Security Blog über SSL und TLS Zertifizierung,
bin ich etwas darauf eingegangen, wie wichtig SSL/TLS Verschlüsselung bei einer Webapplikation ist.
Im Groben sollte jede größere Webapplication mit SSL (Secure Socket Layer) zertifiziert sein,
bzw. Das SSL-Protokol nutzen.
Die Cloud (PaaS) bietet mir hier einige festures:
  • wie flexibilität
  • Range of Option
  • Respected providers
  • und selbstverständlich die Encrypted Connection an
die ich ohne großen aufwendung für meine Applikation freischalten kann.
Wenn ich auf meinem eigenen Webserver SSL/TLS anbieten will,
muss ich mich um die ganze Zertifizierung selbst kümmern.

DevOps - Die Entwicklungsumgebung in der Cloud Platform

Ich als Programmierer, mag die Kontrolle über den Code.
WYSIWYG (what you see is what you get) Developing Tool und drag & drop Objects, mag ich eher weniger.
Am Anfang scheint dies schnell und einfach zu sein,
aber wenn problemchen auftauchen, dann möchte ich Zeile für Zeile debuggen können,
um dem Fehler auf die Spur zu kommen oder genau sehen,
wie und wo der connection-String zum Datenbank-Server auf- und zusammengebaut ist.

Also schaue ich mir mal an:

  • wie das ganze Coding und Debugging so in der Cloud mit DevOps so funktioniert?

Die ganze DevOps Cloud-Umgebung (development and operation)

Die PaaS setzt sich im groben aus den folgenden Services zusammen:

  • Web-IDE (Integrated Develeopmet Enviroment)
  • Repository - GIThub oder JazzHub oder vielleicht doch eigene Repository?
  • Local IDE, Eclypse für lokale Anwendungsentwicklung - dann mit CF um den Code zu PUSHEN (cloud foundry command line)
Also im Prinzip kann man auch Lokal arbeiten.
Seine eigene Repository nutzen
und die Änderungen dann in die Cloud mit mit der Cloud Foundry PUSHEN
oder auch mit der GIT syncronisieren. (aber das muss ich noch genau testen...)

Für meine developing Tests in der Cloud,
entschied ich mich für die NODE.JS Runtime.

Also im Groben wollte ich einfach mal im DevOps Service
eine kleine NODE.JS Anwendung mit "build and deploy" machen

Dazu habe ich folgende erste Schritte gemacht:
  • a) Sign-up for IBM Bluemix
  • b) Set-up environment (data-center und WorkSpace erstellt)
  • c) Die Runtime Node.JS gewählt
  • d) Einen Alias für die GIT Repository erstellt
  • e) Und dann konnte ich schon im DevOps Service mit build & deploy loslegen
DevOps Server Runtime

8. Vorteil bei der Cloud Platform - Erreichbarkeit/Verfügbarkeit und Monitoring

  • Erreichbarkeit/Verfügbarkeit, Monitoring in der PaaS
    erkennen, isolieren und diagnostizieren von Anwendungsprobleme in der WebIDE
Erreichbarkeit/Verfügbarkeit, Monitoring ind er Cloud PaaS

9. Vorteil bei der Cloud Platform

  • Logging - im "overview" kann ich die Activity Logs sehen
    wann wurde der Service gestartet, gestoped oder restaged ?
Activity Logs in der Cloud

In dem menu "Logs" kann ich alle, auch die Error-Logs sehen.
Darunter zählen die Log's von:
Cloud Foundry API, Staging, Droplet Execution Agent, Router, Loggregator und Application

 Logs in der Cloud

Loglist in der Cloud

COMMIT - PUSH - Stages - in der Cloud Foundry

Im Dashboard vom Bluemix, bin ich mich über den Punkt COMPUTE
zu der Cloud Foundry gekommen - das soll der schnellste (einfachste) Weg sein, einen Webserver zu starten.
Hier spielen wieder die 3 Begrifflichkeiten eine wichtige Rolle:
Git Repository oder DevOps oder Web-IDE

Ich habe festgestellt,
dass junge Entwickler gerne diese 3 Begriffe nutzen,
letztendlich aber das gleiche meinen.

Ich bevorzuge:

  • WEB-ID, das mein Entwicklungstool (Entwicklungsumgebung)
  • Git Repository, das ist mein Aufbewahrungort und Versionsverwaltung für den Programmcode
  • DevOps, beschreibt das ganze System
    also die Philosophy von Entwicklung, Programmierung und Operation (Verwaltung und Server Administration) auf einer Platform
Da ich schon bei den ersten Schritten meine Entwicklungsumgebung,
Runtime etc. festgelegt und erstellt hatte
will ich ein paar kleine Änderungen (code edit) machen und die Änderungen Live schalten (deployment)

Um also den Code editieren zu können (build, test and deploy),
muss ich dem DevOps Service die GIT Repository hinzufügen

Dazu gibt es auf der Platform den Continously Delivery
ich muss also erst mal den Continously Delivery für die App enablen (frei schalten)
dazu benötigt er die GIT Repository
Das war nicht so kompliziert, denn ich musste lediglich die GIT-URL hinzufügen
Und schon kann ich auf Edit-Code klicken
Und werde direkt zur Web-IDE weiter geleitet

In der Web-IDE sehe ich nun den ganze Webprojekt-Verzeichnis in der Cloud

Im Unterordner PUBLIC finde ich meine index.html, welche zum Grundinstallationspaket gehört,
wenn man eine neue Node.js Applikation im DevOps erstellt.

In der Index.html ändere ich einfach ein bischen Text, und möchte das nun deployen

Zum Deployment in die Cloud gibt es mehrere Möglichkeiten:
  • Live Deployment
  • GIT repository deployment pipeline
Es gibt auch noch für schnelle, unkomplizierte deployments die Live Edit funktion
Das bedeutet, wenn der Live Edit aktiviert ist, muss der Server nicht neu gestartet werden,
Bsp: wenn Änderungen im HTML, CSS, JavaScript gemacht wurden.

Jedoch ist Live Edit standard mäßig deaktiviert,
d.h. bei jeder Änderung wird der Server neu gestartet
(und das ist zunächst auch gut so, das Live Edit lassen wir mal aus)

Hätte ich meinen Code lokal im Eclypse editiert,
müsste ich die CF commandline interface nutzen um in die Cloud zu pushen

Da ich aber mit der Web-IDE arbeite und diese aus der GIT-Repository pushen will,
Muss ich zuerst eine COMMIT machen und kann dann erst PUSHEN.

Beim COMMIT kann (sollte) man eine Commit-Message eingeben.
Also eine Notiz/Info erstellen, was oder warum geändert wurde?
Das bezeichnet man dann als Push-Notifications.

10. Vorteil bei der Cloud Platform

Die Commit-Message (Push-Notifications)
dokumentiert also jede Änderung und kann von anderen Entwickler im Log gelesen werden.
Also wird hier eine sauber Software dokumentation ermöglicht.

  • PUSH capabilities like: Like Push notifications
Wenn der PUSH angestoßen wurde,
werden automatisch die Build & Deploy Stages in der Pipline ausgelöst
Die Grundeinstellung besteht aus 2 Stufen (stages):
  • Build stage
  • Deploy stage
Man kann aber nach belieben noch weitere Stages (Stufen) hinzufügen,
und zum Beispiel:
  • Build Stage > Test Stage > Deploy Stage erstellen
Dann kann man Live,
die Stages beobachten und sehen ob diese erfolgreich ausgeführt wurden

Zum COMMIT und PUSH muss ich noch hinzufügen,
dass beim pushen der COMMIT syncronisiert wird
und es gibt noch GITIGNORE Verzeichnisse oder Dateien,
die nicht zum Server hochgeladen (deployed) werden.

Mein Fazit hier: Für die Dokumentation und auch für die Sicherstellung der Qualität,
ist der Deployment-Proccess in der PaaS eine gute Sache.

Für mich war aber der erste Eindruck, dass die Entwicklung in der Cloud etwas Zeit aufwendig ist,
wenn bei jeder kleinen Änderung alle Prozesse (Commit, Push, Build stage und Deploy stage) durchlaufen werden.
Besonders wenn man nur kleinere Änderungen macht, oder schnell einen Fehler suchen will.


Comments

No comments yet.

Add Comment

* Required information
(never displayed)
 
Bold Italic Underline Strike Superscript Subscript Code PHP Quote Line Bullet Numeric Link Email Image Video
 
Smile Sad Huh Laugh Mad Tongue Crying Grin Wink Scared Cool Sleep Blush Unsure Shocked
 
1000
Enter the word table backwards.
 
Enter answer:
Captcha
Refresh
 
Enter code:
 
Notify me of new comments via email.
 
Remember my form inputs on this computer.
 
I have read and understand the privacy policy. *
 
I have read and agree to the terms and conditions. *
 
 
Powered by Commentics