welche Tools von DevOps und wie tief sollte ein Java-Programmierer wissen, der Microservice implementiert.
Er soll Docker wissen, aber wie tief? Ist es auf der DOCKERFILE-Ebene und den grundlegenden Befehlen ausreichend? Sollte er ein breiteres Wissen haben (z. B. auf Clustering-Ebene, Docker-Compose, Swarm-Docker, Pacemaker)? Sollte er Kubernetes kennen? Wie gut?
Sollte er zum Beispiel Ansible oder Puppet usw. lernen? Oder solche Tools wie ansible benutzt nur DevOps Engineer.
Mit anderen Worten, welcher Teil von DevOps sollte Microservices-Java-Developer kennen, um seine Arbeit gut zu machen.
Und noch eine Sache:
Es ist am besten, Spring Boot und Spring Cloud für Microservice zu verwenden.
Und was denkt ihr an MicroProfi oder Payara oder Wildfly Swarm? Ist es für den produktiven Betrieb geeignet? Ist es stabil und robust genug?
Irgendwie habe ich diese Überzeugung nicht und ich habe das Gefühl, dass JEE8 noch keine guten Microservices Optionen hat und dass es abgesehen von Spring Boot und Cloud keine ebenso guten Alternativen gibt. Stimmt ihr zu?
Denken Sie, dass Java EE 8 derzeit in diesem Feld bemerkenswert ist?
Ich frage mich, weil ich mich auf Microservices-Programmierung spezialisieren möchte, und ich weiß nicht, ob ich nur bei Spring Boot / Cloud bleiben soll. Ist es sinvoll Neuigkeiten zu erweitern, die seit JEE7 in JEE8 erschienen sind. Soweit ich weiß, steht in JEE8 nichts über Microservices.
Bis jemand, der eine fundiertere Antwort schreiben kann, das tut (oder, was wahrscheinlicher ist: bis jemand der meint, das tun zu können, das tut ), nur ein kurzer Link auf Fullstack: Alles ein bisschen, nichts richtig? und die im ersten Moment zynisch klingende Antwort auf die Titelfrage:
Alles
Kompetenz besteht heute nicht mehr darin, sich in einem Themenbereich auszukennen. Kompetenz besteht heute darin, mit jeder beliebigen Technik etwas machen zu können, wo man erst auf den zweiten Blick sieht, dass derjenige, der es gemacht hat, in diesem Bereich keine Kompetenz hatte. Es geht also nicht um „Kompetenz“, sondern um „Meta-Kompetenz“.
Es geht in der Praxis einfach nur darum, dass man den Bus irgendwie am Fliegen hält. Ja, es ist ein Bus, und der kann eigentlich nicht fliegen, aber das sind technische Details. Wenn du weißt, was eine dockerfile ist, dann „kennst du dich mit Docker aus“, und Kubernetes sind auch nur ein paar YML-Files…
Das sehe ich anders. Kompetenz ist halt nicht einfach da. Wenn man sich auf etwas spezialisiert, wird man in diesem Bereich schneller kompetent. Beschäftigt man sich mit mehreren Dingen, dauert es entsprechend länger, in diesem Bereich kompetent zu werden.
Natürlich ist FullStack möglich. Jedoch nicht nur mit 2-3 Jahren Berufserfahrung.
Zu der Frage:
So viel, wie für Deinen Job notwendig ist.
Docker ist sicher ein Thema, mit dem man sich beschäftigen sollte. Ansible oder Puppet würde ich nur tiefergehend betrachten, wenn ich Bock auf das Thema habe oder mein Job es erfordert.
Das sehe ich wiederum anders. Im Eingangspost stehen
Docker
Docker-Compose
Swarm-Docker
Pacemaker
Kubernetes
Ansible
Puppet
Spring Boot
Spring Cloud
MicroProfi
Payara
Wildfly Swarm
JEE8
Schon das ist nur ein winziges Fragment der Tools, die „relevant sein könnten“. Schon für Docker kann man sich auf GitHub - veggiemonk/awesome-docker: 🐳 A curated list of Docker resources and projects ca. 200 Tools ansehen, die auch „relevant sein könnten“. Und das betrifft dann nur ein winziges Fragment (nämlich die Containerisierung/Deployment) dessen, was als „FullStack“ gilt. Da ist noch kein Node.js, Express, JavaScript/TypeScript, Angular/React/Vue, Less/CSS/Pug, etc. dabei, und keine der >200 NoSQL-Datenbanken von http://nosql-database.org/ .
Natürlich kann man sich spezialisieren und Kompetenzen aneigen, vielleicht im „klassischen MEAN-Stack“. Aber „klassich“ heißt eben, dass der vor 3 Jahren „in“ war, und jetzt schon wieder „out“ ist, und wenn jemand nicht MongoDB sondern CouchDB und nicht Angular sondern React verwendet, kann man, drastisch formuliert, die Kompetenzen, die man bisher hatte, in die Mülltonne werfen und anfangen, sich „Hello World“-Tutorials durchzulesen.
Und dann besteht die „Kompetenz“ eben darin, sich die so schnell durchzulesen, dass man „bis zur Deadline ‚irgendwas zum Laufen kriegt‘“. Das wird nicht „gut“ sein. Aber solange das niemand merkt, ist ja alles gut.
Aber eigentlich ging es ja nicht speziell um „Full Stack“, sondern um Microservices (mit Java?). Man kann sich da seine für dieses Thema passenden T-shaped skills - Wikipedia aufbauen. Aber ob die „nützlich“ sind (d.h. zu irgendeiner Art vom „beruflichem Erfolg“ beitragen), … nun, das hat was von einem Glücksspiel…
… aber wenn es doch funzt UND zur deadline fertig ist, wie gut muss es denn sonst noch sein?
Klar denke ich als SW Entwickler gerne das die Qualitaet des Produktes durch den Code definiert wird, aber SW wird nunmal nicht fuer SW Entwickler, sondern von SW Entwicklern geschrieben, die paar Ausnahmen sind doch nur libs/frameworks/APIs die wiederum nur dazu dienen, SW Entwickler SW fuer nicht-SW Entwickler schreiben zu lassen
Zur Frage:
IMHO scheint zur Zeit SpringBoot, Docker/Docker-Compose/Kubernetes verbreitet zu sein da wo ich arbeite, kann sich aber schnell aendern, ansonsten weiss ich nicht was du mit „DevOps Engineer“ meinst… SRE?
Dann brauchst du davon eigentlich gar nix sondern Python/Ruby/Bash/AWS/Puppet/Ansible…
Um Docker gut zu beherrschen, muss ich nicht alle 200 Tools kennen. Ich kenne auch nicht alle Java-Frameworks. Dennoch kann ich mich in den von die genannten Technologien (bis auf Puppet und Pacemaker) ziemlich sicher bewegen. Und zwar so sicher, dass ich damit einen Betrieb übernehmen könnte (und teilweise auch übernehme).
Fullstack bedeutet ja nicht, dass ich mit allen Sprachen alle Cloud-Systeme über alle Arten von Deploymentmechanismen befeuern können muss.
Ein Qualitätsaspekt ist auf jeden Fall die Wart- und Erweiterbarkeit. Deshalb ist ein Stakeholder der Software sehr wohl auch der Softwareentwickler selber.
), nur ein kurzer Link auf 
