Cloud basierte Anwendungen erzeugen

[Kostas]

Es gibt eben ERP-Systeme die mit python entwickelt sind und auf einer Cloud laufen. Habe ich mir nicht genauer angeschaut, aber ein aktueller Kunde schaut sich derzeit solche Systeme an. Natürlich sind die Daten dann auch irgendwo und nicht bei sich im Unternehmen. Aber das scheint den Kunden nicht oder nicht mehr wichtig zu sein. Ich kennen ein IT Team eines deutschen Autoherstellers, die haben berichtet dass sie einen neuen IT Sicherheitschef bekommen haben. Seine erste Amtshandlung war, teile der Motorenentwicklungsabteilung auf deutsche Cloud Server Anbieter zu verlagern. Keine zwei Wochen später sind die hoch sensible Daten abhanden bekommen, vermutlich an Mitbewerben, das ist nicht genau bekannt. Ihm ist nichts passiert da er passende Verträge mit den Cloud Anbieter gemacht hat.

Nochmal zurück zu Cloud Apps und Co. Für mich hört sich das unrealistisch an wenn Cloud basierte CRM und ERP Systeme benötigte Hardware nicht adressieren können. Da stimmt was nicht. Ich habe befreundete Web-Entwickler, die kennen die Probleme mit externer Hardware überhaupt nicht weil Sie sie nicht nutzen. Frage: Wie macht Ihr Reports= Antwort wir erzeugen PDFs. Frage: und wie adressiert Ihr Papierschächte? Antwort: Das PDF wird nicht ausgedruckt sondern per mail versendet. Es macht keinen Sinn mit den Leuten zu sprechen.

[TurboMagic]

Manchmal fragt man sich echt, was an einer monolithischen EXE-Datei so falsch sein soll...
(außer dass die nicht auf einem mobilen Betriebssystem läuft)

MS sollte im Tablet Bereich einfach mal besser und preiswerter werden und dort trotzdem native
Software unterstützen.

Man hat derzeit den Eindruck dass alles krampfhaft in die Cloud muss, auch wenn das dann
Abo-Gebühren usw. kostet und immer wieder Sicherheitsdesaster passieren (z. B. Azure neulich,
da musste MS zugeben, dass > 100.000 Kundedatensätze oder so offen im Netz verfügbar waren,
wegen einer "kleinen" Fehlkonfiguration). Das ist der Schwachsinn mit dem "Trends" hinterherrennen
ohne das richtig zu reflektieren.

Evtl. liegt's da auch ein wenig an uns dem Anwender klar zu machen, was er davon hat, wenn das
Zeugs nicht in der Cloud liegt und nativ läuft. Auch mal einfach aufzeigen was dann viel einfacher
umzusetzen ist und vielleicht auch mal, wieviel Strom damit gespart werden kann...

Aussprachetechnisch ist Cloud übrigens mit "klaut" verwandt

Grüße
TurboMagic

[himitsu]

Zitat von TurboMagic:

Manchmal fragt man sich echt, was an einer monolithischen EXE-Datei so falsch sein soll...

Sagen wir es mal so ... bei uns kommen ab und zu neue Kunden dazu.
Manchmal sogar mehr, als wir annehmen können, weil macht ja auch Arbeit, dieses Kundenwünsche/Anforderungen/Anpassungen/... bis hin zur Installation und Einführung.

Also gefragt scheint "eine" normale Windows-App, mit zentraler DB und einem Service schon noch zu sein.

Gut, nun aber auch mal wieder einen kleineren Kunden, dem ein "ständiglaufender" Server im Hause zu viel ist, weswegen wir DB und Apps über's Internet bei uns laufen lassen.
Wobei ja eigentlich ein kleiner Rechner/Server oder vielleicht sogar ein NAS mit Linux-Docker und Windows-VM (Service ist Windows ... noch nicht probiert, ob es auch mit Linux zum Laufen zu bekommen wäre, aber eine Fremdkomponente wäre wohl dagegen : ImageEn ... zukünftig wird die aber vermutlich rausfliegen ... wobei die ersten RuntimePackage lassen sich schon seit 'ner Weile auch für Android kompilieren und mit einer winzigen TestApp nutzen, bzw. damals im 10.2 zuletzt getestet)

[Olli73]

Also ich habe in der Vergangenheit Webanwendungen mit Delphi + UniGui entwickelt und mit Fastreport auf dem Server eine PDF erstellt und diese dann im Browser angezeigt. Druckerschächte müsste der Benutzer dann aber selbst auswählen...

Alternativ könntest du einen Windows-Service auf dem Client installieren, der per HTTP(S) mit dem Server kommuniziert und die mit der angeschlossenen Hardware kommuniziert. Dann muss dieser allerdings wieder lokal installiert werden (das ist aber vielleicht auch nicht an jedem Arbeitsplatz notwendig).