Dass ich an einer Open Source Implementation (NSimpleDB) von Amazons SimpleDB Datenmodell und API sitze, hatte ich ja schon berichtet. Bisher lief das Ganze allerdings nur lokal. Aber das war ok, denn ich wollte ja zunächst auch nur eine lokale Version zum Herumspielen für diejenigen, die noch keinen Zugang zum SimpleDB Betaprogramm bekommen hatten bzw. die, die einen so einfachen Datenbank-API für die Persistenz einfach auch lokal einsetzen wollen.
Nun habe ich inzwischen jedoch selbst Zugang zur SimpleDB Beta bekommen. Deshalb war es mir natürlich ein Anliegen, den Umgang mit Amazons online Tuple Space in meine Implementation zu integrieren. Da mein eigenes API-Serviceinterface ISimpleDBService schon "serviceorientiert", d.h. für eine Benutzung als Remote-Schnittstelle ausgelegt war, stellte das nun auch kein Problem dar.
Über dasselbe Interface lassen sich also nun sowohl Daten lokal wie online nach dem Amazon SimpleDB Datenmodell speichern und abfragen. Bisher ging das so lokal:
ISimpleDBService ts;
ts = new NSimpleDB.Service.VistaDb.VistaDbSimpleDBService("hello.ts");
...
ts.Close();
Aber jetzt geht es auch so:
ts = new NSimpleDB.Service.Amazon.AmazonSimpleDBService("<accessKeyId>", "<secretAccessKey>");
Einfach die AmazonSimpleDBService Implementation instanzieren, die von Amazon Ihrem AWS-Konto zugewiesenen Keys übergeben, fertig. An den sonstigen Operationen auf ISimpleDBService ist nichts zu ändern. Noch etwas mehr dazu in meinem englischen Blog.
Ich finde mein Interface für das Amazon Datenmodell ziemlich gradlinig. Etwas objektorientierter könnte es zwar noch hier und da sein, aber dennoch leicht zu bedienen. Für einen remote service passt es aber erstmal so, würde ich sagen. Wer damit herumspielen mag, kann von meinem NSimpleDB Open Source Projekt bei Google Code auch eine fertig übersetzte Assembly inkl. Demoprogramm herunterladen.
8 Kommentare:
Hallo Ralf,
Du greifst mal wieder ein Thema auf, das mich auch sehr interessiert. Was Amazon da zur Zeit vom Stapel lässt, ist cool und wegweisend - vor allem auch das SQS Messaging API, dem ich allerhöchstes Erfolgspotential einräume. Sofern die Entscheider eines Tages meine Auffassung teilen, dass diese Art des Nachrichtenversandes über einen externen Internet Hub im Prinzip für jede verteilte Enterprise-Anwendung Sinn machen kann. Denn erst dann habe ich vollkommene Transparenz und es ist egal, ob die kommunizierenden Nodes nebeneinander im Büro oder an entferntesten Ecken der Welt stehen, ich kann mich auf meine Daten konzentrieren und die Infrastruktur weitgehend vergessen resp. isoliert betrachten.
Die Idee, dass das Internet dereinst zum omnipräsenten Datenbus, quasi der "Äther" ausnahmslos aller Software und Services werden wird, ist bestimmt nicht von mir. Ich bin auf jeden Fall ein überzeugter Anhänger davon. Services wie SimpleDB und SQS flehen einen geradezu an, lokal begrenzte Speicher- und Messaging-Lösungen Geschichte werden zu lassen.
Das einzig stichhaltige Gegenargument ist IMO noch die Verfügbarkeit/Bandbreite. Aber es ist nur eine Frage der Zeit, wann selbst Mobilfunkgeräte im 10 Mbit-Bereich senden und empfangen, über Kabelanbindungen braucht man dann gar nicht mehr zu reden.
Dein Ansatz, SimpleDB fürs LAN nachzubauen, mag zwar technisch spannend sein, ist aber für die Akzeptanz von Service Outsourcing a la Amazon im Grunde ein Bärendienst. Wenn es z.B. einen genialen Wetter Webservice im Internet gibt, wieso sollte ich das lokal im LAN, mit Wetterstation auf dem Dach, nachbauen?
Auch wenn sich die lokale NSimpleDB programmatisch gleich anfasst und man leicht auf den öffentlichen Anbieter switchen kann - am Ende pflegt man doch wieder aufwendig seine eigene Speicherlösung inkl. Backup, Failover & Co., wo man eigentlich nur an die Businesslogik und die Frontend-Applikation denken wollte und sollte.
In diesem Sinne,
gutes Gelingen
Hansi
@Hansi: Ich habe zuhause eine 30 Mbit Leitung ins Internet für 27 EUR/Monat inkl. Tel, alles flat. Für 35 EUR/Monat könnte ich 100 Mbit haben. Mein WLAN Router macht 54 MBit, wenn ich mich nicht irre. Das ist alles so schnell, dass es mir inzw. ziemlich egal ist, wo meine Daten liegen. Ich habe kein LAN mehr, in dem ich Daten sichere, sondern packe z.B. meine Sourcen komplett in online Subversion Repositories.
Insofern stimme ich in deine Vision ein. SaaS ist die Zukunft für viele Szenarien.
Allerdings: Vor allem bei sehr allgm Infrastrukturdiensten wie SQS oder S3 oder SimpleDB sehe ich eine Zukunft. Denn dann kann ich in meiner App immer noch entscheiden, was ich davon nutze, mache mich also nicht ganz abhängig. Ich könnte dann SimpleDB für einen Discovery-Service einsetzen und ansonsten direkt kommunizieren. BT Services stehen für mich auch in der Linie.
Deine Kritik an NSimpleDB verstehe ich allerdings nicht. Ich habe meine Beweggründe doch deutlich genannt. 1. Verfügbarmachen des SimpleDB Datenmodells für die, die nicht in der Beta sind. Die haben sonst keine Alternative. 2. Einen Spielplatz bieten, der keine Kosten verursacht. 3. Anwendungen sowohl (!) lokal wie online mit dem selben API arbeiten lassen können.
NSimpleDB will SimpleDB nicht ersetzen, sondern ergänzen. Mit der aktuellen Version kann ich lokal entwickeln und offline im Flugzeug. Dann instanziere ich eine andere Klasse und schon ist Amazons SimpleDB eingeschaltet. Das ist wie eine Attrappe beim Testen. Warum sollte es das nicht geben?
-Ralf
NSimpleDB als Entwicklungswerkzeug hat seine Berechtigung, das will ich gar nicht in Abrede stellen. Es ist absolut ehrenwert, so ein mock-up kostenfrei anzubieten.
Aber wie Du selber sagst: Es ist eben -im Gegensatz zu SimpleDB- kostenfrei und so mancher wird nach schnellen, erfolgreichen Tests (es ist ja nun wirklich easy) versucht sein, das als nette kleine Embedded DB zu nutzen, jede Wette.
Das an sich ist auch wieder nicht verwerflich. Das eigentliche Motiv jedoch, einen bestimmten externen Service -mithin das genaue Gegenteil einer Embedded Komponente- zu erläutern, bleibt dabei auf der Strecke.
Meine Kritik zielt weniger auf NSimpleDB explizit als eher auf die allgemeine Problematik, Sinn und Anwendung solcher Services im Fallbeispiel darzustellen. Ohne dass ich selber genau wüsste, wie man es besser schaffen könnte.
Googles Gears zeigt IMO eine mögliche Richtung auf: Offline-Betrieb mit Cache als Fallback und Teil eines Service, nicht als Ersatz.
Könntest Du NSimpleDB in diese Richtung schieben? Das wär's!
:-)
@Hansi: Und warum sollte jmd NSimpleDB nicht statt SimpleDB einsetzen? Ich seh da kein Problem.
Ein SaaS ist doch kein Selbstzweck. Wenn ein SaaS der geeignete Weg zu einer Problemlösung ist, dann wird er benutzt und kein lokaler Ersatz. Wenn ein SaaS aber unpassend ist, dann benutzt man vielleicht eine lokale, embedded Lösung - die genauso aussieht wie der SaaS. Was könnte es besseres geben als diese Wahlfreiheit???
Mir geht es doch auch nicht darum, SaaS als Konzept "zu verkaufen". Und Amazon geht es nicht darum, auf Deubel komm raus, SimpleDB reinzudrücken. Es geht um die Steigerung der Optionenvielfalt. Und ich hab insofern einen draufgesetzt, als dass ich eine Option hinzugefügt habe, die kompatibel zu einer anderen ist. Und darüber hinaus ist NSimpleDB eine "enabling technology", weil die Nutzung von SimpleDB deutlich einfacher wird (wie ich finde), als mit dem Amazon-eigenen API.
Wenn du mich dafür kritisiert, dass ich "Sinn und Zweck solcher Services" nicht dargestellt habe, dann geht das leider an meiner Intenstion völlig vorbei. "Sinn und Zweck" herauszufinden, habe ich bisher jedem selbst überlassen. Sie sind für mich entweder evident oder im Augenblick einfach nicht Thema.
Meine Intention war nicht mehr und nicht weniger als das Datenmodell und einen API schlicht verfügbar zu machen, eben damit (!) man Sinn und Zweck selbst herausfinden kann. Leichter, kostengünstiger, universeller verfügbar.
Hm... NSimpleDB local als Fallback zu benutzen, ist eine interessante Idee. Warum versuchst du dich nicht daran? Setze eine ISimpleDBService Implementation auf, die je nach online Status zwischen local und remote tuple space schaltet und Daten bei Bedarf repliziert. Das wäre doch mal eine Herausforderung. Dafür musst du nicht mal in die Sourcen eingreifen. Ich möchte erstmal an anderen Sachen arbeiten.
-Ralf
Hm, offenbar denken wir aneinander vorbei - oder ich denke zu radikal?
Ich sehe SaaS/SOA weniger als Ergänzung bestehender Techniken (Du nennst es "Steigerung der Optionenvielfalt") sondern in vielen Fällen als deren Ablösung. Wozu Optionenvielfalt, wenn eine Lösung die offensichtlich Mächtigste ist? Warum sollte ich dann noch andere Ansätze wählen? Services, vor allem im Internet, sind IMO der nächste Schritt der Software Evolution und ich tue mich schwer, am sogenannten "Bewährten" fest zu halten wo das Neue soviel mehr verspricht.
Wie auch immer, NSimpleDB als Caching Layer vor der echten SimpleDB ist eine sehr spannende Aufgabe, der ich mich bei Zeiten widmen werde. Mangels freier Zeitkontingente nicht sofort, aber Du erhältst ein Update zum Thema!
@Hansi: Kleine, neue Alternativen heute können natürlich morgen die Platzhirsche sein. Aber das werden wir immer seltener erleben.
So auch bei SimpleDB & Co. SaaS wird lokale DBs nicht verdrängen so wie ODBMS die RDBMS nicht verdrängt haben und werden.
Bei aller Connectivity sind wir noch weit davon entfernt, uns auf das Internet so zu verlassen wie auf den Strom. Ich sehe es als meist vorhanden an, aber nicht als so sicher, wie meine lokale Platte. Deshalb speichere ich gern Backups im Internet, aber nicht meine Zwischenschritte am Tag. Denn die möchte ich garantiert immer zur Verfügung haben.
Insofern haben offline und online Applikationen ihre Berechtigung. Dass alles zum Thin Client wird, ist schon versucht worden - ohne Erfolg. Und das wird auch durch Silverlight mittelfristig nicht anders.
Zumindest gilt das für PC-Applikationen. Etwas anderes mag es sein bei Applikationen, die eh eher "in the cloud" leben wie die auf Handys. Die werden sich mehr auf SaaS verlassen.
Die Zeit der einen Wahrheiten, der großen Gegensätze ich vorbei. Wir leben in der Postmoderne. Nicht nur kulturell. Ersetzungen wie sie dir vorschweben, sind heute selten. Pluralität ist der Weg in die Zukunft.
-Ralf
"[...] Etwas anderes mag es sein bei Applikationen, die eh eher "in the cloud" leben wie die auf Handys. Die werden sich mehr auf SaaS verlassen."
In meinen Augen ist es nur eine Frage der Zeit, bis ausnahmslos alle Applikationen in diesem Sinne "in the cloud" leben und Vernetzung immanenter Bestandteil allen Entwicklungsstrebens sein wird. Vernetzte Kühlschränke, Fernseher und Autos werden heute noch immer gerne belächelt - aber die Zeit wird kommen, da bin ich mir sicher.
"Ersetzungen wie sie dir vorschweben, sind heute selten."
IMO öffnen sich gerade durch Vernetzung und Service Allgegenwart die Freiräume für ständige Ersetzungen - leistet ein Service nicht, was ich brauche, wird er durch einen anderen abgelöst! SOA führt doch genau hin zu Pluralität, einem vielfältigen konstruktiven Nebeneinander. Pluralität ist der Weg in die Zukunft - das sagst Du ja selber. Ich behaupte nichts Gegenteiliges!
Gruß,
Hansi
@Hansi: Vernetzung wird natürlich allgegenwärtiger. Aber ein Gefälle wird es noch länger geben. GBit-Anbindungen hier, langsame Verbindungen mit offline Pausen dort.
Früher gab es nur offline, wenn es dann jetzt online gibt, dann gibt es und wird es geben: offline und online. Wenn ich also eine reine online Lösung wie SaaS anbiete, dann muss ich einkalkulieren, dass ich die, die "in einer anderen Welt leben (müssen)" verliere. Aber das ist ok. Weder das eine noch das andere ist deshalb aber "die Wahrheit".
Schön, dass wir in der Pluralität einig sind. Ich sehe sie aber auch in der Form, wo es dir vor allem um den Inhalt geht. Die Form ist online vs offline.
Wir werden sehen.
-Ralf
Kommentar veröffentlichen