pr0gg3r

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. 

Bei meinen Kommilitonen und mir im Bachelor 14-17€, im Master 16-22€. Ausreißer nach unten (Mindestlohn) und oben (25€/Std. im Bachelor) nicht inbegriffen. Großraum Stuttgart. Allerdings so weit ich weiß jeder in der Softwareentwicklung und nicht in der Administration.

Sehe ich auch so. Ein Azubi ist schließlich in der Lernphase und kein Senior-Dev bzw. -Admin. Ich finde, ein Azubi darf Fehler machen dürfen. Überall, wo ein hohes Risiko besteht, muss jemand anderes prüfen, hier sollte nicht der Azubi verantwortlich sein und wenn er doch dafür verantwortlich gemacht wird, läuft grundsätzlich etwas schief. 
Wichtig ist auch der Umgang mit Fehlern. Zum Beispiel sollte man diese nicht auf andere schieben oder versuchen zu vertuschen sondern offen und ehrlich kommunizieren: "Cheffe, ich hab hier Mist gemacht und brauch kurz deine Hilfe". Ich habe die Erfahrung gemacht, dass das genauso geschätzt wird, wie von Anfang an gute Arbeit ohne Fehler zu machen.
 

Mein Chef hat sogar gesagt das man ruhig eigene Verantwortung übernehmen soll und wenn dabei auch mal Fehler passieren das es nicht schlimm wäre, weil man eben daraus lernt. Also nicht, weil man mal einen Fehler gemacht hat direkt zurück schrecken und bestimmte Dinge nicht mehr machen...
Aus Fehlern lernt man und klar oft ist es peinlich aber das ist den besten schon passiert und wenn du in deiner Firma leute hast mit denen du auch gut reden kannst und die auch Verständnis zeigen sollte das kein Problem sein.

"Gegen die Wand fahren lassen" heißt ja nicht unbedingt, dass das ganze Projekt scheitert. Das heißt erst mal nur, dass der TE die Verantwortung nicht haben sollte die er hat, da er diese weder in seiner Position als Entwickler haben sollte, noch in seiner Gehaltsklasse liegt.
Auf jeden Fall muss der TE die Sache eskalieren, so dass von seiner Seite aus alles sauber ist. Wenn dann der Verantwortliche nicht reagiert, ist es nicht seine Schuld. Aber solange der Verantwortliche reagiert, ist das Projekt auch (noch) nicht in Gefahr. Ich zumindest habe ich die Erfahrung gemacht, dass Eskalationen erst mal nichts negatives sind, sondern manchmal sogar nötig sind, um Projekte erfolgreich abzuwickeln. Dazu muss natürlich eher früher als später eskaliert werden. Bei guten Arbeitgebern werden dann alle Projektbeteiligten in ein Eskalationsmeeting eingeladen, das Problem erörtert und eine Lösung gesucht. Wenn sowas in die Richtung nicht stattfindet, laufen grundsätzlich andere Sachen in der Firma schief.
Ich sehe das grundsätzliche Problem in den verschiedenen Rollen des "Chefs". Auf der einen Seite, möchte er jedes Projekt annehmen und verkaufen, auf der anderen Seite sollte er als Personalverantwortlicher nicht sein Team verbrennen. Das ist eben ein Konflikt. Sind die Rollen getrennt, dann kann der Teamleiter sagen: "Moment mal, wir haben nicht die nötigen Kapazitäten dafür" und man muss auch mal einen Auftrag ablehnen oder kleiner stricken.