Es gibt sie doch noch: Projekte die man auf der grünen Wiese starten darf - incl. Infrastruktur. Nur AWS als Cloud Provider ist gesetzt. In dieser Session gebe ich nach den ersten Wochen Einblicke und Lessons Learned, wie wir vom Zustand eines weißen Blatt Papiers auf ein Account- und Infrastruktur-Setup gekommen sind, mit dem wir zumindest mal sofort loslegen können ohne die üblichen „Abkürzungen“ bei Qualität und Featureumfang zu gehen. Ein wesentlicher Teil davon ist das Tooling von gruntwork.io, welches in diesem Kontext kurz vorgestellt wird. [Disclaimer: Wir sind auch nur normale Kunden mit einer gruntworks-Subscription ohne weitere Connections dorthin – diese Session wird also explizit keine gruntwork.io Werbeveranstaltung, auch wenn sich das inhaltlich nicht 100%ig vermeiden lässt]
Ansible hilft bei der Automatisierung des Configuration Managements. Welche Vorteile Ansible gegenüber manueller Installation bietet und auf welchen Grundprinzipien es aufbaut beschreibt dieser Talk.
Gehalten am 15.01.2014 bei der OpenTechSchool Dortmund.
Automatisierung? ANSIBLE - Einfach. Sicher. Zuverlässig.
Ansible ist ein Open-Source Werkzeug zur Automatisierung von Deployment-, Konfigurations- und Administrationsprozessen. Die Beschreibung der Aufgaben basiert auf YAML und Jinja Templates. Es lässt sich zudem in Verbindung mit Vagrant und Docker nutzen.
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im BetriebAndreas Schmidt
http://www.continuouslifecycle.de/lecture.php?id=290
Continuous Delivery bis zum Go-Live – testgetriebenes Arbeiten im Betrieb
Ein Ziel von Continuous Delivery ist die beschleunigte Bereitstellung von Software. Die Software ist ausgeliefert – aber erst erfolgreich ausgerollt gilt als "delivered". Entwickler und Betriebler treffen an der Infrastrukturfront aufeinander: Wie viele Server, CPUs, Speicher und welche Netze werden benötigt? Und wie reden alle miteinander? Während testgetriebene Softwareentwicklung als Standard gilt, wird Infrastruktur trotz DevOps häufig manuell "hochgezogen" und selten automatisiert getestet. Der Vortrag gibt einen Überblick über Möglichkeiten und Tools, Infrastruktur testbar zu machen. Er zeigt, wie Entwicklung und Betrieb gemeinsam Infrastrukturkomponenten planen und umsetzen sollten.
Ansible hilft bei der Automatisierung des Configuration Managements. Welche Vorteile Ansible gegenüber manueller Installation bietet und auf welchen Grundprinzipien es aufbaut beschreibt dieser Talk.
Gehalten am 15.01.2014 bei der OpenTechSchool Dortmund.
Automatisierung? ANSIBLE - Einfach. Sicher. Zuverlässig.
Ansible ist ein Open-Source Werkzeug zur Automatisierung von Deployment-, Konfigurations- und Administrationsprozessen. Die Beschreibung der Aufgaben basiert auf YAML und Jinja Templates. Es lässt sich zudem in Verbindung mit Vagrant und Docker nutzen.
Continuous Lifecycle 2013: Testgetriebenes Arbeiten im BetriebAndreas Schmidt
http://www.continuouslifecycle.de/lecture.php?id=290
Continuous Delivery bis zum Go-Live – testgetriebenes Arbeiten im Betrieb
Ein Ziel von Continuous Delivery ist die beschleunigte Bereitstellung von Software. Die Software ist ausgeliefert – aber erst erfolgreich ausgerollt gilt als "delivered". Entwickler und Betriebler treffen an der Infrastrukturfront aufeinander: Wie viele Server, CPUs, Speicher und welche Netze werden benötigt? Und wie reden alle miteinander? Während testgetriebene Softwareentwicklung als Standard gilt, wird Infrastruktur trotz DevOps häufig manuell "hochgezogen" und selten automatisiert getestet. Der Vortrag gibt einen Überblick über Möglichkeiten und Tools, Infrastruktur testbar zu machen. Er zeigt, wie Entwicklung und Betrieb gemeinsam Infrastrukturkomponenten planen und umsetzen sollten.
Wie erstelle ich Webapplikationen mit Node.js. Vorgestellt werden verschiedene Frameworks wie Express.js oder Koa. Außerdem wird auf Skalierung eingegangen.
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
HashiCorp, Cloud Orchestration, IaC
Über Terraform
Terraform in Action: erste Schritte
Oracle Bare Metal Cloud Services Grundlagen
Live Demo Kubernetes on Oracle BMCS mit TF
Provisionierung von Dockerhosts und -Containern mit Terraform, Ansible und LXD auf Blech und Cloud
Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden. Dieser Vortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der (oder des) Engineers vorhanden sind.
Es wird gezeigt, wie das Verfahren sowohl auf Blech (d.h. auf lokalen physischen Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse Übereinstimmung zwischen Test-/Integrations- und Produktionsinfrastruktur erreicht wird.
Die vorgestellten Werkzeuge sind terraform und ansible für Provisionierung und Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
Mein Vortrag auf der EnterJS 2015 über Sicherheit in Node.js Applikationen. Es werden verschiedene Angriffsvektoren vorgestellt und wie man ihnen begegnen kann.
Wie erstelle ich Webapplikationen mit Node.js. Vorgestellt werden verschiedene Frameworks wie Express.js oder Koa. Außerdem wird auf Skalierung eingegangen.
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierter Enterprise-Computing-Lösungen geht. Das gilt zumindest immer dann, wenn die Anwendung als Monolith in einem Application-Server deployt werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so mit Hilfe von Nebenprojekten wie Eclipse MicroProfile den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden. Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien, aka Serverless, eine gute Figur macht.
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Ready for the Future: Jakarta EE in Zeiten von Cloud Native & CoOPEN KNOWLEDGE GmbH
Auch nach mehr als 20 Jahren ist Jakarta EE (ehemals Java EE) DER Standard, wenn es um die Entwicklung Java-basierte Enterprise Computing Lösungen geht. Dies gilt zumindest immer dann, wenn die Anwendung als Monolithen in einem Application Server deployed werden soll. Wie aber steht es mit einer Anwendung, die aus einer Vielzahl autark laufender Microservices besteht? Und wie gut schlägt sich Jakarta EE in der Cloud, in der geringer Speicherbedarf und schnelle Startzeiten gefragt sind? Die Session zeigt, wie es Jakarta EE geschafft hat, mit der Zeit zu gehen und so, mit Hilfe von Side-Projekten wie dem Eclipse MicroProfile, den Anforderungen moderner Cloud Native Anwendungen gerecht zu werden.
Ein Ausblick das Zusammenspiel mit GraalVM und Quarkus zeigt, das Jakarta EE dabei auch in extrem verteilten Cloud-Szenarien aka Serverless, eine gute Figur macht.
HashiCorp, Cloud Orchestration, IaC
Über Terraform
Terraform in Action: erste Schritte
Oracle Bare Metal Cloud Services Grundlagen
Live Demo Kubernetes on Oracle BMCS mit TF
Provisionierung von Dockerhosts und -Containern mit Terraform, Ansible und LXD auf Blech und Cloud
Lästige und aufwändige manuelle Serverinstallation kann auf einfache Art durch automatisierte Provisionierung und Konfiguration der Infrastruktur ersetzt werden. Dieser Vortrag zeigt einen Ansatz, bei dem die Definition der Infrastruktur in voll maschinenlesbarer und ausführbarer Form in einem git repo anstatt in den Köpfen der (oder des) Engineers vorhanden sind.
Es wird gezeigt, wie das Verfahren sowohl auf Blech (d.h. auf lokalen physischen Maschinen) als auch in der Cloud angewendet werden kann, und somit eine grosse Übereinstimmung zwischen Test-/Integrations- und Produktionsinfrastruktur erreicht wird.
Die vorgestellten Werkzeuge sind terraform und ansible für Provisionierung und Konfigurationsmanagement, sowie lxd (nur lokal) und docker für System- und Applikationscontainer. Die vollständige Codebasis ist auf github verfügbar, so dass alle TeilnehmerInnen auch sofort mit eigenen Experimenten loslegen können.
Mein Vortrag auf der EnterJS 2015 über Sicherheit in Node.js Applikationen. Es werden verschiedene Angriffsvektoren vorgestellt und wie man ihnen begegnen kann.
http://www.opitz-consulting.com/go/3-6-11 --- Softwareentwicklung, -test und -betrieb können durch Virtualisierung viele Vorteile erzielen. In diesem Zusammenhang werden häufig Werkzeuge für die Bereitstellung von Umgebungen eingesetzt. Verschiedene Werkzeuge adressieren aber unterschiedliche Einsatzszenarien. Wo im Applikationslebenszyklus können diese Werkzeuge sinnvoll eingesetzt werden und wie sieht es mit Kosten und Nutzen aus? ---- Unser Senior Software Architect Richard Attermeyer stellte bei der W Jax am 5.11.2014 in München die Tools Vagrant, Puppet und Docker im Einzelnen vor und erläuterte ihren Nutzen anhand von Use Cases und Live Demos. ---- Weitere Infos: https://jax.de/wjax2014/sessions/vagrant-puppet-docker-fuer-entwickler-und-architekten ---- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.---- Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 ---- Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 ---- Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im ÜberblickKarin Patenge
Ein Key-Value Store mit nativer Unterstützung für JSON, der auch Graphen und SQL “kann”. Der Foliensatz enthält detaillierte Informationen zur Nutzung der Oracle NoSQL DB aus Sicht der Anwendungsentwicklung als auch aus Sicht der Administration / des Betriebs.
Diesen Vortrag zu wichtigen Neuerungen für Single Instance, ASM, Data Guard und Co.
der Oracle Datenbank 11gR2 präsentierte OPITZ CONSULTING Consultant Christian Ballweg beim DOAG Regionaltreffen am 27.10.2010 in Essen.
Er thematisiert wichtige Neuerungen für Single Instance, ASM, Data Guard und Co.
Kuck mal, Node.js! Einstieg für .NET Entwickler mit Visual Studio Code und Ty...Gregor Biswanger
Das Jahr 2009 war die Geburtsstunde von Node.js. Dass hierbei JavaScript ebenfalls serverseitig verwendet werden kann, ist nur ein Teilaspekt für den hohen Erfolg. Viel relevanter ist die extrem hohe Performance, Skalierbarkeit und Produktivität. Nicht ohne Grund wird ASP.NET komplett neu erfunden und basiert auf den gleichen Ideen wie Node.js. Namenhafte Firmen wie Microsoft selbst, Google, PayPal, New York Times, GitHub, uvw. setzen bereits auf das leistungsstarke Node.js. Der Vortrag zeigt durch eine Reise der Node.js Architektur, woher die Vorteile kommen. Durch einen Vergleich von ähnlichen Funktionen, wird zudem der ideale Einstieg für .NET Entwickler geboten.
Java scheint mit seinem Memory- und Runtime-Overhead in Zeiten von Cloud-native und Serverless nicht wirklich gut für die Zukunft gerüstet. Erschwerend kommt hinzu, dass viele auf Java basierende Frameworks mit Annotation Scanning, Aufbau von Proxies und Caches das Start- und Speicherverhalten weiter negativ beeinflussen. Bedeutet das das Aus für Java in der Wunderwelt der Cloud? Mitnichten! Projekte wie Quarkus versuchen, Java in der Cloud zur Numero Uno werden zu lassen. Und das auf beeindruckende Art und Weise. Die Session zeigt anhand praktischer Beispiele, was heute bereits möglich ist.
Similaire à Production-ready Infrastruktur in 3 Wochen (20)
2. Was mache ich eigentlich hier?
Seit ca. 13 Jahren “entwickelnder Architekt”
… ursprünglich mal ECMAScript (4)-Jünger…
… dann auf die dunkle Seite konvertiert (JEE)
… dann kam Spring Boot…
… und jetzt AWS…
3.
4.
5. Warum ist AWS eigentlich so schwierig?
Wer von euch hat wirklich Ahnung
von DNS, Load Balancern, Firewalls, Netzwerktopologien,…?
6. Warum ist AWS eigentlich so schwierig?
Wir starten auf der komplett grünen Wiese,
vielleicht zum ersten Mal in unserem Leben
13. Welche Anforderungen haben wir an unsere Architektur?
Security-by-default
Welche Konsequenzen
haben die Aktionen von
unerfahrenen Entwicklern?
14. Welche Anforderungen haben wir an unsere Architektur?
Monitoring, Logging und hohe Dev Exp. von Anfang an
Nie wieder „öhhh da muss ich
erstmal nachgucken wie man das
nochmal macht..“
15. Welche Anforderungen haben wir an unsere Architektur?
Nur so komplex wie unbedingt nötig
Wie lange brauche ich, um einen
neuen Entwickler zu erklären wie
unser Setup funktioniert?
Wieviel Aufwand ist das initiale
Setup?
Welche Schritte sind notwendig,
um neue Clients oder APIs
onzuboarden?
16. Welche Anforderungen haben wir an unsere Architektur?
100% über versionierten Quelltext verwaltet
Wissen wir in 5 Jahren noch
exakt, was auf unseren
Blechen installiert ist?
17. Security-by-default
Nur so komplex wie
unbedingt nötig
Monitoring, Logging
und hohe Dev Experience
von Anfang an
100% über versionierten
Quelltext verwaltet
19. AWS Organization "meinProjekt"
Account "root"
Account
"security"
Account
"collab"
Account
"cicd"
Account
"qa"
Account
"stage"
Account
"prod"
Account
"spielwiese"
Reza
Philipp
André
dev
dev&qa-write
qa-full-access & stage-read & prod-read
20. Part 2: Wie war das mit der Developer Experience?
21. Wir haben schnell gemerkt, dass wir
entweder Shortcuts gehen müssen oder
noch lange mit dem Setup beschäftigt sein werden
22. Enter gruntwork.io
- Open-Source Tooling
- Infrastructure as Code Bibliothek
- Referenzarchitektur
- Viel Trainingsmaterial (Videos und Blogs)
- Support und hoher Reifegrad
- Subscription kostet 700 USD/Monat für AWS
30. In folgenden Punkten weichen wir bewusst von der
Multi-Account Referenzarchitektur ab
- Geringfügig angepasste Account-Struktur
- Wir verwenden gitlab und perspektivisch Spinnaker statt Jenkins
- Nur ein VPN von welchem alle anderen Accounts erreicht werden können
- Wir erweitern die Architektur um API und Access Management
33. Du musst nicht alles vergessen, was du über Infrastruktur weißt,
wenn du mit AWS anfängst.
Ganz im Gegenteil, die Basics im Bereich Netzwerk sind unerlässlich,
um sich schnell in AWS zurecht zu finden.
Mach es von Anfang an richtig.
Du musst das Rad nicht neu erfinden.
Jemand anders hatte bereits das gleiche Problem wie du.