Cloud Computing für Entwickler leicht gemacht: Apex als Entwicklerplattform „As A Service“

Heutzutage brauchen Entwickler eine flexible Plattform, auf der sie eigenverantwortlich agieren können, neue Anwendungen schnell und unkompliziert bereitstellen und bestehende einfach ändern können. Oracle Application Express (Apex) kommt diesem Bedürfnis entgegen und stellt nach dem Modell „Platform as a Service“ flexible und effiziente Entwicklungsumgebungen zur Verfügung. Wie es funktioniert, zeigt DOAG Online.

Geschäftsprozesse ändern sich immer schneller - und so ergeben sich fast täglich neue Anforderungen für die IT, die diese Prozesse unterstützen soll. Der „klassische“ Ablauf der Anwendungsentwicklung kann nicht mehr Schritt halten: Bis die Projektumgebung aufgesetzt ist und die Entwickler produktiv arbeiten können, haben sich die Anforderungen meist schon wieder geändert. Je mehr Personen sich aktiv an einem Entwicklungsprojekt beteiligen und je individueller die Prozesse sind, desto länger dauert es, bis die nötige IT-Unterstützung implementiert ist. Dementsprechend teuer wird das Projekt für die Fachabteilung. 

Hier können die Konzepte des Cloud Computing helfen und den ganzen Prozess beschleunigen: Die Ressourcen-Beschaffung ist standardisiert , läuft automatisiert ab und kann vom Projektverantwortlichen in Eigenverantwortung durchgeführt werden. Von „Cloud Computing“ spricht das amerikanische National Institute of Standards and Technology (NIST) übrigens, wenn ein System folgende Kriterien erfüllt: 

• Selbstbedienung
• Zugang mittels üblicher Netzwerktechnik und Geräte
• Ressourcen werden je nach Bedarf (und nicht fest) zugeordnet
• Ressourcen stehen flexibel, quasi unbegrenzt zur Verfügung
• Abrechnungsfähiger Service

Eine Cloud-Umgebung mit APEX erfüllt diese Kriterien und kann automatisiert als "Plattform as a Service (PaaS)" innerhalb von wenigen Minuten als „Platform as a Service (PaaS)“bereitgestellt werden. 

Cloud Computing mit Apex

Selbstbedienung ist einer der wichtigsten Aspekte beim Cloud Computing. Die Tatsache, dass Nutzer sich ohne manuelle Eingriffe eines Administrators selbst bedienen können, macht die Systeme flexibel und effizient. 

In Apex arbeiten Entwickler in Workspaces. Ein Apex-Workspace ist ein abgegrenzter Bereich mit eigener Benutzerverwaltung, der wie eine Sandbox funktioniert. Der Eigentümer eines Workspace kann diesen völlig unabhängig verwalten: So lassen sich neue Benutzer einrichten, bestehende ändern oder entfernen und neue Anwendungen erstellen – und zwar ohne dass ein Datenbankadministrator aktiv werden muss. Dieser wird nur dann gebraucht, wenn die Rechte oder Ressourcen eines Workspace erweitert werden müssen. Und auch hierfür gibt es einen definierten Prozess: Abbildung 2 zeigt die Anfrage eines Workspace nach mehr Speicherplatz. Dieser muss (vom Administrator) genehmigt werden - danach wird er bereitgestellt (die Tablespace-Quota wird erweitert) und der Entwickler kann weiterarbeiten.

Je nachdem, wie ein Apex-Server aufgesetzt wurde, sind neue Workspaces - und damit neue Entwicklerbereiche - entweder manuell oder vollautomatisch eingerichtet. Abbildung 3 zeigt die Konfiguration der Apex-Instanz durch den Datenbank-Administrator.

Wichtig bei einer solchen flexiblen Umgebung ist der Umgang mit inaktiven Workspaces. Wie beim öffentlichen Apex-Demoserver apex.oracle.com melden sich die meisten Nutzer nicht formal ab, wenn der Workspace nicht mehr benötigt wird. Apex bietet daher einen Standardprozess zum „Aufräumen“ inaktiver Workspaces. In den Einstellungen kann der Eigentümer bestimmen, wie lange ein Workspace inaktiv sein muss, damit er zum Löschen vorgemerkt wird. Er kann auch angeben, wie lang er gewarnt werden soll, bevor der Workspace dann tatsächlich gelöscht wird. Den Rest macht Apex allein.

Anwendungsentwicklung mit dem Browser

Eine Umgebung für einen Anwendungsentwickler aus der Cloud bereitzustellen, ist eine echte Herausforderung: Schließlich arbeiten Entwickler mit typischen Werkzeugen (Visual Studio, Eclipse oder JDeveloper) - dabei handelt es sich um Desktop-Applikationen, die zunächst zu installieren sind. Das bedeutet allerdings, dass der Entwickler nur noch mit seinem PC arbeiten kann. Eine schnelle Änderung von einem anderen PC aus ist kaum machbar. In Apex hingegen sind sowohl Entwicklungs- als auch Laufzeitumgebung webbasiert. Die Entwicklungsumgebung ist selbst wiederum eine Apex-Anwendung, läuft also in der gleichen Architektur ab wie die entwickelten Anwendungen.

Für die Arbeit mit Apex muss keine Software installiert sein. Auch Arbeiten am Datenbank-Schema, wie das Erstellen von Tabellen oder die Arbeit an PL/SQL-Prozeduren, lassen sich mit dem Browser erledigen. Das Deployment einer Anwendung findet nicht statt, da Apex ein metadatengetriebenes Werkzeug ist. Der Entwickler verändert durch seine Arbeit die im Apex-Repository gespeicherte Anwendungsdefinition und der Nutzer sieht die daraus generierten Webseiten sofort.

Eine Apex-Anwendung kann also von jedem Ort aus sowohl genutzt als auch bearbeitet werden: Auf welchem Server Apex läuft, spielt keine Rolle. Ein Entwickler mit VPN-Zugang kann eine Apex-Applikation zur Not auch von unterwegs oder von zu Hause aus bearbeiten.

Ressourcen-Verwaltung durch die Datenbank

Ein Apex-Workspace wird stets mit einem Datenbank-Schema oder mit mehreren Datenbank-Schemata verknüpft - in diesen liegen die Datenbank-Objekte wie Tabellen, Views oder PL/SQL-Funktionen, mit denen die Anwendung arbeitet. Bei Bedarf kann diese Zuordnung geändert werden. Dem Datenbank-Schema kann nun (wie immer) eine Speicherplatz-Quota auf einem oder mehreren Tablespaces zugeordnet werden: Apex stellt speziell hierfür einen Anfrage-Mechanismus bereit (siehe auch Abbildung 2). Solange diese Speicherplatz-Quota eingehalten wird, kann der Entwickler also beliebig neue Objekte anlegen oder bestehende erweitern.

Wenn viele Apex-Workspaces gemeinsam auf einem System arbeiten, gilt folgende Regel: Mit einer hohen Last auf dem System können sich die Konfliktsituationen vermehren. Hierfür bietet die Oracle-Datenbank geeignete Mittel an: Wird der Ressourcen-Manager eingeschaltet, so lassen sich die verschiedenen Workspaces oder Anwendungen priorisieren. Der Entwickler wiederum merkt davon nichts - solche Aspekte muss er auch nicht bei der Entwicklung seiner Anwendungen berücksichtigen.

Reichen die Ressourcen eines Servers nicht aus, kommen Technologien wie Real Application Clusters (RAC) zum Einsatz - in diesem Fall greifen mehrere Server auf ein- und dieselbe Datenbank zu. Wird Apex auf einer RAC-Datenbank installiert, so bemerkt der Entwickler davon ebenfalls nichts - Apex funktioniert genauso wie in einer Single-Instance-Datenbank.

Der Datenbank-Administrator kann anhand des Gesamt-Anforderungsprofils Ressourcen wie Server, CPU-Kerne und I/O-Bandbreiten bereitstellen. Dazu sind folgende Fragen zu klären:

• Wie viele Apex-Anwendungen sind vorhanden?
• Wie viele Nutzer greifen parallel zu?
• Welche Verfügbarkeit wird benötigt?

Die Oracle-Datenbank sorgt dafür, dass die Apex-Entwickler diese möglichst effizient nutzen können. Das wird am öffentlichen Apex-Demoserver apex.oracle.com besonders deutlich: Welche Hardware dort tatsächlich läuft, ist dem Apex-Entwickler in keinster Weise ersichtlich - in einem Apex-Workspace arbeitet er, als hätte er den Server für sich allein. Die Datenbank sorgt jedoch mit dem Ressourcen-Manager dafür, dass keine Applikation die Server-Ressourcen für sich allein allokieren kann.

Kosten verteilen: Abrechnungsverfahren mit Apex

Apex selbst bringt kein spezielles Modul zum Abrechnen von Kosten mit. Gerade hier hat wahrscheinlich jedes Unternehmen eigene Anforderungen und auch eigene Prozesse. Während die Kosten bei Unternehmen A nach der Belegung von Plattenplatz verrechnet werden, kommt bei Unternehmen B vielleicht eine pauschale Verteilung nach Workspaces in Betracht. Unternehmen A möchte die Kennzahlen direkt von einem ERP-System verarbeiten lassen? Unternehmen B nimmt vorher eine manuelle Prüfung vor.

Die Grundlage für jede Form der Kostenverrechnung sind Nutzungsdaten, die Apex sammelt. Das Apex Activity Log protokolliert alle Seitenabrufe und die verbrauchte Zeit mit. Es lassen sich also sowohl einfache als auch komplexere Abrechnungsmodelle realisieren. Beispiele für sehr einfache Modelle wäre die pauschale Verteilung der Kosten anhand folgender Kriterien:

• Anzahl Workspaces
• Anzahl Anwendungen
• Anzahl Benutzer
• Belegter Plattenplatz im Tablespace

Ein Beispiel für ein komplexeres Modell ist die Verteilung anhand der Anzahl von Klicks, die auf die Anwendungen eines Workspace stattfinden, oder die verbrauchte CPU-Zeit pro Anwendung. Welche Variante die richtige ist, hängt stark von den tatsächlichen Kostentreibern des Apex-Servers ab.

Daneben können auch andere, von Apex unabhängige Metriken zum Einsatz kommen. So loggt Apex zwar jeden Seitenabruf mitsamt verbrauchter Zeit mit, der CPU-Anteil an dieser verbrauchten Zeit wird dabei jedoch nicht erfasst. Hier kann jedoch das „Automated Workload Repository“ der Datenbank zum Einsatz kommen. Alle darin enthaltenen Informationen lassen sich einer Apex-Anwendung und damit einem Workspace zuordnen und können somit Grundlage für eine Abrechnung sein. Listing 1 zeigt exemplarisch, wie die von einer Apex-Anwendung verbrauchte CPU-Zeit aus dem Automated Workload Repository ermittelt wird.

Listing 1: Ermittlung der CPU-Belastung durch eine Anwendung

Fazit

Application Express setzt einige der Konzepte und Ideen, die unter dem Begriff „Cloud Computing“ diskutiert werden, bereits seit Jahren um. Wie der öffentliche Demoserver „apex.oracle.com“ zeigt, können Entwickler einen Workspace im Selbstbedienungsverfahren beantragen und selbstständig verwalten und nutzen. Dem Entwickler steht die volle Bandbreite der Oracle-Datenbank zur Verfügung, egal ob diese als Single Instance auf einer CPU oder als RAC-Datenbank auf mehreren Rechnerknoten läuft. Auf dem Demoserver läuft allerdings genau das gleiche Apex, das auch heruntergeladen werden kann. Es spricht also überhaupt nichts dagegen, ein eigenes „apex.meinefirma.de“ im Unternehmen aufzubauen und mit dem Cloud Computing für Anwendungsentwickler sofort zu beginnen. Nach dem gleichen Konzept funktioniert übrigens die Oracle Public Cloud cloud.oracle.com und die Database Cloud.

Wussten Sie, dass... Die Ressourcen in einer Cloud werden in Form von Diensten (Services) in Anspruch genommen, wobei im Wesentlichen drei Serviceformen unterschieden werden:
Infrastructure as a Service (IAAS)	Hier werden Infrastruktur-Komponenten wie zum Beispiel Storage, Netzwerk oder Rechnerkapazität zur Verfügung gestellt
Platform as a Service (PAAS)	Die angebotene Plattform beinhaltet zum Beispiel Datenbank- und Applikationsserver-Ressourcen. Eine solche Plattform kann dann Grundlage für eine konkrete Anwendung sein
Software as a Service (SAAS)	Hier wird eine komplette Anwendung als Dienst angeboten