pr0gg3r

Du brauchst einen Google-Account und eine Kreditkarte. Ich glaube, Apps in Google Play veröffentlichen zu können kosten 25$.
Dann ist Google Play sowieso nicht das Richtige für dich. Du kannst die APK natürlich selbst irgendwo zum Download anbieten, die Installation ist für die Nutzer dann aber etwas komplizierter. Wenn es sich für eine App für einen internen Unternehmensgebrauch handelt, kannst du sie auch über eine MDM-Lösung verteilen.

Du sollst nicht nur entwickeln, sondern Entscheidungen treffen. Das heißt, du lässt den Part mit "Entwickeln mit Laravel, Vue, Vuetify usw. weg und beziehst das in deinen Entscheidungsprozess ein (Warum Laravel + Vue statt irgendein Backend das dir eine (Rest-)API zur Verfügung stellt + JS-Framework wie React oder Angular?). Wo wird das ganze deployed (cloud, hosted Server, inhouse-Server? Wie bekommen eure Kunden Zugriff darauf? Zugangsdaten, Login?). 
Wo ist ist der kaufmännische/wirtschaftliche Teil?

Das ist ein weit verbreiteter Irrglaube.
Die Big4 zahlen erst ab Senior Manager vergleichbar (~120k). Davor heißt es mit den anderen um die wenigen Managerpositionen in der Tretmühle strampeln; mit viel Arbeit und wenig Geld. Das können die sich leisten, weil ein weiterer Gehaltsbestandteil der Name im CV und die Kontakte zur Industrie sind. "Gehaltlicher Jackpott" bei den Big4 erst ab Director/Partner mit Gewinnbeteiligung.
Teilweise. 
Wenn ich einen Experten für ein Thema suche und weiß, dass ich ihn voll auslasten kann und der Kunde Summe Y dafür bezahlt, kann ich Ihm kein Gehalt > Y zahlen. Da gibt der Markt für dieses Thema eben nicht den Stundensatz her, den der Bewerber gerne hätte. So einfach ist das.
Meist sieht es jedoch anders aus. Da ist der Wasserkopf im Unternehmen so groß und die parasitären Nutznießer so zahlreich, dass der Kunde mit Summe Y dafür herhalten muss. D. h. Summe Y muss > Gehalt + Wasserkopf + Kosten für "Leistungsträger" sein. Da der Wasserkopf fix ist und das eigene Gehalt die Wichtigkeit der eigenen Person und nicht die Leistung widerspiegelt, dreht man eben an der einzig verbliebenen Variable in der Gleichung: dem Gehalt des Fließbienchens. Und wenn das Fleißbienchen es nicht einsieht, am Ende des Monats nur 25% des eigens erarbeiteten Umsatzes auf seinem Gehaltszettel wiederzufinden, dann nennt man das Fachkäftemangel!

"Drei-Mann-Buden" bekommen aber gar keine lukrative Aufträge, sondern höchstens Aufträge aus dem regionalen Bereich, wie z.B. eine Webseite für den Tante Emma-Laden um die Ecke. Das kann ich jetzt nicht eine hochwertige Aufgabe nennen.

Wieso ist das Lernen denn nicht Grund genug? Ich will gar nicht wissen, wie viele zig tausend Zeilen Code ich bereits geschrieben habe, die niemals jemand sehen oder nutzen wird. Na und? Was bringt es, privat an einer Modelleisenbahn zu basteln? Hobby vielleicht? Leidenschaft? Keine Ahnung. Man findet sicher genug Gründe. Ansonsten zwingt dich ja niemand und du kannst es bleiben lassen. Wird dich ja wohl niemand aufhalten!
Was willst du denn? Anerkennung? Dann musst du dich aber persönlich und als Entwickler sehr viel weiter entwickeln. Dann bekommst du auch irgendwann Anerkennung - zumindest wenn du etwas machst, das andere gebrauchen können UND das auch gut machst. Um etwas zu machen, was genutzt wird, musst du auch etwas entwickeln, das gebraucht wird. Bei einem Ticket-System habe ich da so meine Zweifel. Mir kommt es so vor, dass du etwas online stellst und jetzt von irgendwem erwartest, dass dein Code verwendet wird. Aber wieso soll das passieren? Weil du dich angestrengt hast? Wenn ich mich anstrenge und etwas singe und aufnehme kann ich auch nicht meckern, dass sich das niemand anhört oder sogar Geld dafür bezahlt, nur weil ich mir die Mühe gemacht habe. 

Wieso ist das Lernen denn nicht Grund genug? Ich will gar nicht wissen, wie viele zig tausend Zeilen Code ich bereits geschrieben habe, die niemals jemand sehen oder nutzen wird. Na und? Was bringt es, privat an einer Modelleisenbahn zu basteln? Hobby vielleicht? Leidenschaft? Keine Ahnung. Man findet sicher genug Gründe. Ansonsten zwingt dich ja niemand und du kannst es bleiben lassen. Wird dich ja wohl niemand aufhalten!
Was willst du denn? Anerkennung? Dann musst du dich aber persönlich und als Entwickler sehr viel weiter entwickeln. Dann bekommst du auch irgendwann Anerkennung - zumindest wenn du etwas machst, das andere gebrauchen können UND das auch gut machst. Um etwas zu machen, was genutzt wird, musst du auch etwas entwickeln, das gebraucht wird. Bei einem Ticket-System habe ich da so meine Zweifel. Mir kommt es so vor, dass du etwas online stellst und jetzt von irgendwem erwartest, dass dein Code verwendet wird. Aber wieso soll das passieren? Weil du dich angestrengt hast? Wenn ich mich anstrenge und etwas singe und aufnehme kann ich auch nicht meckern, dass sich das niemand anhört oder sogar Geld dafür bezahlt, nur weil ich mir die Mühe gemacht habe. 

DevOps ist auch ein recht neuer Begriff, der sich erst mal etablieren muss, da viele Firmen mit diesem Begriff noch nicht viel anfangen können und so nach und nach begreifen müssen, wozu DevOps benötigt wird. Den Begriff gibt es auch erst seit 4 Jahren und Deutschland gehört auch nicht zu den schnellsten IT-Ländern. Ich gehörte damals auch zu den ersten Mechatronikern auf den Arbeitsmarkt. Damals kannte den Begriff auch niemand. Nicht mal die Firmen. Die haben entweder einen Schlosser oder Elektriker gesucht. Damals musste ich den Firmen noch erklären, was eigentlich ein Mechatroniker ist oder haben sich selbst erst mal erkundigt und waren immer wieder erstaunt darüber, dass den es Beruf Mechatroniker gab, da man sich nicht vorstellen konnte, dass man zwei Berufe in einem zusammengefügt hat. Heute ist der Begriff allgegenwärtig und hat z.B. den Beruf Schlosser gänzlich ersetzt.
Deutschland ist auch noch mehr ein Land der Monolithen. Also ein großer Haufen Code, der alles kann, der noch On-Premise installiert wird. Außerdem ist hierzulande noch das Pflichten- und Lastenheft gegenwertig. Da ist CI/CD noch nicht so wichtig. Wenn man aber in Richtung agiler Softwareentwicklung denkt und den Kunden immer ein vollständiges Produkt zur Verfügung stellen möchte, dann wird CI/CD immer wichtiger und wir merken, dass es in unserem Umfeld (Banken) dies immer mehr zu einem Thema wird, da auch Banken immer mehr dazu verpflichtet werden, die Systeme auf den aktuellen Stand zu aktualisieren und sollen ihre individuelle Datenverarbeitung (IDV) abbauen. Da kommen dann inzwischen auch Themen wie SaaS oder FaaS.
Und wie @bigvic schon sagte, wenn man deine Suche als Maßstab nimmt, dann wären auch FISIs eine Nische, da 10 mal so viele Entwickler gesucht werden, wie Systemintegratoren.
Die Frage ist auch: Wie viele Personen für DevOps benötigt ein Unternehmen? Man benötigt vielleicht 40 Entwickler aber ggf. kommt man auch mit 3 DevOps aus. Das Team, dass bei uns mit CI/CD angefangen hat, besteht aus zehn Entwicklern und aus einer Person für DevOps. Wir dachten zuerst auch, dass dies die Entwickler mitübernehmen könnten aber es stellte sich heraus, dass es zu einer Vollzeitbeschäftigung wurde. Natürlich werden nicht so viele Personen für DevOps gesucht, wie für die Softwareentwicklung aber dennoch werden sie früher oder später benötigt.

Leute, vergisst die Arbeitswelt ohne Ausbildung, das hat keinen Wert...
Also ich finde den Plan, erst mittlere Reife zu machen und dann eine Ausbildung, recht solide und wüsste nicht, was dagegen spricht.
Ich würde mich an deiner Stelle erst einmal auf die mittlere Reife konzentrieren und das dann später gemeinsam mit deinem Ausbildungsbetrieb entscheiden, ob eine Verkürzung am Anfang oder Ende der Ausbildung in Frage kommt. Stand jetzt finde ich es etwas arg früh, darüber Gedanken zu machen
Wenn es dir Spaß macht, warum nicht? Ich finde, alles was das technische Denken fördert, kann man alles mal machen. Ob du jetzt zum Spaß Java lernst oder wirklich was produktives entwickelst, spielt gar nicht so groß die Rolle.
Genau so ist es. Viel Erfolg! 

Und jetzt noch ein konstruktiver Vorschlag von mir ?
Geh zu deinem Chef und sag ihm, dass du das mit dem Nebengewerbe sein lässt und du dir im Gegenzug wünschst, dass er deine Arbeitszeit von 35 Stunden pro Woche auf 40 Stunden pro Woche erhöht und das Gehalt entsprechend anpasst.

Im Grunde benötigst du eine Hochschulzulassungsberechtigung. Dabei unterscheidet man zwischen Allgemeiner Hochschulreife und Fachhochschulreife (FHR). Eine Umschulung ist dabei keine Hochschulzulassungsberechtigung. Die Allgemeine Hochschulreife erhält man über ein reguläres Abitur, also dem Abschluss an einem Gymnasium. Darüber hinaus gibt es Berufskollegs, an denen die FHR erworben wird, die zum Studieren an Fachhochschulen berechtigen. Diese genannten sind aber für Schüler konzipiert. Deshalb benötigst du etwas auf dem zweiten Bildungsweg. Hier gibt es verschiedene Möglichkeiten wie zum Beispiel Abendgymansien (wo die allgemeine Hochschulreife erworben wird) oder einjährige Berufskolleges zum Erwerb der FHR. Je nach Universität und Hochschule kann die Zulassungsberechtigung auch anders erfolgen, zum Beispiel durch Anerkennung von Arbeitserfahrung, aber darauf würde ich nicht wetten.
Einfach mal nach den fett markierten Wörtern googlen, dann solltest du erst mal genug Informationen haben. 

Hi,
Hin und wieder soll es gerüchteweise auch mal ruhigere Phasen in der IT geben, man geniesst solche Augenblicke weil sie selten sind.
 

Nur weil dir dein Betrieb eine Hersteller(?)zertifizierung bezahlt hat, und du somit zertifizierter "Nike-Schuhzubinder" bist, heißt das nicht, dass du für den Rest deines Lebens nichts anderes machen kannst/darfst/sollst als Nike Schuhe zuzubinden.
Zertifikate sind nichts Negatives, im Gegenteil: als zertifizierter Nike-Schuhzubinder hast du einerseits auch als Zubinder bei anderen Herstellern einen Vorteil (der kann schon binden, muss nur noch unsere Spezialtechnik lernen) andererseits hast du dadurch keinerlei Nachteile wenn du dich auf einen Job als Sockenzusammenleger bewirbst. Natürlich kann dein aktueller AG sagen "du bist mein bester Binder, ich setz dich nirgends anders ein" aber was soll er machen wenn du dann den Job wechselst? Dich erschießen?
Wenn du in der Ausbildung nichts anderes gemacht hast als Geräte zu reparieren, ist das eine mangelhafte Ausbildung, aber sicher keine Einbahnstraße. Such dir was anderes und freu dich, dass du bei Bedarf Geräte selbst richten kannst/darfst und nicht auf den Kundendienst warten musst.

Auch wenn @bigvic in meinen Augen recht hat und sich Trends durchaus zu Branchenstandards entwickeln, muss sich ein technischer Leiter nur bedingt immer selbst mit dem neuesten Schrei auseinander setzen. Letztendlich muss er "nur" Entscheidungen treffen. Aber er selbst muss sich nicht zwingend damit beschäftigen, das kann ja jemand anderes aus dem Team machen und ihm zuarbeiten. Wichtig ist nur, dass es gemacht wird und dass es ergebnisoffen gemacht wird, wie @Konketea geschrieben hat:
Ich zum Beispiel untersuche bzw. vergleiche derzeit oft verschiedene konventionelle und neue Technologien und deren (möglicher) Einsatz im Unternehmen, schreibe ein 3-5 Seiten Paper darüber und liefer das ab. Entscheiden tun dann jedoch andere.
Da hier gerade auch schon wieder die Diskussion um die Cloud losgeht, meine bescheidene Meinung: Es gibt nicht nur "schwarz" und "weiß". Auch gibt es in nicht nur "ja" und "nein". Letztendlich gibt es bei jeder Lösung Vor- und Nachteile, die gegenüber abzuwiegen sind. Cloud zum Beispiel macht sicherlich nicht immer Sinn, aber es gibt durchaus Szenarien wo die Vorteile überwiegen. Wobei Vorteile nicht immer nur aus technischer Sicht zu betrachten sind, sondern auch vom Usecase und Business-case (was ITler, mich eingeschlossen, auch nicht immer sehen (möchten)).
 
 

Den Einstieg in eine Leitungsposition erstmals mit 50 ausserhalb des eigenen Unternehmens halte ich für sehr schwer. Selbst innerhalb des eigenen Unternehmens würde ich da eher einen 30jährigen neu aufbauen. Und insbesondere ein technischer Leiter sollte mit dem heutigen Schnickschnack fit sein bzw. immer offen dafür permanent Neues zu lernen. Wenn du keine Lust mehr auf das Technologiehamsterrad hast, dann würde ich dir empfehlen irgendwas im ÖD zu suchen. Die sind technologisch oft eine Dekade hinterher und hast nahezu Jobsicherheit bis zur Rente.

Ich weiß nicht ob ichs richtig verstanden habe oder ob du Verständnisprobleme hast.
Erst einmal: für eine systemnahe Entwicklung (Teile des Betriebssystems(kernels), Treiber, programmierbare integrierte Schaltkreise, usw.) benötigen Assembler und/oder C. Also sobald du mit Hardware zu tun hast. Das ganze ist dann ziemlich low-level, also ein paar Schichten unter der Anwendungsentwicklung. Hierbei brauchst du umfassende IT-Kenntnisse, wie Computer und Chips funktionieren.
Ich kenne Power BI nicht, aber das sieht mir in erster Linie nach ganz normaler Anwendungssoftware aus (zumindest das Dashboard). Diese programmierst du mit einer Programmiersprache deiner Wahl, für welche es eine GUI gibt. Zum Beispiel C++, Java, C#, whatever). Anwendungsentwickler entwickeln zum Beispiel kein eigenes DBMS, verwenden dafür aber eines der unzähligen die es gibt. 
Das Problem das wir nun in der Diskussion haben: Man macht eher selten beides, denn beides sind Spezialgebiete für sich. An deiner Stelle würde ich vielleicht beides ausprobieren und dann überlegen, auf was du dich dann spezialisieren möchtest. Dazu lerne am besten Assembler und C für die systemnahe Programmierung und wenn dir das Spaß macht, bleib dabei. Ansonsten such dir irgendeine Sprache für Anwendungsentwicklung aus. 

Erreichbarkeit: natürlich kann ein Cloud-Dienst mal unerreichbar sein. Aber genauso kann die interne IT-Infrastruktur ausfallen. Vor allem bei KUM gibt es da viele Probleme, wenn der einzige IT-Mitarbeiter gerade krank oder im Urlaub ist.
Sicherheit: Ich denke mal, dass die großen Cloud-Dienste (Amazon, Google, Microsoft Azure, ...) mehr Knowhow im Bezug auf IT-Sicherheit haben, als die meisten Unternehmen und Konzerne.
"Gefrickel": Vor allem bei KUM sieht man es oft, dass sich die Anforderungen ändern, ohne dass die IT-Infrastruktur sich mit ändert, zum Beispiel wenn eine Firma wächst. Hier fehlt häufig Budget und die IT muss schauen, wie sie mit den vorhandenen Geräten zurecht kommt. Schlechte Dokumentation tut sein übriges dazu. In der Cloud kann man Dienste hinzu- und abschalten, so wie man sie benötigt.
Kosten: Cloud ist nicht billig. Einmalige Kosten für einen Server sind vermutlich billiger, als jedes Jahr X€/MA oder X€/Service zu zahlen. Jedoch braucht man dann eben auch das Personal und das Knowhow, was auch sehr hohe Kosten sind, wodurch es dann wieder ohne Cloud teurer werden kann. Wobei man in-house einen Serverraum benötigt mit Klimatisierung, man braucht Backup (am besten geographisch getrennt), eine SUV, etc. pp. 
Datenschutz: Das Thema ist natürlich nicht zu vernachlässigen. Wo stehen die Server? Gibt es Auftragsdatenverarbeitung-Verträge? Das ist vermutlich bei Cloud-Diensten ein größeres Thema.

Ich habe zwar keine Literaturempfehlung, deine Frage ist aber auch sehr allgemein und für jedes spezifische Gebiet gibt es mehr als genug Lektüre. Du würfelst viele Begriffe durcheinander, darum plauder ich einfach mal aus dem Nähkästchen, da ich vor allem in diesem Bereich arbeite und zu tun habe.
Dadurch, dass man heutzutage viele Endgeräte hat (Browser, Smartphone-App, Smart-TV-App, was auch immer), geht man weg von serverseitigem Rendering über (Script)Sprachen wie PHP, Python (Django-Framework), usw. hin zu Schnittstellen (z.B. Rest), auf die dann von jeder App aus zugegriffen wird.
Im Web-Frontend sieht es nun so aus, dass Single-Page-Applications (SPAs) entwickelt werden. Diese bestehen, wie der Name sagt, aus einer einzigen Seite. Das realisiert man vor allem mit JavaScript-Frameworks wie React, Angular (was ich hauptsächliche mache), VueJS o.Ä.
Für die (REST-)API benötigt man natürlich auch einen Server. Dies kann bei einfachen Servern einfach eine Applikation sein, die Anfragen annimmt und Resultate zurück gibt. Zum Beispiel könnte man das auch mit serverseitigem Rendering über PHP machen, häufiger wird aber NodeJS (ggf. auch mit Express, NestJS oder einem anderen Framework) verwendet. Manche MVC-Frameworks wie Django bieten auch REST-Schnittstellen mit an. Das reicht erst mal für kleine Applikationen völlig aus.
Werden Projekte aber nun größer, wird eine skalierung notwendig. Hierbei gibt es verschiedene Strategien. Man könnte zum Beispiel X Server hinstellen, auf denen X mal die gleiche Serveranwendung läuft und einen Proxy davor, der die Anfragen verteilt. Bei großen Applikationen ist es jedoch so, dass nicht alle "Teile" der Software gleich häufig verwendet werden. Darum verwendet man sogenannte "Microservices". Jeder Microservice ist ein Teil der Software, zum Beispiel ein Microservice für die Authentifizierung, einen für eine Timeline, einen um Bilder anzuzeigen, ein anderer für den Warenkorb, der nächste hat eine KI-Applikation laufen, die Informationen aus Bildern herausliest, die hochgeladen werden. Jeder Mircroservice kann in einem (Docker-)Container laufen und je nach Auslastung, kann orchestriert werden (z.B. über Kubernetes), also zusätzliche Container hochgefahren oder abgeschaltet werden. Mircoservices haben zudem den Vorteil, dass jeder Microservice mit einer anderen, dafür geeigneten Technologie entwickelt werden kann. Zum Beispiel kann der eine Container eine PHP-App beinhalten, der andere NodeJS mit ner MongoDB, der nächste Python, usw. Jede Abteilung kann also die Technologie verwenden, welche für ihre Zwecke am besten ist (z.B. ist Python für KI-Geschichten besser geeignet als PHP).
Die Verwendung einer Microservice-Struktur hat spezielle Anforderungen. Zum Beispiel, wie autorisiert man einen Benutzer in den Containern untereinander? Was soll passieren, wenn ein Service zu lange für ein Response braucht? Wie kommunizieren die Container untereinander (muss nicht über REST sein)? Das sind alles Fragen, die man zu beantworten bzw. zu lösen hat.
Hast du auf all das keine Lust oder Ressourcen oder das Knowhow, kannst du auch auf "serverless" setzen. Hierbei wird dir die Schnittstelle vom Serverless-Anbieter angeboten. Du benutzt einfach über deren Software-Libraries um deren User-Auth, Datenbank, Storage, usw. zu verwenden und musst dich dann nicht um die Skalierung dahinter kümmern. Dafür musst du das dann natürlich auch (ab einer gewissen Größe) bezahlen.
Ich mag den Begriff nicht sonderlich, aber ich würde zu der Aussage eher "jein" sagen. Dev-Ops hat in meinen Augen mehr mit Continuous Integration und Continuous Delivery zu tun, wobei es natürlich auch Schnittpunkte mit den oben genannten Technologien gibt, zum Beispiel indem man Container baut, testet und (in einer orchestrierten Umgebung) deployed.
Lange Rede kurzer Sinn: befass dich einfach nach und nach mit den Technologien. Baue eine kleine SPA, mit einem kleinen Server dahinter, schieb den in einen Container rein und bastel da einfach mal am besten rum. An Dinge wie Orchestrierung würde ich mir erst mal keine Gedanken machen, das kommt dann mit der Zeit. Wenn du dich eher in Richtung DevOps entwickeln möchtest, wäre vlt. ein guter Ansatz, agile Softwareentwicklung zu verstehen und wie DevOps dabei unterstützt.
 

Ich habe zwar keine Literaturempfehlung, deine Frage ist aber auch sehr allgemein und für jedes spezifische Gebiet gibt es mehr als genug Lektüre. Du würfelst viele Begriffe durcheinander, darum plauder ich einfach mal aus dem Nähkästchen, da ich vor allem in diesem Bereich arbeite und zu tun habe.
Dadurch, dass man heutzutage viele Endgeräte hat (Browser, Smartphone-App, Smart-TV-App, was auch immer), geht man weg von serverseitigem Rendering über (Script)Sprachen wie PHP, Python (Django-Framework), usw. hin zu Schnittstellen (z.B. Rest), auf die dann von jeder App aus zugegriffen wird.
Im Web-Frontend sieht es nun so aus, dass Single-Page-Applications (SPAs) entwickelt werden. Diese bestehen, wie der Name sagt, aus einer einzigen Seite. Das realisiert man vor allem mit JavaScript-Frameworks wie React, Angular (was ich hauptsächliche mache), VueJS o.Ä.
Für die (REST-)API benötigt man natürlich auch einen Server. Dies kann bei einfachen Servern einfach eine Applikation sein, die Anfragen annimmt und Resultate zurück gibt. Zum Beispiel könnte man das auch mit serverseitigem Rendering über PHP machen, häufiger wird aber NodeJS (ggf. auch mit Express, NestJS oder einem anderen Framework) verwendet. Manche MVC-Frameworks wie Django bieten auch REST-Schnittstellen mit an. Das reicht erst mal für kleine Applikationen völlig aus.
Werden Projekte aber nun größer, wird eine skalierung notwendig. Hierbei gibt es verschiedene Strategien. Man könnte zum Beispiel X Server hinstellen, auf denen X mal die gleiche Serveranwendung läuft und einen Proxy davor, der die Anfragen verteilt. Bei großen Applikationen ist es jedoch so, dass nicht alle "Teile" der Software gleich häufig verwendet werden. Darum verwendet man sogenannte "Microservices". Jeder Microservice ist ein Teil der Software, zum Beispiel ein Microservice für die Authentifizierung, einen für eine Timeline, einen um Bilder anzuzeigen, ein anderer für den Warenkorb, der nächste hat eine KI-Applikation laufen, die Informationen aus Bildern herausliest, die hochgeladen werden. Jeder Mircroservice kann in einem (Docker-)Container laufen und je nach Auslastung, kann orchestriert werden (z.B. über Kubernetes), also zusätzliche Container hochgefahren oder abgeschaltet werden. Mircoservices haben zudem den Vorteil, dass jeder Microservice mit einer anderen, dafür geeigneten Technologie entwickelt werden kann. Zum Beispiel kann der eine Container eine PHP-App beinhalten, der andere NodeJS mit ner MongoDB, der nächste Python, usw. Jede Abteilung kann also die Technologie verwenden, welche für ihre Zwecke am besten ist (z.B. ist Python für KI-Geschichten besser geeignet als PHP).
Die Verwendung einer Microservice-Struktur hat spezielle Anforderungen. Zum Beispiel, wie autorisiert man einen Benutzer in den Containern untereinander? Was soll passieren, wenn ein Service zu lange für ein Response braucht? Wie kommunizieren die Container untereinander (muss nicht über REST sein)? Das sind alles Fragen, die man zu beantworten bzw. zu lösen hat.
Hast du auf all das keine Lust oder Ressourcen oder das Knowhow, kannst du auch auf "serverless" setzen. Hierbei wird dir die Schnittstelle vom Serverless-Anbieter angeboten. Du benutzt einfach über deren Software-Libraries um deren User-Auth, Datenbank, Storage, usw. zu verwenden und musst dich dann nicht um die Skalierung dahinter kümmern. Dafür musst du das dann natürlich auch (ab einer gewissen Größe) bezahlen.
Ich mag den Begriff nicht sonderlich, aber ich würde zu der Aussage eher "jein" sagen. Dev-Ops hat in meinen Augen mehr mit Continuous Integration und Continuous Delivery zu tun, wobei es natürlich auch Schnittpunkte mit den oben genannten Technologien gibt, zum Beispiel indem man Container baut, testet und (in einer orchestrierten Umgebung) deployed.
Lange Rede kurzer Sinn: befass dich einfach nach und nach mit den Technologien. Baue eine kleine SPA, mit einem kleinen Server dahinter, schieb den in einen Container rein und bastel da einfach mal am besten rum. An Dinge wie Orchestrierung würde ich mir erst mal keine Gedanken machen, das kommt dann mit der Zeit. Wenn du dich eher in Richtung DevOps entwickeln möchtest, wäre vlt. ein guter Ansatz, agile Softwareentwicklung zu verstehen und wie DevOps dabei unterstützt.
 

https://cloud.google.com/about/locations/?hl=de&region=europe#region
https://support.google.com/firebase/answer/9019185?hl=de
Glaub mir, ein Gang zum Anwalt wird dir definitiv nicht erspart bleiben. Du musst dir bewusst sein, dass dich das ganze einige tausend Euro kosten wird. Aber alleine, ohne juristisches Wissen im Bezug Datenschutz und Digitales wirst du nicht weit kommen und Halbwissen aus dem Internet ist eher schädlich als förderlich.
 

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Der TE hat gar nix weiter gepostet, daher ist der Rest reine Spekulation. Wenn alle so ticken würden und sich abschrecken ließen, gebe es diese Unternehmen erst gar nicht. Mir geht es nicht um ehrliche Erfahrung, sondern das dem Poster irgendwas unterstellt wird und der Tenor „packste eh net“ und so ein Schwachsinn wie „Schwanzverlängerung“, echt jetzt? Er solls machen, vllt finde er es super + hat Glück. Was soll schon gross passieren. Alles eine Erfahrung wert.
Davon abgesehen ist manchmal ein bisschen Naivität nicht verkehrt.

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Um es vorsichtig auszudrücken: Ich denke nicht dass wegen dem Inhalt der Antwort die Stimmung gekippt ist. ich denke viel eher, dass du - vermutlich ohne es zu merken - pampig oder trotzig reagiert hast, nachdem mehrmals nachgehakt wurde. Also dass die anderen gemerkt haben, dass die Stimmung in dir innerlich gekippt ist und du es nach außen hast anmerken lassen. Selbst wenn man sich unwohl fühlt, einfach solche Sachen mit nem coolen Spruch abhacken und auf ein anderes Thema lenken, zum Beispiel indem man fragt, wo die Kollegen denn so im Urlaub waren und was sie empfehlen können.

Alles, was du über den Browser anzeigen lassen möchtest (in diesem Fall $storagefile_srv01_user_verzeichnis_dokumente.$file) muss über HTTP erreichbar sein. Um das zu erreichen, gibt es verschiedene Möglichkeiten:
Das Verzeichnis /var/www/cloud_storage/ über HTTP verfügbar machen. Dazu musst du, je nachdem was für eine Server-Software (z.B. Apache oder nginx) du verwendest, entsprechend die Konfiguration des Webservers anpassen. Zum Beispiel machst du die Dateien darin unter "storage.domain.tld" verfügbar, dann lautet die Adresse zum Bild http://storage.domain.tld/$file. Das bringt den Nachteil mit sich, dass alle Dateien dort frei zugänglich sind. Du kopierst die abzurufenden Daten erst in ein von HTTP erreichbares Verzeichnis, dann bindest du das Bild entsprechend ein. Dann sammeln sich aber die Dateien nochmal an einer anderen Stelle an, deshalb ist das nicht zu empfehlen. Vielleicht könnte man irgendwelche Linux-Spielereien wie einen Symlink auf das cloud_storage-Verzeichnis machen, um die Dateien aus /var/www/html/... zugänglich zu machen. Du könntest ein PHP-Script "get-file.php?file=foo.bar" schreiben, das dann die Datei einliest und zurück gibt, indem es die Datei /var/www/cloud_storage/foo.bar einliest und den Inhalt einfach ausgibt. Hierbei nicht vergessen, den Content-Type header anzupssen, dass dieser zur gespeicherten Datei passt.