IPC Tag 3

Doctrine and NoSQL:
Innerhalb von Doctrine gibt es ein Document Mapping Projekt mit dem Zugriff auch MongoDB, CouchDB und PHPCR einfach möglich ist. Wer Doctrine ORM kennt, dem ist ein einfacher Einstieg möglich. Model mit Annotations funktioniert genauso wie XML und YAML. Die Annotations unterscheiden sich natürlich ein wenig. So gibt es z. B. @EmbeddedObject um eingebettete Objekte zu kennzeichnen.
Zum Objekt wird in der Datenbank der Typ abgespeichert, um es nachher wieder identifizieren zu können.
Doctrine ermöglicht Assoziationen zwischen Objekten über das Speichern der Ids. Aber das muss auf Applikationsebene gemacht werden.
Über die Version bzw. Revision lässt sich prüfen, ob ein Objekt noch aktuell ist z. B. wenn mehrere User ein Dokument bearbeiten. Attachments werden auch unterstützt.
Views für map/reduce lassen sich in einem Verzeichnis ablegen und werden automatisch synchronisiert.
Je nach verwendeter Datenbank stehen unterschiedliche Features zur Verfügung, die auch nicht durch Doctrine versteckt werden. Man verliert also etwas den Vorteil, dass sich die Datenbank austauschen lässt.
Momentan befindet sich dieser Teil von Doctrine noch im alpha bzw. beta Stadium.

Practical DevOps for Developers:
Probleme treten auf wenn sich die System Architekturen von Development, Live,  Staging,…  Systemen zu stark unterscheiden. Vagrant and VeeWee bringen sehr einfach vorgefertigte VMs mit verschiedenen Systemen und Komponenten. Beide basieren auf Ruby.
Chef und Puppet können benutzt werden, um die Konfiguration der VMs zu managen. Beide Tools abstrahieren des OS.
Puppet lässt sich in die Vagrant Konfiguration einbinden und sorgt dafür dass Konfiguration synchron bleibt. Es lässt sich so auch dafür sorgen, dass PEAR aktuell bleibt.
Austausch der Konfiguration dann via Version System.
Per Vagrant lassen sich auch Snapshots einer VM anlegen.
McCloud und mCollective bieten sich zur Verwaltung größerer Mengen von Servern an.
Foreman ist eine Art Frontend für Puppet und Chef zur Verwaltung und Anlegen der VMs.
Cloud by Example:
Amazon Cloud Services klingen ganz spannend. Muss ich mir mal anschauen, ob sich das lohnt.

Redis:
NoSQL Datenbanken lösen Einzelprobleme sehr effizient. Im Gegensatz zu klassischen SQL Datenbanken, die alles können wollen.
Redis ist ein Key Value Store, unterstützt auch komplexe Datentypen. Die Daten werden im RAM gehalten, aber die Daten auf Platte gedumpt und damit persistiert.
Redis unterstützt synchrone Master Slave Replikation.
Kommunikation erfolgt via einfachem Textprotokoll z. B. via TCP / IP.
Operationen auf Listen und Sets lassen sich in Redis abbilden, z.b. Union, Pop, …
Einsatzmöglichkeiten: Session, Cache, Statistik, Monitoring, Request Limit bei einer API,…
Sharding ist zur Skalierung möglich.

Continuous Live Deployment:
Der Grund um so etwas zu machen ist eine möglichst kleine Time to market und ausprobieren von neuen Features. Und diese auch wieder zurück zu nehmen wenn es nicht funktioniert.
Man benötigt hierfür Automatisierung, Continuous Integration und eine hohe Testabdeckung.
Hauptsächlich müssen Änderungen an Organisation und Prozessen vornehmen.
Um dies bei monolithischen Applikationen zu erreichen, muss die Releasezeit kontinuierlich kürzer gemacht werden und die Stellen an denen das schmerzt beheben.
In dem Teams sollten die Tester direkt sitzen und zusammen mit den Entwicklern die Tests schreiben.
Das Deployment erfolgt per RPM.

GD Star Rating
loading...

Kommentar verfassen