Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: Irdorath, statixx, Teh Wizard of Aiz


 Thema: Software-Entwicklung 0 ( new SammelThread() )
« erste « vorherige 1 ... 32 33 34 35 [36] 37 38 39 40 ... 51 nächste » letzte »
erste ungelesene Seite | letzter Beitrag 
hoschi

hoschi
Crosspost aus Linuxforum
Originalpost

Ich knobel hier ein einem Rätsel. Warum ist globale Variable optarg von getopt() im GDB verdeckt? Ich verstehe es nicht. Für getopt() benötigt man den Header unistd.h, welcher getopt_posix.h und schließlich getopt_core.h inkludiert.

Deklaration im Header
 

/* For communication from 'getopt' to the caller.
When 'getopt' finds an option that takes an argument,
the argument value is returned here.
Also, when 'ordering' is RETURN_IN_ORDER,
each non-option ARGV-element is returned here. */

extern char *optarg;



Definition im Source
 

109 /* For communication from `getopt' to the caller.
110 When `getopt' finds an option that takes an argument,
111 the argument value is returned here.
112 Also, when `ordering' is RETURN_IN_ORDER,
113 each non-option ARGV-element is returned here. */
114
115 char *optarg = NULL;



Deklaration und Definition sehen für mich fein aus.

Mache ich einen Denkfehler? Kann ich GDB darum bitten mir den Ort eine Variablendeklaration anzuzeigen, also in welcher Datei das optarg deklariert ist. Was mir auffällt, ich bekomme für p &optarg eine andere statische Adresse als für p &'optarg@GLIBC_2.2.5'.
13.10.2021 11:33:53  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
MQTT & Co.: Wie wird in der Praxis ""Sicherheit"" umgesetzt? Im Standard kommt das ja nirgends vor, abseits von Clients die sich halt anmelden. Aber wenn ich jetzt z.B. einen Broker habe, scheint MQTT erstmal davon auszugehen, dass jeder Client der auf den Broker darf überall publishen und subscriben darf. Wenn ich Request-Response per Correlation Data abbilde, kann jeder Client meine Response sehen. Mosquitto scheint ACLs zu haben, aber irgendwie fühlt sich das ganze nicht so an, als ob es dafür gedacht wäre, dass man nicht vertrauenswürdige Clients an den Broker lassen soll (sondern eher nach "dem Ding da hinten im Backend"), etwa wenn man Daten nach Nutzern aufteilen möchte. Ist die Idee hier, dass man für solche Clients letztlich irgendeine Form von Gateway/Anwendung davorschaltet, die Authz umsetzt?
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 13.10.2021 18:42]
13.10.2021 18:40:50  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[smith]

AUP [smith] 29.07.2010
Verstehe nicht genau was du für ein "Level" haben willst... Normalerweise haben die Message Broker selber ja eine ACL, wie Mosquitto auch. Unter Authentication in der Doku hast du ja viele Möglichkeiten aufgezählt: https://mosquitto.org/man/mosquitto-conf-5.html . Dazu gehört z. B. auch, dass Clients ein gültiges Zertifikat beim Verbinden zeigen müssen. Meinst du das?

Ansonsten kannst du natürlich auch deinen Payload beliebig verschlüsseln und den Schlüssel beliebig komplex an berechtigte Clients rausrücken. So macht man es halt generell noch "zusätzlich" wenn man sich um den Inhalt wirklich kümmert.

Vielleicht spannender Anwendungsfall: Firma XYZ fährt voll auf Event-Sourcing ab, muss aber gleichzeitig den deutschen e: GDPR Datenschutzgesetzen genügen. Sprich ein Kunde kann die Löschung aller seiner Daten verlangen. Ist natürlich schwierig, wenn man irgendwo Eventstores rumstehen hat mit ewiger Retention Time.
Eine Möglichkeit ist es dann z. B. den Nachrichteninhalt benutzerspezifisch zu verschlüsseln und bei Löschwunsch schlicht den Key wegzuwerfen, womit alle Nachrichten "unbrauchbar" sind. Siehe Vorschlag hier: https://doc.akka.io/docs/akka-enhancements/current/gdpr/index.html#introduction (bitte prüfen ob alle Bedingungen erfüllt sind).

Hilft das oder kannst du die Frage präzisieren?
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [smith] am 13.10.2021 20:09]
13.10.2021 19:31:49  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
DAS ist dsgvo konform???
13.10.2021 19:54:21  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[smith]

AUP [smith] 29.07.2010
 
Zitat von Oli

DAS ist dsgvo konform???


Hmm, evtl. habe ich übertrieben (korrigiere den Post), aber zumindest für GDPR-Compliance suggeriert mir diese Doku, dass die Methode reichen könnte.

Aber das Datenschutzthema ist natürlich komplizierter und ich bin da kein Experte, daher sollte man entsprechend genau prüfen. Es sollte eher ein Beispiel sein wie er den Inhalt seiner Daten zusätzlich schützen kann.
13.10.2021 20:08:01  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Ich bin da noch in der "konzeptionell verwirrt"-Phase, wo mir noch nicht klar ist, wie man Dinge abbildet - meine Fragen sind also nicht so super-konkret, sondern eher beim Bauchgefühl: Ist die Technik dafür gedacht / bereit, dass ich das als direkte Schnittstelle zu Clients, die im Feld von Kunden betrieben werden, nehmen kann. Quasi eine Einordnung zwischen "Shellzugriff" (Wenn ich Nutzer/Kunden auseinanderhalten möchte, wickle ich dann meine Schnittstelle per SSH-Zugriff und Befehle ausführen ab? Eher nicht) und REST-API.

Konkrete Frage: Wie würde man denn ein Request-Response-Schema auf MQTT sicher abbilden? Ich stelle mir das irgendwie so vor:
- Der Request geht an ein Topic was dem Service gehört, z.B. services/foo
- Jeder Nutzer hat einen privaten Topic-Baum, z.B. users/$USER, und benutzt da dann einen Topic als Response-Topic
- Services sind auf users/* berechtigt und können dort dann die Response publishen, aber
- Nutzer sind nur auf users/$USER berechtigt, können als nur an sie gerichtete Responses erhalten.

Beispiel fortgeführt: Nutzer lässt einen Service irgendeine Ressource per Request-Response erstellen und dann sollen Nachrichten bzgl. der Ressource ausgetauscht werden. Würde man das so machen, dass der dahinterstehende Service dann dynamisch die ACL vom Broker ergänzt, sodass der Nutzer die dazugehörigen Topics zugreifen kann?
13.10.2021 20:29:14  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
NI-Xpert

Arctic
Das klingt für mich eher nach "Ich habe hier den MQTT Hammer und suche nun den passenden Nagel"
Wenn aber alles schon implementiert ist und läuft und du baust was dazu um dich zu integrieren dann fände ich es sinnvoller Authentifizierung und Autorisierung auszulagern und die eigentliche Verbindung über nen Proxy laufen zu lassen. Zum Beispiel kann per REST Call der Proxy mit entsprechender Firewall und den korrekten Subscriptions aufgesetzt werden und dann kann sich der Client mit Standardmitteln verbinden und kriegt nur die Topics die er darf. Der Proxy blockiert dann alle Commands die nicht erlaubt sind.

Vielleicht verstehe ich das Problem aber falsch
13.10.2021 21:06:09  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Viva la Bluescreen

AUP Viva la Bluescreen 31.01.2008
Hm - unser RMQ hat jetzt nicht so wirklich viel mit Nutzerdaten zu tun, aber wir nutzen RMQ sehr stark im Backend quasi als Transportschicht im ESB.

Die angeschlossenen Services nutzen die RMQ ACL um nicht pauschal jegliche Events zu bekommen. Die Payload an sich ist unverschlüsselt.

Die Services selber sind dann halt abgesichert, also bei einer REST-Api entsprechend mit https + Token und je nach UseCase gibts auch Services die wiederum ein eigenes UserManagement haben. Bei den Recherchen dazu bin ich tatsächlich nie über User basierte Exchanges oder topics in RMQ gestolpert sondern entweder Applikations/Service getrieben oder auf Datentypen getrimmt. Spräche dafür dass in diesen Fällen jeweils der ans RMQ angeschlossene Client alles im Rahmen der RMQ ACL bekommt und dann eben selbst dafür sorgen muss dass jeder nur die korrekten Daten bekommt.

Wir haben bei uns nur einen Ausnahmefall wo eine dritte Partei direkt an unseren RMQ darf - da hat uns die ACL im RMQ ausgereicht dass diese Partei nur wenige Queues sehen und abgrasen darf.
13.10.2021 23:03:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[smith]

AUP [smith] 29.07.2010
Das ist bei uns auch so, direkt an die Queues selber darf bei uns niemand Externes dran. Alle externe Zugriffe werden über eigene spezialisierte Services abgehandelt, die dann entsprechende passende Authentifizierungsmethoden haben.

In unserer Welt hatte das alleine den Vorteil, dass wir so Event Evolution im Hintergrund machen können, während die Schnittstelle zum Kunden erstmal stabil bleibt.

Dazu können wir auch an nötigen Stellen Aggregation/Snapshotting/Transformationen/Caching, ohne dass das MQ System es selber unterstützen muss, sprich es gibt weniger Vendor-Lock. Da alle Services einen lokalen Eventstore haben für verschiedene Zwecke kann auch das MQ System im Hintergrund abrauchen, merkt der Kunde erstmal nichts von (bis auf möglicherweise veraltete Daten natürlich).

Ich will auch gar nicht sagen dass es eine zwingend gute Lösung ist. Nach dem zweiten Wechsel des Queue-System sind wir aber davon abgekommen, "komplizierte" Features damit umzusetzen, die die Eventwelt verlassen. Hat eine unglaubliche Kackarbeit an Migration jeweils verursacht. Und dynamische Topic-Erstellung/Bereinigung war in unserem System nicht realistisch umsetzbar. Dazu hat es sich für uns als wartbarer herausgestellt, weniger Topics mit anschließender Filterung im Service selber zu haben, also ewig viele Topics, die einzeln konsumiert wurden und langsam die Connection-Pools weggefressen haben.

Müssen deine Nutzer den zwingend Zugriff zu den Live-Daten haben? Können sie die überhaupt verarbeiten und mögliche Zustände selber herleiten? Wenn du die Event-Struktur änderst, klappt das für alle Nutzer gleichzeitig?

Aber ja, ich kenne auch Beispiele wo eine ACL dynamisch ergänzt wurde, quasi wie iptables-Einträge. War schwierig zu durchschauen und debuggen
13.10.2021 23:37:22  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Tenz

AUP Tenz 03.04.2009
Kenne den typischen Einsatz von RMQ auch nur als async Transportschicht für Event & Delegations innerhalb geschlossener Systeme bzw. bis jetzt auch noch nicht im Zusammenhang mit dem Transfer von sensiblen Daten zwischen verschiedene willkürlichen remote Services über das Grundlegende „da darf ich ran“ hinaus. (Bezieht sich so aber nur auf den Anwendungsbereich E-Commecre und Caching sowie Hintergrundaufgaben und Schnittstellen zu div. rechenintensiven aber nicht zeitkritischen Services).

Spontan würde ich sagen, dass ausserhalb deiner inneren Domain, der Broken zwischen deinen Services eher für das ob, welches und wohin genutzt werden sollte und nicht für das wie und was.

Also sagen wir du hast Client X und Service Y. In der Mitte der Broker.

X schickt per Broker die Anfrage zu Topic N, Topic N ist Service Y Domain, also geht raus, dass Service Auth prüfen soll ob Client X das Topic N von Service Y erhalten darf, Service Auth aus sagt dem Broker dass Service Y Topic N an X liefern darf (ggf. weiss der Broker das auch dank ACL selber) -, Broker informiert Service Y darüber die Daten bereitzustellen, Broker sorgt intern dafür dass die Daten zwischen Service Y und Service IO, C und S gequeued über den Broker bearbeitet werden, Service S informiert Broker darüber dass die Daten von Topic N nun (warm) bereit liegen, Broker gibt Client X bescheid, dass die Daten abgeholt werden können ->(hier kommts) Client X holt sich die Daten per geschlüsselter Verbindung direkt von warmen Endpoint, ggf. informiert es dem Broker noch darüber dass die empfangen wurden.



Finds sehr spannend, gibt sicher legitime Anwendungsfälle für den Transfer der Daten an sich, in der Praxis aber noch nicht begegnet bis jetzt.
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von Tenz am 14.10.2021 0:16]
13.10.2021 23:50:08  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Admiral Bohm

tf2_spy.png
Im IOT-Bereich ist MQTT ein Ding um großflächig events von low-power-systemen einzusammeln. Bei AWS gibts dafür x.509-Authentifizierung für jedes Thing individuell. Diese Teile senden auch nur asynchron Daten und machen selten request/response.

Als größeren API-Ersatz fände ich es auch eine seltsame Anwendung, da gibt es bessere, funktionierende Lösungen.
14.10.2021 9:07:56  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GH@NDI

ghandi2
MQTT taugt als Publish-Subscribe-Plattform sehr gut (wie Admiral sagt: Jedes zweite MQTT-Beispiel published Sensordaten in topics wie "/rooms/2nd-floor/bathroom").

Wenn du eh Request-Response hast und eben nicht "fire and forget" würde ich mir nochmal Gedanken machen, ob du in Wirklichkeit nicht auch etwas nutzen willst, das darauf aufbaut. Z.B. gRPC und dann halt ne Service-Discovery fürs LoadBalancing/Redundanz.

Je nach verwendeter Sprache gibts für gRPC auch coole Wrapper/Erweiterungen für die gängigen Geschichten wie retries, rate-limiting, circuit-breaker, yada yada (I'm looking at you Polly (.net core))
14.10.2021 9:19:51  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Erstmal vielen Dank für die ganzen Antworten!

Das ist alles noch ganz frühe Planungsphase, ob überhaupt was dabei rumkommt steht noch in den Sternen. Breites Grinsen Mit euren Input geht's jetzt eher Richtung klassischerer Architektur, also Broker in der Mitte, AuthZ der Nutzer am Perimeter, Rollen am Broker sind Service-Rollen, nicht Nutzer, Berechtigungen entsprechend weitgehend statisch. Anbindung der Clients via Frontend/Gateway/Proxy, Protokoll zu den Clients (die kommen auch von uns, die Clients haben wiederum ein Interface was die Kunden nutzen) mal schauen - aber wahrscheinlich ergeben sich da aus diversen externen Zwängen (wie wir AuthN tun müssen, nur einen Port benutzen, muss TCP sein, am besten multiplexfähig...) eh nur wenige Kandidaten.
15.10.2021 18:06:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
Moin, ich stelle gerade Python Code von threading auf asyncio um. Ich habe häufig so ein Pattern (vorher "WorkerThreads", jetzt irgendwie WorkerTasks oder so):

 
Code:
async def workwork(input: asyncio.Queue, output: asyncio.Queue):
    while True:
        r = await input.get()
        input.task_done()
        # bla...
        output.put(r)

task = asyncio.get_event_loop().create_task(workwork(a, b))
# Andere Dinge


Diese Loops/Tasks haben immer eine unendliche Schleife, warten auf Input, tun damit was, und schreiben irgendwohin output. Müssen nicht queues sein, kann auch ein socket sein oder StreamReader/Writer oder whatever.

Was ist der best-practice Weg, solche Tasks zu beenden? task.cancel() und den CancelledError fangen oder bestimmt man ein bestimmtes ExitEvent oder so, das man in die input Queue schiebt und woraufhin sich die Task beendet?

a)
 
Code:
async def workwork(input: asyncio.Queue, output: asyncio.Queue):
    while True:
        r = await input.get()
        input.task_done()
        if isinstance(r, ExitMessage):
            return
        # bla...
        output.put(r)


b)
 
Code:
async def workwork(input: asyncio.Queue, output: asyncio.Queue):
    while True:
        try:
            r = await input.get()
            input.task_done()
            # bla...
            output.put(r)
        except asyncio.CacelledError:
            return


Mal angenommen es wäre egal an welcher Stelle die Exception geworfen wird, also ob man output.put() noch schafft oder nicht, welchen Ansatz würdet ihr nehmen?
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 27.10.2021 14:25]
27.10.2021 14:25:32  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Das ist ne semantische Frage. Will ich einfach jetzt, sofort beenden (=> alle Tasks cancellen und Eventloop verlassen oder einfach direkt sys.exit wenn es eh egal ist) oder möchte ich ein geordnetes Herunterfahren (=> Poison Pill wie in a).
27.10.2021 16:32:45  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
Jo, ich glaube die Frage war dumm, es sind ja zwei völlig unterschiedliche Dinge. Danke, den Begriff poison pill in dem Zusammenhang kannte ich noch nicht.
29.10.2021 13:58:54  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Pago

tf2_spy.png
Servus.
Ich bin leider etwas hinterher, was aktuelle Technologien / Stacks betrifft, jedoch firmenbedingt muss ich hier jetzt aufholen.

Da ich nur sehr low-level bis jetzt unterwegs war (oder mit alten Technologien), sind die Fragen hier wohl trivial, allerdings gibt mein Google Kungfu sehr viele Buzzwords aus und bin mir daher unsicher, in welchen "Level/Niveau" man sich befindet.

Grundsätzlich ist es so, dass die Software bereits durch einen (leider selbst) programmierten Webserver es ermoeglich, WEBSERVICE Anfragen (via einer RESTApi) anzunehmen.
Ergo, wenn man ganz tief schaut, klassische GET/PUT/POST Anfragen etc. (wobei ich hier schon wenig Ahnung habe, bin eher auf der c++ Desktop Seite)

Nun moechten "wir" im Grunde auch die andere Richtung, ergo wenn sich was an unserem System ändert, informiere alle via "WEBSERVICE" / einer RESTApi, die es interessiert.

Da dies natürlich ein sehr breit gefächerter Wunsch ist, bleibt die Frage, wie man sowas so breit wie moeglich loest.

Nun kommen in den uninformierten Gesprächen dann logischerweise immer tausende aktuelle Buzzwords auf wie:
- Webhooks
- iPaaS
- Swagger
- elastic

etc. etc.
Allerdings muss ich ehrlich gestehen, dass mir das "zu hoch" ist, da es sich hier um so viele unterschiedliche Arten handelt um die Kernfrage des "welche Technologie muss hier ueberhaupt verwendet werden" noch garnicht beantworten zu koennen.

Daher geht meine Frage eher in die Richtung:
A) Welche Suchbegriffe fehlen mir, um überhaupt ein generelles Wissen bottom up zu erlangen?
Mir ist "ganz unten" klar, was passiert, ergo dass sowas wie TCP/IP oder HTTP Requests passieren muessen, ist offentsichtlich.
Nur wenn man sich solche "Anbieter" von Cloud-Diensten anschaut oder deren Versprechen einer generellen API Anbietung ueber tausenden diensten, ist mir unklar, ob das überhaupt einheitlich ist, oder zb. man sich erst wieder an jemanden "festbindet"?

Oder anders gefragt:
Wie geht Ihr mit dieser Technologie/Informationsflut um?
Oder fixiert Ihr euch eher, zb. auch firmenbedingt, auf eine bestimmte Technologie in diesem Bereich / Anbieter?
03.11.2021 8:15:22  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
Sag mal was zum Umfeld deiner Software. Wer wird informiert? FIrmenintern, oder übers Internet? Was soll passieren, wenn die Leute informiert werden? Brauchst du real-time "push", oder reicht es, wenn der client periodisch eine API nach Neuigkeiten abfragt (polling)? Was sind die Endgeräte der Nutzer?
03.11.2021 8:25:14  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Pago

tf2_spy.png
Internet.
Aktueller Datenaustausch (Beispiel Anbindung eCommerce und Update von Adressdaten).
Real-time Push zu bevorzugen, statt polling.
Endgeräte sehr sehr unterschiedlich, da es eher in die Richtung geht, soviele endpunkte wie moeglich zu bedienen (daher kommen wohl auch die Begriffe/Anbieter wie zapier/elastic/pipedream in die Unterhaltung)
03.11.2021 8:49:37  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
Aber die Endpunkte sind Serverdienste oder Client Anwendungen auf Smartphones/PCs?
03.11.2021 8:56:08  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Pago

tf2_spy.png
Die Endpunkte sind wohl hauptsächlich Serverdienste.
03.11.2021 9:01:42  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
AJ Alpha

AUP Brot 18.02.2024
Uff hier prüft mal wieder einer Floats auf Gleichheit mit Floatliteralen*


Und supplies: es geht nicht


* die nicht 0 sind
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von AJ Alpha am 03.11.2021 9:03]
03.11.2021 9:03:26  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Pago

tf2_spy.png
Da ich gerade eine Termineinladung zu einem Erstgespräch mit elastio.io bekommen habe, geht es wohl sehr stark in Richtung IPaaS, womit sich wohl 80% meiner Fragen erledigt hat.
03.11.2021 9:14:40  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Admiral Bohm

tf2_spy.png
 
Zitat von AJ Alpha

Uff hier prüft mal wieder einer Floats auf Gleichheit mit Floatliteralen*


Und supplies: es geht nicht


* die nicht 0 sind



Warte auf das surprise-pikachu wenn er -0.0 entdeckt. peinlich/erstaunt


----


Je nach Geschmack gibt es da verschiedene Event-Lösungen. Push funktioniert in der Realität oft so, dass Routinen in einer async-routine auf neue Daten in subscriptions warten.
Die Subscription füllt scih mit Daten aus einem Topic.

Generell ist ein Pub/Sub-Mechanismus (Kafka/RabbitMQ/Cloud Pubsub) ein braucbares Pattern für Eventgetriebene Datenverarbeitung.
03.11.2021 9:15:41  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
 
Zitat von Pago

Da ich gerade eine Termineinladung zu einem Erstgespräch mit elastio.io bekommen habe, geht es wohl sehr stark in Richtung IPaaS, womit sich wohl 80% meiner Fragen erledigt hat.


Server-to-Server Sachen würde ich irgendwie immer selbst bauen, ich finde diesen Trend, alles per einkauftem SaaS zu machen blöd. Wenn man beide Seiten kontrolliert, dann kann es nicht so aufwendig sein eine eigene Lösung zu bauen. Zur Not "on trigger ssh server ./action"

peinlich/erstaunt
03.11.2021 10:45:45  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Admiral Bohm

tf2_spy.png
Fixst du das dann auch am Wochenende und setzt dich mit seltsamen Verhalten bei Lastspitzen auseinander? Was ist mit multi-site-Backup?

Betrieb is Krieg, das kann jemand mit guten SRE Principles machen.
03.11.2021 10:55:42  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
 
Zitat von Admiral Bohm

Fixst du das dann auch am Wochenende und setzt dich mit seltsamen Verhalten bei Lastspitzen auseinander? Was ist mit multi-site-Backup?

Betrieb is Krieg, das kann jemand mit guten SRE Principles machen.


Kommt auf die Komplexität an. Wenn API-vom-SaaS-ansteuern auf beiden Serverseiten aufwendiger ist als eine kleine eigene Lösung, gewinnt man nicht viel. Vielleicht habe ich Pagos Situation aber auch einfach falsch eingeschätzt.

Mein "trigger via ssh" wäre ja sogar serverless (sshd ausgenommen), da "betreibt" man in dem Sinne nichts.
03.11.2021 11:00:47  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
FuSL

AUP FuSL 22.06.2012
 
Zitat von Oli

SaaS



Ich möchte an dieser Stelle https://foaas.com/ in den Raum werfen

FOAAS (Fuck Off As A Service) provides a modern, RESTful, scalable solution to the common problem of telling people to fuck off.
03.11.2021 11:16:32  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
...
Ist geblockt vom Firmenproxy. Wird schon seinen Grund haben.
03.11.2021 13:37:48  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
homer is alive

AUP homer is alive 14.03.2022
nvm
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von homer is alive am 03.11.2021 13:40]
03.11.2021 13:40:12  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Software-Entwicklung 0 ( new SammelThread() )
« erste « vorherige 1 ... 32 33 34 35 [36] 37 38 39 40 ... 51 nächste » letzte »

mods.de - Forum » Public Offtopic » 

Hop to:  

Mod-Aktionen:
27.01.2022 20:53:02 Maestro hat diesen Thread geschlossen.

| tech | impressum