News ownCloud 2.0 ohne Datenbank: Infinite Scale nach vier Jahren Entwicklung erschienen

@SVΞN wo kommt "kommt dabei gänzlich ohne Datenbank und Webserver aus" denn her? Klar hat Ocis ein Webfrontend, also ist dort auch ein Webserver integriert, und klar benutzt es Datenbanken, nur sind die bei Ocis embedded und nicht Dependency, was aber eher Implementierungsdetail als Unterscheidungsmerkmal ist.

(und klar kann man auch mit LAMP skalierbare Anwendungen bauen - z.B. Wikipedia läuft komplett auf LAMP - aber OwnCloud 1 war halt niemals dafür konzipiert)
 
  • Gefällt mir
Reaktionen: tollertyp
Cr4y schrieb:
Bedeutet der Einsatz von Google-Technik direkt Datenabfluss, weil irgendwelche Abfragen oder Services auf Googleservern laufen müssen?
Man nutzt eine von Google entwickelte Programmiersprache, keinen Google Service.
 
  • Gefällt mir
Reaktionen: Conqi, tollertyp und Mordi
GrumpyCat schrieb:
@SVΞN wo kommt "kommt dabei gänzlich ohne Datenbank und Webserver aus" denn her? Klar hat Ocis ein Webfrontend, also ist dort auch ein Webserver integriert, und klar benutzt es Datenbanken, nur sind die bei Ocis embedded und nicht Dependency, was aber eher Implementierungsdetail als Unterscheidungsmerkmal ist.
Die korrekte Aussage wäre: ocis verwendet keinen dedizierten Web- oder Datenbankserver. ocis scheint aber tatsächlich keine zentrale Datenbank mehr zu haben und stattdessen auf Storage-basierte API's wie CS3 zu setzen.
 
Ich habe erstmal geguckt was 'native cloud technology' ist. Entweder purer Horror, oder pures Vergnügen am Morgen vor dem ersten Koffein.
Microsoft hat eine tolle Erklärung. Es ist wie Magie, Einhörner digitalisiert, geschreddert und mit unobtainium wieder zusammengeklebt für die besteste user experience die man sich vorstellen kann auf allen 5 Seiten des Bildschirms.
Als Beispiel führen sie Netflix, Uber und WeChat an. Ich kenne nur Netflix und das verbinde ich weder mit innovativen Features, noch mit 'rapid responsiveness'. Eher mit der unfähigkeit Listen zu sortieren, lästige Bugs die ewig halten und nicht nachvollziehbare Abstürze mit Microsoft-style Fehlercodes samt völlig nutzlosen Vorschlägen zur behebung. Aber gut, die sind halt das schwarze Schaf, die anderen machen das bestimmt besser.
Das beste für mich aber ist dass ich keine Hardware mehr brauche bei Microsoft. Alles nur noch Software in der Cloud. Außerdem ist es gleichzeitig effizienter und bringt mehr overhead mit.

Dass ich ausgerechnet bei Amazon eine recht nüchterne und verständliche Erklärung finde hat mich überrascht. Also doch Server nötig, nur kein individuelles handling mehr aus sicht der Software. Alles virtualisiert, containerisiert und (hoffentlich) auch sinnvoll orchestriert. Ich stelle mir das spontan wie bei Musik vor. 2 Instrumente gleichzeitig heißt dass nur 2 Leute nicht falsch spielen dürfen. Bei 200 Instrumenten gleichzeitig sind es nur 200 die nicht falsch spielen dürfen damit man es nicht hört.
Unklar ist mir noch ob das bei Microservices jetzt weniger Fehlermöglichkeiten sind als beim alten Stack.
Bei Amazon kommt auch deutlicher raus dass sich die erhöhte Effizienz auf das Management bezieht und nicht auf die Softwareleistung. Man kann halt automatisiert skalieren und auf der Hardware rumhüpfen.
Ich kann mir irgendwie nicht vorstellen dass man mit weniger Hardware auskommt wenn jeder Microservice seinen eigenen Container mit seinen eigenen Abhängigkeiten mitbringt die dann nur mit Mühe oder garnicht geteilt werden können.

Viel schlauer bin ich nach einer halben Stunde lesen auch nicht. Sehr viele toll klingende Bezeichnungen die nicht das meinen wonach sie klingen und komplexes System das man sich erstmal im Detail angucken und testen müsste.
Harte, wünschenswerte Infos habe ich dafür keine gefunden. Benchmark zum vergleich mit der alten Version, Sicherheitsgarantien bei dem potentiellen wildwuchs an Abhängigkeiten (einfach direkt alles aus dem jeweiligen repository laden, compilieren und ausführen klingt eher explosiv) oder Versicherungen zu Datenverkehr des Code-Zoos. Bei einem LAMP muss ich gefühlt erheblich weniger davon ausgehen dass meine Daten bei jemand anderem landen. Bei beidem werde ich nicht den Quellcode lesen bevor ich es ausführe, aber beim LAMP muss ich weniger Institutionen vertrauen. Die überwachung des Netzwerkverkehrs dürfte auch einfacher weil überschaubarer sein wenn jeder Microservice Telemetrie macht.
 
  • Gefällt mir
Reaktionen: [wj], Yar, chillking und 16 andere
ChristianSL schrieb:
Dann doch lieber eine andere Quelle benutzen. Die Darstellung von Owncloud find ich mehr als fragwürdig, da sie ja selbst diejenigen sind, die eine Enterpriseversion mit separater Lizenz haben, und es in ihrem eigenen Vergleich so aussehen lassen, als wäre das bei Nextcloud so. Die widerum bieten eine vorkonfigurierte Version und Support für Unternehmen an.
Bei Owncloud kann man nur mit dem Kopf schütteln. Es hat sich in den Jahren offenbar nichts getan am Verhalten.
Was sie da genau gebaut haben interessiert mich aber schon, leider erklärt der Artikel das null.

Edit: Die Doku ist auch nur bedingt besser um die Details zu verstehen, da viele Links tot sind, und andere Teile offenbar noch in Entwicklung.
Aus "keine Datenbank" wird dann eben eine selbstgebaute Registry als LDAP-Ersatz. Mal schauen was da in Zukunft aus der Praxis berichtet wird...
Die Quelle kann man sich natürlich selbst aussuchen. Ich wollte nur darauf hinweisen, dass man sehr schnell durch eine Suche im Internet auf Vergleiche stößt. :D
 
  • Gefällt mir
Reaktionen: ChristianSL
@Bigeagle
Schlecht geschlafen? Du klingst wie jemand, der in der Vergangenheit stecken geblieben ist, und für den jede Neuentwicklung eine Zumutung ist.
Cloud native lässt sich nunmal nicht in einem Satz erklären. Entweder es interessiert dich und du befasst dich damit ernsthaft oder du lässt es bleiben. Aber eine Wall of Text, in der du dich nur darüber auslässt, dass du es nicht verstehst, muss nicht sein.
Sowohl Dependency Management als auch Isolation sind in der Cloud überhaupt kein Problem.
P.S.: Wenn Netflix zitiert wird, dann geht es weniger um die UI oder UX bei der Fehlerbehandlung, sondern um die Backend-Architektur.
 
  • Gefällt mir
Reaktionen: M-X, buy95, tollertyp und 4 andere
Bigeagle schrieb:
Ich habe erstmal geguckt was 'native cloud technology' ist.


Bei Amazon kommt auch deutlicher raus dass sich die erhöhte Effizienz auf das Management bezieht und nicht auf die Softwareleistung. Man kann halt automatisiert skalieren und auf der Hardware rumhüpfen.
Kann es sein dass der Begriff gar noch nicht wirklich definiert ist und vorwiegend von Marketing verwendet wird?
Könnte man jedenfalls meinen wenn man den Wiki Eintrag dazu liest:
https://en.m.wikipedia.org/wiki/Cloud-native_computing

Aber die Definition von Amazon macht Sinn.
Steht ja auch im Namen "Infinity Scale"



Habe vor Wochen mal versucht ein TrueNAS Scale aufzusetzen, in der Hoffnung das könnte Skalieren so das ich auf dem Router/Low Power Device nur das habe was ich 24h jederzeit benötige, und aufm Heimserver der mehr Strom verbraucht nur Backups mache und alle grossen Dateien, dann schaltet der aus wenn er nicht gebraucht wird. Leider hab ich kein Doktorat in WebSsrvices/Server Management und das mit der "einfachen skalierung" ist gescheitert.
Ich hoffe sehr das wird bei OcIS einfacher zu managen sein ...
 
  • Gefällt mir
Reaktionen: Bigeagle
darthbermel schrieb:
Die korrekte Aussage wäre: ocis verwendet keinen dedizierten Web- oder Datenbankserver. ocis scheint aber tatsächlich keine zentrale Datenbank mehr zu haben und stattdessen auf Storage-basierte API's wie CS3 zu setzen.
Pff, und was benutzt das unter der Haube? Reva, und das steckt bis unter die Hutkrempe voll mit Interfaces zu ganz normalen Datenbanken, siehe https://github.com/cs3org/reva/blob/master/go.mod - SQLite, MySQL, you name it. Also mal im Ernst, wie sollte so ein System auch "ohne Datenbank" funktionieren? Und wenn sie sich ihre Datenbank selbst klöppelten, würde es immer noch eine Datenbank bleiben.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai und kat7
CS3 ist nur eine API Spezifikation. Reva ist eine von vielen Storage-Lösungen, die die CS3 API implementiert.
 
SheepShaver schrieb:
Schlecht geschlafen? Du klingst wie jemand, der in der Vergangenheit stecken geblieben ist, und für den jede Neuentwicklung eine Zumutung ist.
Ja, leider. Zweiteres erscheint mir hin und wieder auch möglich. Bis ich merke dass mein altmodischer Kram ganz gut funktioniert und die Vor- und Nachteile meist in etwa ausgleichen.
Wenn man etwas neu macht ist die Frage doch was macht es besser als das alte und besonders bei IT meist auch für welchen Anwendungsfall.
Vielleicht habe ich letzteren auch völlig verkannt. Für mich ist die typische Owncloudnutzung 'Privatmensch hostet seinen Kram zuhause um nicht von einem Anbieter abhängig zu sein' und nicht 'Privatmensch hostet seinen Kram in der Cloud'.
Vielleicht habe ich auch das zuhause hosten falsch im Kopf. Wenn der multisockel Epyc nicht mehr reicht muss eben mehr Hardware her und die Software muss das natürlich auch unterstützen. :)
Ich sehe da immer noch eher einfache Desktop-, oder MiniPCs, NAS, Raspberry Pi Äquivalente. Letztere kann man sicher auch spaßeshalber zu einem Schwarm zusammenschließen und so tatsächlich seine eigene home-cloud aufmachen. Aber das dürfte kaum der typische Fall sein und bringt auch eher persönliche als technische Vorteile.

Die Vorteile die ich erkennen konnte betreffen vor allem Anwendungsfälle die eher eine eigene IT Abteilung und mehrere Maschinen haben weil eine nicht ausreichen würde. Ggf. wäre die Robustheit auch zuhause interessant, wobei man sich da schon fragen sollte wie oft denn da etwas ausfällt und ob Hochverfügbarkeit zuhause so wichtig ist. So ein Linuxserver braucht nicht sooo lange für updates+reboot und so oft geht das auch nicht kaputt.

Vielleicht bin ich aber auch einfach alt und überschätze den Aufwand sich in die Cloudtechnik einzuarbeiten. Für mich siehts immer noch mehr wie verteilte und in kleine Stücke runtergebrochene alte Technik aus.
SheepShaver schrieb:
Cloud native lässt sich nunmal nicht in einem Satz erklären. Entweder es interessiert dich und du befasst dich damit ernsthaft oder du lässt es bleiben. Aber eine Wall of Text, in der du dich nur darüber auslässt, dass du es nicht verstehst, muss nicht sein.
Bei Microsoft sind es rund 4000 Wörter, bei Amazon rund 1500. Das ist schon ein bisschen mehr als ein Satz. Schachtelsatzliebhaber würden jetzt ggf. widersprechen, aber da sind wirklich satzbeendende Zeichen dazwischen!
Wenn ich Owncloud auf einem LAMP System in wenigen Sätzen erklären, bzw verstehen kann, aber für die Cloudfassung ein kleines Studium brauche müssen die Vorzüge schon heftig sein. Aber für den privaten Anwendungsfall reichen die dann eher nicht mehr.
Dass mein Text so lang ist liegt vor allem daran dass ich meine Meinungsäußerung einfach nicht nur in einem Satz unterbringen kann. :p
Und ich mich ein wenig darüber lustig machen will dass die Neuentwicklung und 'cloud native' als so toll angepriesen wird und es dann so schwer ist zu erklären warum. Ich bezweifle ja nicht mal dass es Vorteile hat.
SheepShaver schrieb:
Sowohl Dependency Management als auch Isolation sind in der Cloud überhaupt kein Problem.
Nenn mich alt und grau, aber ich denke da spontan sofort an die Nachteile zu vieler externer Abhängigkeiten. Besonders wenn ich lese dass die alle automatisiert direkt aus dem repository geupdated werden sollen. Dass man damit das Problem löst dass viele 'klassisch' mitgelieferten Abhängigkeiten nie oder zu langsam geupdated werden ist ja gut, doch das macht es nicht problemlos.
Dazu war mein Eindruck von Außen bislang eher dass man sich sehr schnell hunderte bis tausende Abhängigkeiten einfangen kann weil sehr freizügig für einfache funktionen externe Abhängigkeiten eingebunden werden. Wenn ich mich entscheiden muss ob ich einer handvoll Entwickler, oder hunderten+ vertrauen muss wähle ich wahrscheinlicher die geringere Anzahl einfach weil die überhaupt für mich allein prüf- und einschätzbar ist.
Wenn das gelöst ist teile mir doch mit wie :)

Prozessisolation ist genau genommen tatsächlich ein gelöstes Problem. Man nehme einen Prozessor ohne Sprungvorhersage, ggf. auch in-order und verzichtet auf multitasking (wie in DOS). Wenn man es ganz sicher haben will verzichtet man auf Ein- und Ausgabemöglichkeiten.
</spaß>
Um Isolation habe ich mir noch garnicht mal gedanken gemacht. Solange ich keine fremden auf mein System lasse erschien mir das klassische Benutzer- und Rechtemanagement ausreichend. Will ich Hacker draußen halten müsste ich ja genau genommen erstmal rausfinden ob mein Server für Sachen wie Spectre oder Rowhammer anfällig ist und mich auch darum kümmern. Das übersteigt dann aber wieder den akzeptablen Aufwand.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai, Creshal und Rickmer
Wer schnell einen eigenen Onlinespeicher aufsetzen will, kann sich mal minIO oder filebrwoser anschauen.
Beides nur eine einzelne Binary (beide auch in GO geschrieben). Einfach mit den gewünschten Parametern aufrufen.

Minio ist ein S3 kompatibler Objektspeicher.
https://min.io/download#/linux

Filebrowser ein Fork von Caddy, was auch ein sehr cooles Projekt ist.
https://filebrowser.org/

Ich hab ein TrueNAS Core (Scale ist mir noch zu buggy) als VM laufen für local storage und bestimmte Ordner per NFS freigegeben. Eine 2 VM mit Fileserver und Caddy hängt in der DMZ und ist Cloud und Reverseproxy in einem bei mir.
Läuft seit Jahren problemlos.
 
  • Gefällt mir
Reaktionen: Reflexion und DFFVB
Ich frage mich grade, wie viel Troubleshooting man bei den Microservices überhaupt machen kann. Beim LAMP Stack kann man ja ziemlich tief eingreifen.

Erinnert mich irgendwie an die Karikatur vom Apple Auto:
Apple Repair.jpg


Wobei ich zugegebenerweise bisher auch nur das Owncloud Video aus dem Artikel angesehen habe, wo man nur einen Download macht, auf 'run' drückt und es ist alles schon lauffertig.
 
  • Gefällt mir
Reaktionen: DFFVB, agent-orange, Kitsune-Senpai und 2 andere
Owncloud ist mit "alles muss ein Microservice sein!!1" eh schon wieder 2-3 Jahre hinter dem Hype her, wenn man sich Hackernews o.Ä. Branchen-Aggregatoren anschaut, gibts da gefühlt jede Woche einen Bericht von einer Firma, die das alles bereut.

Weil ja, es kann besser skalieren, wenn du wirklich Facebook oder Netflix bist und hundert Millionen User auf einer "Instanz" verwalten musst… aber du brauchst auch Facebooks oder Netflix's tausende Programmierer, um den Scheißhaufen zu debuggen, sobald was schief geht. Bei n Microservices hast du n^n implizierte, undokumentierte Abhängigkeiten und Gelegenheiten für Race Conditions, viel Spaß.

Der Overhead von Cloud-Orchestration variiert. Bei Kleininstanzen auf dedizierter HW ists egal, weil moderne Hardware eh absurd überdimensioniert ist für sowas. Das fühlt sich alles fluffig und geschmeidig an… bis du dann bei einigen tausend bis zehntausend Usern in eine Wand rennst: Wo mit einem LAMP (oder Linux/Nginx/Postgres/FPM-Stack) ein halbes Dutzend Server mit HA-Failover reichen, hat das Cloudnative-Microservice-Bullshitbingo gerne mal Hunger auf 20+ Server.

Ab ein paar hunderttausend Usern ists aber wieder egal, da ist Cloud-Orchestrierung (auch von klassischer LAMP-Software!) alternativlos weil du von Hand so oder so nimmer hinterherkommst.
 
  • Gefällt mir
Reaktionen: Kitsune-Senpai und DFFVB
brubbelmichi schrieb:
Und ab wann ist der Punkt erreicht, an dem traditionelle Datenbanken nicht mehr so gut skalieren wie dieser Ansatz?
Der Punkt ist noch in sehr weiter Ferne. In 11 von 10 Fällen sind die abfragenden Queries nicht optimiert oder die Datenbank nicht sinnvoll aufgebaut bzw. verteilt.
 
Tzk schrieb:
Man nutzt eine von Google entwickelte Programmiersprache, keinen Google Service.
Das ist auch mein Verständnis einer Programmiersprache. Aber was Google aus sowas macht, ist nochmal was anderes. Da vermute ich bei jedem Angebot die Idee, es mit der Google-Welt fest zu verknüpfen.
 
Wobei es schon schwierig ist, so etwas in einem Open Source Compiler mit Open Source Bibliotheken und einer Open Source Community zu verbergen.
 
darthbermel schrieb:
Open Source Community
Klingt so abstrakt immer erstmal gut. Frage ist, wer sich das a) anschaut und dann b) auch in der Lage ist, das zu beurteilen. Wenn jeder denkt, einer wird da schon reinschauen, macht's am Ende keiner.
 
Bigeagle schrieb:
Als Beispiel führen sie Netflix, Uber und WeChat an. Ich kenne nur Netflix und das verbinde ich weder mit innovativen Features, noch mit 'rapid responsiveness'. Eher mit der unfähigkeit Listen zu sortieren, lästige Bugs die ewig halten und nicht nachvollziehbare Abstürze mit Microsoft-style Fehlercodes samt völlig nutzlosen Vorschlägen zur behebung. Aber gut, die sind halt das schwarze Schaf, die anderen machen das bestimmt besser.
Du betrachtest das zu sehr aus der Frontend bzw. User-Seite. Es ist unabhängig von Technik, wie gut Dinge umgesetzt werden. Schlecht sortierte Listen sind kein Cloud Problem. Es ist einfach nur ein schlecht umgesetztes Feature.
Bedenke aber mal welche Leistung im Backend notwendig ist, damit die Leute weltweit streamen können. Hunderte Millionen von Menschen von jedem Kontinent aus. Die Menge an Daten die es da zu handhaben gilt, besonders zu Stoßzeiten.
Microservices sind auch nichts, was ein "Nicht-Technik-Begeisterter-Mensch" verstehen oder nutzen muss. Es ist für Leute relevant, die jeden Tag für die Verfügbarkeit von Diensten sorgen müssen.

Das gearade im Cloud-Bereich oder generell bei neuer Technologie aber viel Marketing-BlaBla genutzt wird, ist wohl leider wahr. Wer damit jeden Tag arbeiten muss, kann aber die notwendigen Infos für sich rausziehen, bzw. schauen solche Leute dann in entsprechende Dokumentationen rein. Nicht auf die Werbeseiten der Anbieter.
 
  • Gefällt mir
Reaktionen: Bigeagle
mae1cum77 schrieb:
Klingt so abstrakt immer erstmal gut. Frage ist, wer sich das a) anschaut und dann b) auch in der Lage ist, das zu beurteilen. Wenn jeder denkt, einer wird da schon reinschauen, macht's am Ende keiner.
Da muss ich glatt an das Facebook SDK oder was das war denken...wo Appentwickler das fleißig nutzten, ohne zu prüfen, was dadurch sonst noch so in die eigene App rein kommt..an FB Apis.
 
  • Gefällt mir
Reaktionen: mae1cum77
Zurück
Oben