Was ist der organische Wachstumsprozess von einer eigenständigen Lösung in eine Software as a Service ? Klar
Skalierbarkeit ist kein "Merkmal", das am Ende der Entwicklung angeheftet wird. ^
Ich bin also an Codeänderungen und Architekturänderungen auf hohem Niveau interessiert.
Wählt man eine bestehende Plattform aus und übernormalisiert sie?
Startet man mit der blanken Cloud-Architektur und migriert die Legacy-Funktionalität?
Passen aggressive Technologie-Upgrades (d. h. Webformulare & gt; MVC) in den Prozess?
Ich wurde um eine Klärung der aktuellen Projektarchitektur gebeten. Wenn Sie nicht zu sehr ins Detail gehen, denken Sie an eine .NET-Webformularanwendung, die in eine Geschäftslogikebene integriert und mit mehreren Drittanbietern integriert werden kann. Immer wenn neue Plattforminstanzen benötigt werden (mir fehlt hier die Terminologie, was meine ich, wenn ein neuer Client Anpassungen der Geschäftslogik, Integration mit verschiedenen Drittanbietern, brandaktuelles Branding etc.), Bestehenden Code benötigt ist verzweigt und eine neue Umgebung ist eingerichtet. Alle Änderungen sind effektiv sehr Low-Level, unabhängig davon, ob sie direkt in ASPX-Dateien, Komponentencode oder DB-Konfiguration passieren.
Dieses Szenario scheint perfekt geeignet zu sein, um ein "richtiges" SaaS-Modell zu implementieren, aber ich habe Schwierigkeiten, konstruktiv zum Migrationsprozess beizutragen. Um die ursprünglichen Fragen neu zu formulieren, was eine effiziente Strategie wäre:
Überdimensionieren Sie eine vorhandene Plattform, und konfigurieren Sie alles konfigurierbar, indem Sie diese simulierte Skalierbarkeit effektiv aussetzen und keine neuen Clients hinzufügen, bis die Architektur refaktoriert ist. Der Nachteil dieses Imho beruht weiterhin auf Code und Struktur, die nicht für Skalierbarkeit gebaut wurden (Details unten).
Beginnen Sie von vorne mit allem, was als (subjectievly) die beste Architektur für die zukünftige Lösung gilt, und migrieren Sie die Legacy-Funktionalität nach Bedarf. Dies ermöglicht nahezu jedes gewünschte Technologie-Upgrade, hat aber bis zur Fertigstellung keine Sichtbarkeit und wird als aggressive Änderung vom Management als inhärent hohes Risiko angesehen.
Persönlich lehne ich mich der zweiten Option zu, wegen der Menge an vorhandenem Legacy-Code und dem Mangel an ausreichender db-Normalisierung. Gleichzeitig ist die bestehende Lösung ausgereift und funktional ( wenn sie nicht kaputt ist, reparieren Sie sie nicht ), und es gibt wahrscheinlich noch viel mehr Möglichkeiten zur Skalierung als die beiden Ansätze, die ich aufgeführt habe oben.
Wenn der obige Kontext eine szenariospezifische Beratung zulässt, nehme ich es an. Jedoch bin ich offen für allgemeinere do-s und dont-s und Hinweise, die für ein breiteres Publikum geeignet sind.
Der Schlüssel ist Architektur . Der Weg ist, zu teilen und zu erobern . Der Ansatz ist zu entspannen .
Die wichtigste Komponente eines Gebäudes ist seine Architektur. Die Art und Weise, wie der Raum mit Wänden und Böden, Fenstern und Decken, d. H. Elementen der Konstruktion, gestaltet wird. Ziel des Architekten ist es nicht, die Wände zu gestalten. Er entwirft sie als sekundären Teil der eigentlichen Aufgabe: den von den Wänden geformten Raum zu gestalten. Wir bauen keine Gebäude, um Wände zu haben, wir bauen sie, um den Raum darin zu haben.
Wir entwerfen zuerst Funktionen, die wir von Software erwarten. Dann gehen wir auf Einzelheiten ein, die es möglich machen, d. H. Das Produkt zu bauen. Technologien, die wir verwenden, sind nicht die Hauptsache, sie sind die Wände und was wir wirklich wollen, ist der Raum selbst.
Mit einem guten Verständnis dessen, was wir von der Software, die wir bauen, wollen, wird das Engineering zu einem viel einfacheren und fast automatischen Prozess. Technische Schwierigkeiten beginnen mit gut verstandenen Definitionen und glücklicherweise offensichtlichen Lösungen.
Ein sehr wichtiges Maß für eine gute Architektur ist, dass sie Komponenten der Lösung klar definiert. Wenn wir diese Komponenten des Gesamtbildes getrennt sehen können, können wir die Arbeit in einzelne Teile aufteilen. Wir können dann separate Dinge zusammen arbeiten.
Vielleicht klingt dieser Titel so, als wollte ich etwas Humor in den Text bringen; aber nein, bitte versteh mich nicht falsch. Wenn Sie eine gute Architektur haben, können Sie sich entspannen, ebenso Ihre Webserver, Datenbankserver, Ingenieure, Kunden, Benutzer und der Rest der Welt. Wenn dies nicht der Fall ist, heißt das, dass Sie mit der Arbeit an Ihrer Architektur fortfahren sollten.
Hey, was zum Teufel habe ich hier gesprochen? Es gab einige Absätze und drei Titel und ich habe keinen einzigen Softwarebegriff außer Software verwendet. Solch abstraktes Geschwätz ist für Leute, die den ganzen Tag nichts zu tun haben, aber faul herumlaufen und reden und reden und reden ... Wir sind Software-Leute und dafür haben wir keine Zeit. Hey ich, Hasan, schneid es kurz ..!
Okay, ich werde es versuchen; aber zuerst, lassen Sie uns entspannen ... dann können wir uns einige reale Beispiele ansehen.
Nehmen wir an, wir entwickeln einen Web-Publishing-Service für Profis und Einzelpersonen. Jeder Kunde hat eine eigene Website, die auf unserem System läuft. Diese Websites können gewöhnliche persönliche Websites mit sehr geringen Besucherzahlen sein, oder wenn unser Geschäft Glück hat, können einige unserer anderen Kunden große Publikationen wie NY Times sein.
Wir müssen zwei Arten von Skalierbarkeitsproblemen lösen: Skalierung unseres Geschäfts, unseres Systems, wenn wir immer mehr Kunden haben und mehr und mehr Websites betreiben. Dieser ist ein ziemlich einfaches Problem im Vergleich zu dem zweiten, der eine einzelne Website skaliert, da immer mehr Besucher, immer mehr Daten, mehr und mehr Anwendungen auf diesen Daten ausführen.
Wir können die Frage "Wie skaliere ich" wie "Wie teile ich" umschreiben, um die Lösung klarer zu sehen. Wenn wir etwas in kleine Teile teilen können, können wir es skalieren, indem wir mehr Ressourcen hinzufügen, um diese Teile horizontal zu bearbeiten.
Wir werden Daten und Anwendungen haben, die an diesen Daten arbeiten. Nehmen wir an, wir haben einen Datenbankserver und einen Webserver und versuchen, dies skalierbar zu machen.
Wenn wir an die Webserver denken, werden wir für unseren Service laufen; Wenn wir keine Daten auf diesen Maschinen aufbewahren, werden sie zu generischen, gleichen Komponenten, kleinen Clients des Daten-Backends, die diese Daten mit dem Rest der Welt verbinden. Indem wir unsere Webserver leicht, albern und leer halten, können wir viele von ihnen dazu bringen, die steigende Anzahl von Anfragen zu bewältigen.
Okay, Web-Server in dumme Proxies zu verwandeln, ist nicht die klügste Idee. Wir brauchen Dinge, die erledigt werden müssen, Anwendungen, die ausgeführt werden müssen. Und weil Webserver in unserer Architektur am einfachsten zu multiplizieren sind, werden wir auf diesen Webservern so viele Dinge wie möglich machen wollen. Wir werden dieses schwierige Problem weiter unten unter "Dividing Smarter" behandeln. Schauen wir uns vorher an, welche Art von Architektur wir derzeit auf der Tabelle haben und wie sie skalierbar ist.
Wir verwenden Load Balancer, um viele Webserver parallel laufen zu lassen und viele Websites in Gruppen zu unterteilen, indem wir DNS (noch bevor Anfragen auf unser System kommen) auf mehrere Load Balancer verteilen. Zum Beispiel: a.com, b.com, c.com, um Balancer 1 zu laden, a-y-big-website.com, um Balancer 2 zu laden, ... Jede Gruppe eines Load Balancers, eine Gruppe von Webservern und eine Datenbankserver erstellt ein separates Universum in unserem System. Jetzt können wir Millionen von Websites haben und unser System wachsen lassen, indem wir mehr von diesen separaten Universen ohne irgendwelche Einschränkungen hinzufügen. Wir können so viele Kunden mit so vielen Websites versorgen, wie unsere Marketingabteilung es leisten kann. Unser erstes Problem ist bereits gelöst.Was ist mit großen großen Websites zu betreiben?
Natürlich können wir eine einzelne Website nicht in separate Universen aufteilen, wie wir es mit separaten Websites tun; aber das bedeutet nicht, dass wir überhaupt nichts teilen können. Wir werden weiter teilen und erobern. Um dies zu tun, müssen wir uns die Probleme, die wir lösen, genauer ansehen.
Was ist eine Website? Webseiten, die Inhalte wie css und js -Dateien unterstützen, Multimedia-Inhalte wie Bild- und Videodateien und Daten, viele Daten. Dank CDNs und großartigen Speicherdiensten, die Cloud-Computing-Systeme bieten, sind statische Dateien kein wichtiger Teil unseres Problems mehr ...
Wir machen das Rendern von Webseiten wirklich. Oben haben wir uns unsere Webserver als sehr leichte, generische Schnittstellen zu unserem Datenbank-Backend vorgestellt. Wir haben noch nicht herausgefunden, wie man Anwendungen in unseren Universen ausführt. Jetzt ist es Zeit, das zu tun.
Jede Anforderung an unser System wird auf eine Site kommen und von einer Anwendung verarbeitet werden, die für diese Site ausgeführt wird. Das erste, was unsere Webserver tun werden, ist zu entscheiden, zu welcher Seite eine Anfrage gehört. Auf unserem Datenbankserver führen wir eine Tabelle, die Hostnamen mit Sites vergleicht. Mit jeder neuen Kunden-Website, die wir haben, werden wir eine oder mehrere Domains zu dieser Tabelle hinzufügen, um zu dieser Site zu passen. Bei jeder Anfrage an unsere Webserver fragen wir den Datenbankserver ab und entscheiden, welche Seite geladen werden soll. Gut?
Nein, nicht gut. Es ist furchtbar. Warum?
Wir haben eine kleine Anzahl von Websites; aber eine sehr große Anzahl von Anfragen. Die Anzahl der Websites in einem Universum ändert sich viel weniger häufig als andere Arten von Daten wie Kommentare auf Blog-Websites. Diese Tabelle wird vielleicht ein paar Mal am Tag in einem etablierten Universum aktualisiert. Eine solch winzige (ein paar tausend Datensätze, winzige!) Datenbank für jede Anfrage immer wieder den ganzen Tag abzurufen, ist nicht schlau. Der beste Weg dazu besteht darin, Kopien dieser Tabelle auf Webservern zu speichern und sie nur zu aktualisieren, wenn sie aktualisiert werden. Woher wissen wir, wann die Site-Liste aktualisiert wird? Wir können eine Zeile mit einer Nummer als unsere Tischversionsnummer führen. Mit jedem Update können wir diese Anzahl erhöhen. Oder wir können einen Zeitstempel des letzten Updates behalten. Webserver können den Datenbankserver auf diese Nummer prüfen und sie mit ihren lokalen In-Memory-Versionen vergleichen. Wenn die Tabelle neuer ist, ziehen wir die Daten erneut und überschreiben die lokale In-Memory-Kopie. Auf diese Weise haben wir Tausende von Anfragen auf kleine Zahlen reduziert. Große Zahlen, kleine Zahlen ...
An diesem Punkt begannen die Materialien, die wir für unsere Gebäude verwenden, von Bedeutung. Welche Sprachen, welche Art von Plattformen und Datenbanksystemen usw. Sie sind jetzt wichtig, weil sie unsere Architektur besser oder schlechter machen können. Zum Beispiel kann unser Datenbankserver für die Aktualisierung der Tabelle einen Mechanismus haben, um Webserver über das Update zu benachrichtigen. Auf diese Weise sind wir noch weiter gegangen und haben die unnötigen Abfragen der Domain-Site-Tabelle vollständig entfernt. Wenn also die von uns gewählten Systeme solche Mechanismen bereitstellen, bedeutet dies, dass diese Systeme eine gute Wahl für unsere Architektur sind.
Die intelligente Aufteilung der Dinge geschieht automatisch, wenn wir wissen, was wir von unserer Software erwarten. Es ist sehr schwierig, Datenbankserver zu skalieren. Da wir Daten brauchen, um zusammen zu sein. Durch die Erhöhung der Anzahl der Webserver skalieren wir horizontal ohne jegliche Einschränkungen. Für den Datenbankserver ist dies jedoch nicht anwendbar. Der Datenbankserver muss Zugriff auf Daten haben und Maschinen haben Grenzen, die wir nicht effizient skalieren können.
Jedes Datenbanksystem bietet Möglichkeiten zur Skalierung wie Sharding oder Shared-Nothing-Architektur. Es kann eine Zeit geben, dass Sie diese verwenden müssen; Aber wie ich in Foren, Blogs und anderen Orten sehe, teilen Leute ihre Erfahrungen, IMHO, benutzen Leute diese zu aggressiv und falsch. Sie lassen ihre Datenbanken größer und größer werden als "hey es ist Zeit zu skalieren, lass uns einige Scherben hinzufügen." 99% aller dieser Anwendungen laufen blind. Leute werfen ihre Probleme auf Software und erwarten, dass sie wie Magie gelöst werden. Leider merken sie sehr bald, dass es keine Magie gibt.
Wir sollten uns von blinden Lösungen fernhalten, indem wir unsere Zahlen beobachten: große Zahlen, kleine Zahlen. Auch indem wir das Innenleben unseres Systems verstehen und Probleme über die Architektur lösen, anstatt den Materialeinsatz zu intensivieren.
Hier ist eine architektonische Lösung: Architected Solution (von < a href="http://en.wikipedia.org/wiki/Santiago_Calatrava"> Calatrava ).
Hier sind andere Lösungen, die auf Materialien statt auf guter Architektur beruhen: [ Blind-run-Lösung 1 ], [ Blind -run Solution 2 ]
Beurteilen Sie den Unterschied selbst.
Wie können wir einen Datenbankserver skalieren? Anstatt Tische in der Mitte blind zu teilen, können wir über unsere Daten nachdenken.Können wir Benutzerkontoinformationen von Websitevorlagen trennen? Natürlich, warum nicht? Können wir verschiedene Datenbankserver für alte und neue Daten behalten? Ein bisschen schwieriger, vor allem in Anbetracht der Suchmöglichkeiten; aber warum nicht?
Teilen Sie sich intelligent, nicht blind! Ich akzeptiere, dass es Zeiten geben wird, in denen du es nicht mehr teilen kannst; Aber komm, wie viele von uns arbeiten für Google oder Facebook?
- Hey Mann, wir haben einen sehr großen Datensatz und wenn wir laufen ...
- Shush. Gehen Sie zuerst zurück und überprüfen Sie Ihren Datensatz. Muss es wirklich ein großer Datensatz sein ?
Die meiste Zeit, nein, tut es nicht. Wir wollen es einfach nicht zugeben ...
Der Neuaufbau von allem braucht Zeit, die sich viele Unternehmen nicht leisten können. Der bessere Weg ist, unser aktuelles System zu entwerfen, ohne jede Komponente neu zu schreiben; sondern stattdessen, sie als Komponenten zu trennen und neu zu definieren. Dies ist meistens eine Analyse, gefolgt von kleinen Änderungen. Jeder Funktionsaufruf auf einem System kann leicht ein Trennpunkt sein. Wir können das System einfach von diesem Punkt in zwei Teile schneiden.
Ein glücklicher Blick auf Ihr aktuelles System für nur ein paar Stunden wird Ihnen viele Ideen zeigen, wie Sie diese Teile teilen können. Sobald Sie sie aufgeteilt haben, ist es sehr einfach, alles neu zu strukturieren und dann Ihr neues System Stück für Stück neu aufzubauen. Wenn ich ein Gebäude habe und ich ein größeres Gebäude auf dem gleichen Grundstück brauche, um das neue Gebäude zu bauen, ohne die dort lebenden Menschen zu bewegen, ist das eine sehr schwierige Aufgabe; aber nicht unmöglich. Wenn es um Software statt um Gebäude geht, ist es viel einfacher. Also?
Es ist Software. Es ist weich. Sie können Ihre Daten kopieren, Tests durchführen, alles löschen und eine Million weitere Male kopieren. Sobald Ihre Architektur gut entworfen ist, verursachen Ihre Fehler niemals katastrophale Ereignisse. Es ist sehr schwierig, einen Esstisch mit 6 Plätzen in einen zu verwandeln, der 60 Gästen Platz bietet; aber Software ist ... Software und wir können leicht solche Dinge tun. Entspannen Sie sich.
- Die Frage oben berührt einen solchen Bereich, der zur Deckung der in nur wenigen Absätzen unmöglich ist. Basierend auf diesem Teil der Frage: "Aber ich bin immer noch offen für allgemeinere Do-s und Dont-s und Hinweise, die für ein breiteres Publikum geeignet sind." Ich habe versucht, Dinge in einem allgemeinen Format zu erwähnen, ohne in Details einzutauchen. Obwohl ich ein paar kleine Beispiele für die praktische Anwendung meiner Prinzipien zu geben versucht, ich weiß, ich viele offene Enden in diesem kurzen Text hinterlassen haben. Ich freue mich über jede Kritik und Fragen in Kommentaren.
Leider gibt es keine "richtige" Antwort darauf, wie Sie Ihre Architektur verändern sollten. Die Lösung hängt davon ab, wie Ihre aktuelle Architektur aussieht und welche Fähigkeiten und Vorlieben Sie als Entwickler haben. Einige Standalone-Systeme verfügen möglicherweise bereits über eine relativ skalierbare Plattform, während andere möglicherweise Verbesserungen vornehmen müssen, wenn sie an Zugkraft gewinnen, während andere möglicherweise von vorne beginnen müssen, weil ihre Codebasis unbrauchbar ist.
Eine feste Codebasis ist EXTREM WICHTIG. Ohne eine effiziente und saubere Code-Basis ist es unwahrscheinlich, dass Ihre Architektur jemals optimal skaliert. Viele Unternehmen machen den Fehler, Pflaster nach Pflaster zu setzen, um kurzfristige Probleme zu lösen - aber auf lange Sicht funktioniert das nie gut. Wenn etwas nicht richtig funktioniert, nimm dir die Zeit, um es auf die logischste Weise zu beheben - selbst wenn das bedeutet, dass du anderen Code in deiner Plattform anpassen musst.
Das beste, was Sie tun können, ist, Ihnen allgemeine Ratschläge zum Aufbau eines skalierbaren Systems zu geben, d. h. Caching zu verwenden, Ihr System horizontal zu skalieren, Ihre Datenbank zu optimieren und sicherzustellen, dass die db-Indizierung wo immer angebracht ist. Einige Best Practices sind architekturabhängig, aber es gibt einige allgemeine Prinzipien, die so ziemlich jede skalierbare Plattform befolgen muss. Für eine ausführliche Darstellung guter Skalierbarkeitstechniken und Entwurfsmuster würde ich Skalierbarkeitsregeln: 50 Prinzipien für die Skalierung von Websites .
Was die Auswahl einer Plattform betrifft, liegt es ganz bei Ihnen und Ihren Vorlieben als Entwickler. Was codierst du gerne? C #, Ruby, PHP? Gehen Sie mit der Sprache und Plattform, auf die sich Ihr Team einigt, vor. Ich bevorzuge Ruby on Rails und ich liebe das MVC Design Pattern, aber das bedeutet nicht, dass es die beste Lösung für dich ist. Gehen Sie mit dem, was für Sie am sinnvollsten ist, und arbeiten Sie daran, ein skalierbares System zu entwickeln.
In der Vergangenheit, als ich an Systemen gearbeitet habe, die eine hohe Skalierbarkeit erfordern, kam es oft zu einem Punkt, an dem ich die Notwendigkeit gefunden habe, von vorne anzufangen. Leider hat nicht jeder die Voraussicht, alle Best Practices und Features zu kennen, die sie benötigen, und oft führt dies zu weniger als idealen Datenbank- und Plattformdesigns. Der Prozess der Entwicklung eines Systems gibt viel Aufschluss darüber, was wirklich benötigt wird und welche Methoden für dieses System am besten geeignet sind. So gab es in der Vergangenheit ein paar Mal, wo ich ein Produkt halb durchgearbeitet habe und die Notwendigkeit einer neuen Code-Basis erkannt habe. Also übersetze ich den Legacy-Code, den ich für das neue Design für geeignet halte.
Mein Fall ist irgendwie anders, aber kann dennoch ein Modell des Übergangs vom Desktop direkt zu Saas sein. Meine Firma macht Media Monitoring. In letzter Zeit haben wir entdeckt, dass Medien nicht mehr Fernsehen und Radio sind, und wir sind dazu übergegangen, alle Ströme aus dem Netz zu erfassen. Um unseren Kunden eine Lösung zu bieten - sie brauchen ARCHIV, nicht RECORDER -, führen wir für sie einfach eine gehostete Lösung auf unseren Servern durch.
Das gab uns die Möglichkeit, alles unter einem Dach zu haben und die Code-Basis direkt in 'Cloud HQ' zu pflegen.
Es gibt mehr dazu, aber ich werde die Leser nicht langweilen, werde nur darauf hinweisen, dass wir uns dazu nicht gezwungen haben - es war wirklich organisch und vollkommen normal.
Die Architektur unserer Lösung folgt einer großen Prämisse: Jeder zum System hinzugefügte Hardware-Knoten wird vollständig genutzt, vom Netzwerk über den Speicher bis zur CPU. Jede Software wird als 'Task Server' geschrieben & lt; - & gt; "Agenten", die separat ausgeführt werden. So können Sie immer mehr Maschinen kaufen und alles ausführen, was Sie zu diesem Zeitpunkt benötigen.
Lesen Sie: Ссылка
Was einen guten Überblick über den Aufbau von skalierbaren Systemen gibt. Sowohl aus Sicht von Hardware / Software als auch aus Sicht des menschlichen Skalierungsingenieurs pro Server.
Das Buch (oder Kindle Buch) Das Lean Startup (Eric Ries) hat auch einige gute Hinweise.
Die Prozesse erstellen im Grunde eine Client / Server-Schnittstelle (http in den webbasierten SAAS-Fällen), die auf der Interaktion mit Ihren Daten basiert ...
Wenn Sie direkten Zugriff auf Ihre Daten in Ihrem Server haben, können Sie alle oder einen großen Teil Ihrer Softwarelösung auf eine webbasierte Plattform wie asp.net, php, ruby + rails, python + django oder andere migrieren. In dieser Alternative können Sie Ihre Daten auf verschiedene Arten weitergeben: JSON, oData, Text, eingebettet in Code (Objekte oder Arrays) usw. Es gibt sehr clevere Lösungen, um diese Probleme zu lösen. Allgemein AJAX und die allgegenwärtige XMLHTTPRequest.
Wenn Sie einen extremen Fall haben, in dem Sie nicht einmal den Code der Software haben, die Sie verwenden möchten, stellen Sie sich eine COBOL- oder ähnliche Lösung vor, in der Sie nur ausführbare Dateien haben ... Selbst in diesem extremen Fall können Sie einen Broker erstellen das liest aus den Bildschirmen Ihres Programms (Auto-It kann es tun), übergibt diese Daten an Ihre Web-Schnittstelle, die es auf dem Client-Endpunkt präsentiert, erhalten Sie die Ergebnisse von Ihrem Web-Programm und injizieren es in der ausführbaren Schnittstelle (auto -it wieder oder eine andere Makrosteuerungsbibliothek).
Sie brauchen nicht MVC / MVVC / RAILS / DJANGO oder andere, aber sie können Ihr Leben leichter machen, wenn Sie nicht über gewisse Erfahrung im Trennen von Aktionen von Daten und Steuern des Flusses von Web-Programmen verfügen / p>
Tags und Links .net architecture cloud saas
