Dass eine Anwendung gegen Angriffe von Außen abgesichert werden muss, ist in der heutigen Zeit keine Frage mehr. Die OWASP Top10 sind in aller Munde. Um so verwunderlicher ist es, dass in den meisten Projekten die Suche nach Sicherheitslücken frühestens nach Fertigstellung der Software angegangen wird.
Dabei gibt es ein paar Möglichkeiten, bekannte Security-Probleme bereits während der Entwicklung automatisiert zu erkennen und dem Entwickler so durch geeignetes Feedback die Möglichkeit zu geben, diese zeitnah zu beheben.
Im Vortrag werden verschiedene Tools vorgestellt und gezeigt, welche Security-Probleme schon während der Entwicklung durch Continous Integration vermieden werden können.
Die Zeiten einfacher Webanwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle wie Web, Desktop, Mobile oder 3rd-Party-Clients parallel bedienen zu müssen. Und das mit einer Architektur, die am besten auch noch zukünftigen, bisher noch nicht bekannten Anforderungen standhält. Wie aber sieht eine solche Architektur aus? Welche neuen Herausforderungen ergeben sich durch die Öffnung für zusätzliche Kanäle? Und welche Auswirkungen hat das alles auf Themenbereiche wie Security, Schnittstellendesign, Versionierung oder das Domänen- bzw. Datenmodell? Im Rahmen der Session „öffnen“ wir eine klassische monolithische Webanwendung und stellen uns den Herausforderungen.
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Jeder redet von Continuous Delivery, aber was macht eine gute Development-, Testing- und Delivery-Pipeline aus? Diese Session soll zeigen, welche Schritte nötig sind, um das Ziel Continuous Delivery zu erreichen. Neben Themen wie Update- und Roll-out-Strategie werden ebenso Crash Reports und Analytics-Möglichkeiten beleuchtet.
Verstehe deine Daten! Wie App-Hersteller ihre App-Performance steigernUnivention GmbH
Nico Gulden, Product Manager bei Univention, gab auf dem Univention Summit wertvolle Tipps für App-Hersteller. Er erklärte u. a., warum es wichtig zu wissen ist, wie Produkte genutzt werden, um gute Produkte zu entwickeln. Er zeigte auch auf, welche Daten wir über die Nutzung von UCS und das App Center anonymisiert sammeln, welche Erkenntnisse wir daraus gewinnen und wie sie unsere Produktweiterentwicklung beeinflussen.
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Die Matrix: Enterprise-Architekturen jenseits von MicroservicesOPEN KNOWLEDGE GmbH
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Die Zeiten einfacher Webanwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle wie Web, Desktop, Mobile oder 3rd-Party-Clients parallel bedienen zu müssen. Und das mit einer Architektur, die am besten auch noch zukünftigen, bisher noch nicht bekannten Anforderungen standhält. Wie aber sieht eine solche Architektur aus? Welche neuen Herausforderungen ergeben sich durch die Öffnung für zusätzliche Kanäle? Und welche Auswirkungen hat das alles auf Themenbereiche wie Security, Schnittstellendesign, Versionierung oder das Domänen- bzw. Datenmodell? Im Rahmen der Session „öffnen“ wir eine klassische monolithische Webanwendung und stellen uns den Herausforderungen.
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Jeder redet von Continuous Delivery, aber was macht eine gute Development-, Testing- und Delivery-Pipeline aus? Diese Session soll zeigen, welche Schritte nötig sind, um das Ziel Continuous Delivery zu erreichen. Neben Themen wie Update- und Roll-out-Strategie werden ebenso Crash Reports und Analytics-Möglichkeiten beleuchtet.
Verstehe deine Daten! Wie App-Hersteller ihre App-Performance steigernUnivention GmbH
Nico Gulden, Product Manager bei Univention, gab auf dem Univention Summit wertvolle Tipps für App-Hersteller. Er erklärte u. a., warum es wichtig zu wissen ist, wie Produkte genutzt werden, um gute Produkte zu entwickeln. Er zeigte auch auf, welche Daten wir über die Nutzung von UCS und das App Center anonymisiert sammeln, welche Erkenntnisse wir daraus gewinnen und wie sie unsere Produktweiterentwicklung beeinflussen.
Leider existiert bei vielen Entwicklern der Irrglaube, dass mit dem Launch der eigenen App in einem der App Stores die Arbeit getan sei. Dabei geht der Spaß dann erst richtig los. Nur wer seine App als Produkt und nicht als Projekt versteht, hat auch nachhaltig die Chance auf Erfolg. Die Session zeigt, wie man durch Crash Reporting, App Analytics, geschicktes Einbinden der Usercommunity und ein gut durchdachtes Releasemanagement seine App auch nach dem ersten Launch attraktiv und erfolgreich halten kann.
Die Matrix: Enterprise-Architekturen jenseits von MicroservicesOPEN KNOWLEDGE GmbH
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Getreu dem Motto "choose Microservices for the benefits and not because your codebase is a mess." (Zitat: Simon Brown), beleuchtet die Session typische Problemstellungen aus großen Projekten und zeigt auf, für welche dieser Microservices eine Lösung darstellen und für welche eher nicht. Anhand verschiedener Real-Life-Anforderungen, werden alternative Architekturen als Lösungsansätze gezeigt und bewertet.
Die Zeiten einfacher Web-Anwendungen sind gezählt. Moderne Unternehmen stehen heute vor der Aufgabe, unterschiedlichste Kanäle, wie Web, Desktop, Mobile oder 3rd Party Clients, parallel bedienen zu müssen. Und das mit einer Architektur. Wie aber sieht eine passende Architektur aus? Welche neuen Herausforderungen ergeben sich durch die zusätzlichen Kanäle? Und welche Auswirkungen hat dies auf Aspekte wie Security, Schnittstellendesign oder das Datenmodell? In der Session „öffnen“ wir eine Web-Anwendung und stellen uns den Herausforderungen.
Oftmals wird "Multi-Channel" gleichgesetzt mit Responsive Design. Dies setzt allerdings voraus, dass jeder Channel mehr oder minder dieselben Use-Cases bedient. Ein echter Business-Mehrwert wird aber erst erreicht, wenn jeder Channel seine speziellen Eigenschaften ausspielt, was automatisch eine deutlich größere Flexibilität - auch auf Ebene der Architektur - verlangt. Genau hier setzt die Session an und zeigt, wie eine Architektur aufgebaut sein sollte, die deutlich mehr erlaubt als "nur" Responsive Design.
Man gewinnt den Eindruck, Microservices seien die Universallösung für all unsere (Architektur-)Probleme. Dabei sind Microservices lediglich Mittel zum Zweck. Was also, wenn meine Probleme nicht zur Lösung „Microservices“ passen? Ist es nach wir vor legitim, einen Monolithen zu bauen? Oder gibt es andere Architekturansätze, mit denen sich Monolithen aufbrechen lassen? In der Session werfen wir einen kritischen Blick auf Microservices und beleuchten – immer ausgehend von bestehenden Problemfeldern – eine Reihe alternativer Architekturen.
Dass eine Anwendung gegen Angriffe von Außen abgesichert werden muss, ist in der heutigen Zeit keine Frage mehr. Die OWASP Top10 sind in aller Munde. Um so verwunderlicher ist es, dass in den meisten Projekten die Suche nach Sicherheitslücken frühestens nach Fertigstellung der Software angegangen wird. Dabei gibt es ein paar Möglichkeiten, bekannte Security-Probleme bereits während der Entwicklung automatisiert zu erkennen und dem Entwickler so durch geeignetes Feedback die Möglichkeit zu geben, diese zeitnah zu beheben.
In dem Talk werden verschiedene Tools vorgestellt und gezeigt, welche Security-Probleme schon während der Entwicklung durch Continous Integration vermieden werden können.
Monolithische Mehrschichtarchitekturen scheinen ihre besten Tage hinter sich zu haben. Heute muss alles “micro”, „loosely coupled“ und „highly flexible“ sein. Ach ja, “resilient” nicht zu vergessen! Hört sich spannend an, aber was genau bedeutet das eigentlich für uns Entwickler/Architekten? Brauchen wir wirklich neue Architekturen? Und wenn ja, welche Herausforderungen ergeben sich dadurch? Mit welchen Patterns und Best Practices kann man diese Herausforderungen bewältigen? Und wie sieht überhaupt ein möglicher Migrationspfad aus, wenn man nicht das Glück hat, auf der grünen Wiese starten zu dürfen? Fragen über Fragen. Die zugehörigen Antworten auf dem Weg in eine leichtgewichtige(re) Zukunft gibt es in der Session.
Swarovski Wie mobile-optimierte Websites Umsatz und das neue Google Rating st...Dynatrace
Herr René Neubacher von Swarovski zeigt, wie er die Performance von mobilen- und Desktop Nutzern getrennt analysiert, die Visits mobiler Nutzer in Echtzeit überwacht und automatisierte Lasttests durchführt.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
Mit Solr und Elasticsearch haben Betreiber zwei erstklassige Produkte für Suche und Navigation in Online-Shops. Beide ebenbürtig, bewähren sich tagtäglich vielfach und unter äußersten Bedingungen, genießen ein gesundes Ökosystem und bieten ein mehr als attraktives Lizenzmodell. Das sind die Zutaten für erfolgreiche Shops á la eBay Kleinanzeigen, Sonepar, Zappos, Sears oder Netflix. Wie für jede geschäftskritische Suchanwendung jedoch, darf nicht nur die Technologie im Vordergrund stehen. Nicht minder wichtig sind Domänenexpertise, nachhaltige Prozesse und Liebe zum Detail. Damit kombiniert, verwandelt sich die Technologie in eine Konversionsmaschine und unterstützt Shop-Betreiber beim Erreichen ihrer Umsatzziele. Einen möglichen Weg dorthin zeigen wir Ihnen in diesem Webinar.
Das werden Sie in dem Webinar erfahren:
• Käufer brauchen Beratung. Auch in Online-Shops.
• Technologie und die Qual der Wahl
o Verspielte Chancen mit Suche „aus der Dose“
o Technologie als Wettbewerbsvorteil
o Apache Solr und Elasticsearch als die bekanntesten Protogonisten aus der Welt der lizenzkostenfreien Software
o Attraktives Lizenzmodell, gesundes Ökosystem, Unabhängigkeit vom Softwarehersteller
• Die Vierfaltigkeit einer erfolgreichen Umsetzung: Technologie, Domänenwissen, Prozesse und Liebe zum Detail
• In bester Gesellschaft mit…
• Nutzer optimal bedienen und der Weg dorthin
• Trotz Tippfehler Produkte finden mit sprachunabhängigem Ähnlichkeitsmaß
• Mit Vorschlägen (Auto-Suggest) Käufer leiten
• Long-tail optimal nutzen mit Faceted Navigation
• Eigenmarken stärken oder Promotionen abbilden
• Wissen ist Macht und der Weg zur Macht mit Logfile Analyse
o Sortimentslücken entdecken
o Trends frühzeitig erkennen
o Top-relevante SEM Keywords generieren
o Häufig falsch geschriebene Begriffe einbeziehen
o Nulltreffer identifizieren und Maßnahmen zur Vermeidung einleiten
o Abbrüche erkennen und vermeiden
• Mit Empfehlungen zum Kauf animieren mit Recommendation Engine
• Eigenheiten der Multichannel berücksichtigen mit Business Rules
In dieser Webcast-Aufzeichnung zeigt Herr Wolfram Wagner, Performance Engineer bei Endress & Hauser, anhand von Best Practice Beispielen wie ein proaktives Monitoring samt Alarmierung umgesetzt wurde, ein Echtzeit Monitoring Cockpit die Performance der Anwendungen analysiert, die Evaluierungskriterien für CDN Anbieter definiert und überprüft wurden und wie einfach Management-Reports erzeugt werden können. http://cpwr.it/EQs3U
Die DevOps-Bewegung - Einführung und Überblick
OOP 2012, 24.01.2012
Uhrzeit: 14:00 - 14:45
Sprecher: Udo Pracht
Die Bereiche Software-Entwicklung und IT-Betrieb in größeren Unternehmen haben meist eine sehr verschiedene Vorstellung davon, wie selbstentwickelte Anwendungen produktiv genommen und betreut werden. Diese unterschiedliche Zielsetzung führt zu geschäftsrelevanten Verzögerungen, Behinderungen oder gar Ausfällen. Um das Problem zu lösen, will DevOps die Zusammenarbeit von Entwicklern und Administratoren agil gestalten, deren Umgang miteinander verbessern.
Der Vortrag stellt den Ansatz und aktuellen Stand des Themas im Überblick vor.
Warum SEO (auch) Deine Aufgabe ist - WebTechCon 2016André Scharf
SEO ist Aufgabe der Experten, dafür gibt es Agenturen, die einzig und allein darauf spezialisiert sind. So oder so ähnlich ist das allgemeine Verständnis von Suchmaschinenoptimierung. Kein Wunder, denn immerhin haben wir Experten knapp zwei Jahrzehnte lang SEO als Wunderwaffe im Performancemarketing aufgebaut und damit geworben, dass wir die Einzigen sind, die die Geheimnisse der Suchalgorithmen entschlüsseln können. Mittlerweile allerdings sind diese Algorithmen so komplex, dass selbst ihre Entwickler sie nicht mehr verstehen. Was also tun? Ganz einfach: alle müssen alles richtig machen, um erfolgreich sein zu können! Wie das geht und welche Hausaufgaben wir alle – egal ob Entwickler, Marketer, Designer – zu machen haben, zeigt diese Session.
Bareos: Open Source Backup leicht gemacht (Webinar vom 10.06.2014)NETWAYS
Bareos ist der Open Source Fork der Open Source Backup Lösung Bacula und bietet trotz des jungen alters bereits sehr viele Vorteile gegenüber Bacula.
In diesem Webinar sind wir vor allem auf die Neuheiten, die Bareos Architektur und den ersten Entwurf des Bareos Webinterfaces eingegangen.
Webinare
Archiv Link: https://www.netways.de/webinare/archiv/bareos_webinare/bareos_open_source_backup_leicht_gemacht/
Aktuell: https://www.netways.de/webinare/webinare_aktuell/
NETWAYS
Konferenzen: https://www.netways.de/events_schulungen/home/
Schulungen: https://www.netways.de/events_schulungen/schulungen/home/
Shop: https://shop.netways.de/
Blog: http://blog.netways.de/
Social Media
YouTube: https://www.youtube.com/channel/UC8nIBEFmjzXjXeJV_hkkeIQ
Facebook: https://www.facebook.com/netways
Google+: https://plus.google.com/+netways/
Twitter: https://twitter.com/netways
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIOPEN KNOWLEDGE GmbH
Häufig stellt die Entwicklung einer ML-Lösung die Optimierung von Performanz-Metriken wie der "Accuracy" unter Verwendung sehr komplexer Modelle in den Fokus. Fälschlicherweise wird sich damit abgefunden, dass aufgrund der höheren Komplexität die Explainability, also die Frage nach dem "Warum verhält sich mein Modell so und nicht anders?" leiden muss. Die Folgen können schwerwiegend sein und reichen vom unwissentlich gelernten Bias aus tabellarischen Daten bis zu einer hohen Anfälligkeit gegenüber Adversarial-Attacks in Bilddaten des autonomen Fahrens.
Warum meiner Meinung nach die Explainability auch bei komplexen Modellen nicht leiden muss, möchte ich in diesem Vortrag verdeutlichen.
Hierfür werde ich verschiedene XAI-Methoden, wie z.B. die Permutation-Importance und LIME, anhand eines konkreten Anwendungsfalles vorstellen, bewerten und vergleichen. Mein Ziel ist es, für XAI zu sensibilisieren und euch einen Methoden-Kasten an die Hand zu geben, der dazu befähigt, den Blick in die Black-Box zu wagen.
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot - KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Vorausgesetzt man verfügt über gute Ideen und hinreichend viele und qualifizierte Daten. Aber wie genau kommt man zu diesen Ideen? Und wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Softwareentwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.
Weitere ähnliche Inhalte
Ähnlich wie INTEGRATION VON SECURITY-CHECKS IN DIE CI-PIPELINE
Dass eine Anwendung gegen Angriffe von Außen abgesichert werden muss, ist in der heutigen Zeit keine Frage mehr. Die OWASP Top10 sind in aller Munde. Um so verwunderlicher ist es, dass in den meisten Projekten die Suche nach Sicherheitslücken frühestens nach Fertigstellung der Software angegangen wird. Dabei gibt es ein paar Möglichkeiten, bekannte Security-Probleme bereits während der Entwicklung automatisiert zu erkennen und dem Entwickler so durch geeignetes Feedback die Möglichkeit zu geben, diese zeitnah zu beheben.
In dem Talk werden verschiedene Tools vorgestellt und gezeigt, welche Security-Probleme schon während der Entwicklung durch Continous Integration vermieden werden können.
Monolithische Mehrschichtarchitekturen scheinen ihre besten Tage hinter sich zu haben. Heute muss alles “micro”, „loosely coupled“ und „highly flexible“ sein. Ach ja, “resilient” nicht zu vergessen! Hört sich spannend an, aber was genau bedeutet das eigentlich für uns Entwickler/Architekten? Brauchen wir wirklich neue Architekturen? Und wenn ja, welche Herausforderungen ergeben sich dadurch? Mit welchen Patterns und Best Practices kann man diese Herausforderungen bewältigen? Und wie sieht überhaupt ein möglicher Migrationspfad aus, wenn man nicht das Glück hat, auf der grünen Wiese starten zu dürfen? Fragen über Fragen. Die zugehörigen Antworten auf dem Weg in eine leichtgewichtige(re) Zukunft gibt es in der Session.
Swarovski Wie mobile-optimierte Websites Umsatz und das neue Google Rating st...Dynatrace
Herr René Neubacher von Swarovski zeigt, wie er die Performance von mobilen- und Desktop Nutzern getrennt analysiert, die Visits mobiler Nutzer in Echtzeit überwacht und automatisierte Lasttests durchführt.
Da hat man einmal eine tolle Idee für eine Mobile-App und möchte sie so schnell wie möglich realisieren, und dann scheitert das Ganze am Ende am passenden Backend. Zu aufwendig und riskant die Anpassung des bestehenden Web-Backends, zu zeitintensiv und teuer die Entwicklung eines neuen Mobile-Backends. Von mangelnder Skalierung, Security und Co. ganz zu schweigen. Aber kein Grund zur Panik: Wo ein Wille ist, ist auch ein Weg. Die Session zeigt, wie bestehende Backends für Mobile-Apps „enabled“ und neue Backends on the fly via Cloud-Anbieter zur Verfügung gestellt werden können. SaaS, PaaS, BaaS und BFF heißen die Akronyme der Stunde. Was nimmt man wann? Auflösung folgt …
Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
Mit Solr und Elasticsearch haben Betreiber zwei erstklassige Produkte für Suche und Navigation in Online-Shops. Beide ebenbürtig, bewähren sich tagtäglich vielfach und unter äußersten Bedingungen, genießen ein gesundes Ökosystem und bieten ein mehr als attraktives Lizenzmodell. Das sind die Zutaten für erfolgreiche Shops á la eBay Kleinanzeigen, Sonepar, Zappos, Sears oder Netflix. Wie für jede geschäftskritische Suchanwendung jedoch, darf nicht nur die Technologie im Vordergrund stehen. Nicht minder wichtig sind Domänenexpertise, nachhaltige Prozesse und Liebe zum Detail. Damit kombiniert, verwandelt sich die Technologie in eine Konversionsmaschine und unterstützt Shop-Betreiber beim Erreichen ihrer Umsatzziele. Einen möglichen Weg dorthin zeigen wir Ihnen in diesem Webinar.
Das werden Sie in dem Webinar erfahren:
• Käufer brauchen Beratung. Auch in Online-Shops.
• Technologie und die Qual der Wahl
o Verspielte Chancen mit Suche „aus der Dose“
o Technologie als Wettbewerbsvorteil
o Apache Solr und Elasticsearch als die bekanntesten Protogonisten aus der Welt der lizenzkostenfreien Software
o Attraktives Lizenzmodell, gesundes Ökosystem, Unabhängigkeit vom Softwarehersteller
• Die Vierfaltigkeit einer erfolgreichen Umsetzung: Technologie, Domänenwissen, Prozesse und Liebe zum Detail
• In bester Gesellschaft mit…
• Nutzer optimal bedienen und der Weg dorthin
• Trotz Tippfehler Produkte finden mit sprachunabhängigem Ähnlichkeitsmaß
• Mit Vorschlägen (Auto-Suggest) Käufer leiten
• Long-tail optimal nutzen mit Faceted Navigation
• Eigenmarken stärken oder Promotionen abbilden
• Wissen ist Macht und der Weg zur Macht mit Logfile Analyse
o Sortimentslücken entdecken
o Trends frühzeitig erkennen
o Top-relevante SEM Keywords generieren
o Häufig falsch geschriebene Begriffe einbeziehen
o Nulltreffer identifizieren und Maßnahmen zur Vermeidung einleiten
o Abbrüche erkennen und vermeiden
• Mit Empfehlungen zum Kauf animieren mit Recommendation Engine
• Eigenheiten der Multichannel berücksichtigen mit Business Rules
In dieser Webcast-Aufzeichnung zeigt Herr Wolfram Wagner, Performance Engineer bei Endress & Hauser, anhand von Best Practice Beispielen wie ein proaktives Monitoring samt Alarmierung umgesetzt wurde, ein Echtzeit Monitoring Cockpit die Performance der Anwendungen analysiert, die Evaluierungskriterien für CDN Anbieter definiert und überprüft wurden und wie einfach Management-Reports erzeugt werden können. http://cpwr.it/EQs3U
Die DevOps-Bewegung - Einführung und Überblick
OOP 2012, 24.01.2012
Uhrzeit: 14:00 - 14:45
Sprecher: Udo Pracht
Die Bereiche Software-Entwicklung und IT-Betrieb in größeren Unternehmen haben meist eine sehr verschiedene Vorstellung davon, wie selbstentwickelte Anwendungen produktiv genommen und betreut werden. Diese unterschiedliche Zielsetzung führt zu geschäftsrelevanten Verzögerungen, Behinderungen oder gar Ausfällen. Um das Problem zu lösen, will DevOps die Zusammenarbeit von Entwicklern und Administratoren agil gestalten, deren Umgang miteinander verbessern.
Der Vortrag stellt den Ansatz und aktuellen Stand des Themas im Überblick vor.
Warum SEO (auch) Deine Aufgabe ist - WebTechCon 2016André Scharf
SEO ist Aufgabe der Experten, dafür gibt es Agenturen, die einzig und allein darauf spezialisiert sind. So oder so ähnlich ist das allgemeine Verständnis von Suchmaschinenoptimierung. Kein Wunder, denn immerhin haben wir Experten knapp zwei Jahrzehnte lang SEO als Wunderwaffe im Performancemarketing aufgebaut und damit geworben, dass wir die Einzigen sind, die die Geheimnisse der Suchalgorithmen entschlüsseln können. Mittlerweile allerdings sind diese Algorithmen so komplex, dass selbst ihre Entwickler sie nicht mehr verstehen. Was also tun? Ganz einfach: alle müssen alles richtig machen, um erfolgreich sein zu können! Wie das geht und welche Hausaufgaben wir alle – egal ob Entwickler, Marketer, Designer – zu machen haben, zeigt diese Session.
Bareos: Open Source Backup leicht gemacht (Webinar vom 10.06.2014)NETWAYS
Bareos ist der Open Source Fork der Open Source Backup Lösung Bacula und bietet trotz des jungen alters bereits sehr viele Vorteile gegenüber Bacula.
In diesem Webinar sind wir vor allem auf die Neuheiten, die Bareos Architektur und den ersten Entwurf des Bareos Webinterfaces eingegangen.
Webinare
Archiv Link: https://www.netways.de/webinare/archiv/bareos_webinare/bareos_open_source_backup_leicht_gemacht/
Aktuell: https://www.netways.de/webinare/webinare_aktuell/
NETWAYS
Konferenzen: https://www.netways.de/events_schulungen/home/
Schulungen: https://www.netways.de/events_schulungen/schulungen/home/
Shop: https://shop.netways.de/
Blog: http://blog.netways.de/
Social Media
YouTube: https://www.youtube.com/channel/UC8nIBEFmjzXjXeJV_hkkeIQ
Facebook: https://www.facebook.com/netways
Google+: https://plus.google.com/+netways/
Twitter: https://twitter.com/netways
Warum der Computer "Nein" sagt - Mehr Nachvollziehbarkeit dank Explainable AIOPEN KNOWLEDGE GmbH
Häufig stellt die Entwicklung einer ML-Lösung die Optimierung von Performanz-Metriken wie der "Accuracy" unter Verwendung sehr komplexer Modelle in den Fokus. Fälschlicherweise wird sich damit abgefunden, dass aufgrund der höheren Komplexität die Explainability, also die Frage nach dem "Warum verhält sich mein Modell so und nicht anders?" leiden muss. Die Folgen können schwerwiegend sein und reichen vom unwissentlich gelernten Bias aus tabellarischen Daten bis zu einer hohen Anfälligkeit gegenüber Adversarial-Attacks in Bilddaten des autonomen Fahrens.
Warum meiner Meinung nach die Explainability auch bei komplexen Modellen nicht leiden muss, möchte ich in diesem Vortrag verdeutlichen.
Hierfür werde ich verschiedene XAI-Methoden, wie z.B. die Permutation-Importance und LIME, anhand eines konkreten Anwendungsfalles vorstellen, bewerten und vergleichen. Mein Ziel ist es, für XAI zu sensibilisieren und euch einen Methoden-Kasten an die Hand zu geben, der dazu befähigt, den Blick in die Black-Box zu wagen.
Machine Learning? Ja gerne! Aber was und wie? Eine Kurzanleitung für den erfo...OPEN KNOWLEDGE GmbH
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot - KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern. Vorausgesetzt man verfügt über gute Ideen und hinreichend viele und qualifizierte Daten. Aber wie genau kommt man zu diesen Ideen? Und wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Softwareentwicklung ergeben können, und zeigt dafür passende, pragmatische Lösungsansätze auf.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die CloudOPEN KNOWLEDGE GmbH
Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster? Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten.
SPAGAT ZWISCHEN BIAS UND FAIRNESS
KI soll fair sein. Da sind wir uns alle einig. Entsprechend gilt es, eine „Voreingenommenheit“ der eigenen KI-Lösung zu vermeiden.
Leichter gesagt als getan, denn Bias kann sich an verschiedenen Stellen innerhalb des AI/ML-Lifecycles einschleichen – vom initialen Design bis hin zum produktiven Einsatz des Modells. Diese Stellen gilt es zu identifizieren und im Detail zu verstehen. Denn nicht jede Art von Voreingenommenheit ist automatisch auch böse bzw. unfair.
Die Session zeigt, wie potenzielles Auftreten von unerwünschtem Bias in der eigenen KI-Lösung aufgedeckt und vermieden werden kann.
FEHLENDE DATEN? (K)EIN PROBLEM!: Die Kunst der Data ImputationOPEN KNOWLEDGE GmbH
Leider sind die in der Praxis zur Verfügung stehenden Daten für das Training von Modellen bei weitem nicht so gut und vollständig, wie in den Lehrbüchern. Was also tun? Unvollständige Datensätze ignorieren und damit die zum Training notwendigen Daten deutlich reduzieren? Oder die Lücken besser mit sinnvollen Näherungswerten auffüllen.
Die Session zeigt, ob und wann es sinnvoll ist, fehlende Datensätze aufzufüllen und demonstriert an Real-Life Szenarien verschiedene Verfahren zur sinnvollen Ergänzung fehlender Daten. Neben einfachen Verfahren wie Mean/Median, Random Sample, Mulitple Imputation oder der Interpolationen zeitbezogenen Werte werden auch ML-basierte Imputation-Verfahren wie Regression oder Classification sowie deren potenzielle Einsatzgebiete beleuchtet. Dass fehlende Datensätze im Training auch einen positiven Effekt auf die Qualität des resultierenden Modells haben können, wird ebenfalls gezeigt.
In der Vergangenheit mussten Log-Files von Produktiv-Systemen mühsam von Hand zusammengesucht und danach durchforstet werden. Mit dem Aufkommen von Microservices gibt es jedoch immer mehr Tools, die die Aggregation und das Durchsuchen von Log-Informationen automatisieren. Den Anfang hat der ELK-Stack gemacht. Verteilte Systeme liefern jedoch heutzutage viel mehr relevante und besser aufbereitete Informationen als in den Log-Files zu finden sind. In einigen Situationen sind die in den Log-Files gefundenen Informationen unzureichend oder müssen mühsam extrahiert werden. Aus diesem Grund ist es naheliegend, die benötigten Informationen direkt in einem geeigneten Format bereitzustellen. Heutige Standards wie OpenTelemetry ermöglichen es, Informationen in dem benötigten Format zu sammeln. Werden Log-Files dadurch überflüssig? Die Session regt einen Mindset-Change an, stellt die Herausforderungen vor, die mit den verschiedenen Toolings bewältigt werden können, und erklärt, unter welchen Voraussetzungen auf Logging komplett verzichtet werden kann.
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.
From Zero to still Zero: The most beautiful mistakes going into the cloud. OPEN KNOWLEDGE GmbH
"Cloud is the new Normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Passende Blaupausen dazu gibt es mehr als genug. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloud-Anbieter glauben machen wollen? Natürlich nicht. Diese Session zeigt anhand typischer Antipattern, wie der Weg in die Cloud garantiert im Desaster endet und wie man sich dagegen wappnen kann. Ähnlichkeiten zu existierenden Projekten sind rein zufällig – oder auch nicht.
API Expand Contract ist ein Pattern zur Weiterentwicklung von APIs. Aber was verbirgt sich hinter der Idee? Wie kann ich damit eine API weiterentwickeln, ohne dass Client und/oder Server im Wartungsaufwand alter Schnittstellen(-Versionen) ersticken?
In der Realität erweist sich Management von APIs und deren Versionen als gar nicht so einfach. Diese Session zeigt mögliche Wege und Alternativen, um der Versionierungshölle zu entkommen und dabei das oberste Gebot beim API-Design - nämlich „Don’t break the Client“ - jederzeit einzuhalten.
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.
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.
Machine Learning ist eine Art von Software-Entwicklung, bei der man nicht direkt Code schreibt, sondern ein Modell anhand von Daten trainiert. Das kann in Situationen von Vorteil sein, in denen man keinen passenden Code schreiben kann oder dieser extrem komplex werden würde. TensorFlow ist das bekannteste Framework im Bereich Neuronaler Netzwerke mit dem man solche Modell erzeugen und nutzen kann. TensorFlow.js (https://js.tensorflow.org/api/latest/) implementiert die volle API von TensorFlow mit JavaScript und erlaubt sowohl die Ausführung, als auch das Training von Neuronalen Netzwerken auf jeder GPU.
Im ersten Teil des Workshops werden wir ein Modell zur Bilderkennung in einer grafischen Webanwendung trainieren und in einer eigenen Anwendung zum Laufen bringen. Hier geht es um die Grundlagen von Machine Learning und den Teil der TensorFlow.js API zum Ausführen eines Modells.
Im zweiten Teil werden wir ein eigenes Modell mit der TensorFlow.js API trainieren und als Teil einer JS-Anwendung integrieren.
Es sind keine Vorkenntnisse nötig und zur Teilnahme wird lediglich eine beliebige IDE zur Entwicklung von JavaScript benötigt.
Künstliche Intelligenz ist auf dem Vormarsch, ohne Zweifel. Egal ob Qualitätssicherung in der Produktion, Retourenmanagement im Online-Handel oder Customer-Support via Chatbot: KI eröffnet bisher noch nicht dagewesene Möglichkeiten, die eigenen Prozesse und Geschäftsmodelle deutlich zu verbessern - vorausgesetzt man verfügt über hinreichend viele und qualifizierte Daten.
Aber wie lässt sich KI in die eigene Software-Architektur integrieren? Wer befindet über das richtige Modell und den richtigen Algorithmus? Und wie wird über die hinreichende Quantität / Qualität von Daten entschieden? Die Rolle des KI-Architekten scheint geboren.
Die Session veranschaulicht die verschiedenen Herausforderungen, die sich durch das Einbinden von KI für die eigene Software-Entwicklung ergeben können und zeigt dafür passende, pragmatische Lösungsansätze auf.
KI und insbesondere Deep Learning sind der Megatrend. Dank leistungsstarker Frameworks sind erste Schritte schnell gemacht. Leider stößt man aber genauso schnell auch wieder an (seine) Grenzen. Passt das genutzte Modell überhaupt zu meinem Problem? Wie sind die gewonnenen Ergebnisse zu bewerten? Kann durch geschickte Veränderung von Modell-Parametern das Ergebnis weiter verbessert werden? In der Session werden wir unser eigenes Neuronales Netz von Grund auf aufbauen und Schritt für Schritt verbessern. Aber keine Angst: „it’s not rocket science“!
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Versteht man seine Anwendung als Kombination (fast) unabhängiger Services, so ergeben sich nicht nur für Entwicklung und Deployment neue Perspektiven.
Denn nicht nur die eigenen Services können internen oder externen Dritten zur Verfügung gestellt werden, sondern auch der umgekehrte Weg ist denkbar.
Eine entsprechend flexible Architektur vorausgesetzt, lässt sich die eigene Fachlichkeit durch 3rd Party Services sinnvoll und gewinnbringend ergänzen, ohne dabei das Rad neu erfinden zu müssen.
Besonders interessant scheint hier das Feld der künstlichen Intelligenz zu sein. Egal ob automatische Texerkennung, Retourenvorhersagen, Qualitätsicherung in der Produktion oder die Vorhersage von Terminen zur Maschinenwartung; die Möglichkeiten scheinen nahezu unbegrenzt.
Die Session zeigt, welche Möglichkeiten heute bereits Out-of-the-Box AI Services bieten und für welche Aufgaben man doch besser einen ML Experten mit ins Boot holen sollte.
Jeder Service für sich kann unabhängig deployed und skaliert werden.
Gerade Cloud Computing erleichtert in vielen Unternehmen die Verwaltung der IT-Infrastruktur. Weil die für die Software benötigte Plattformen so einfach anzumieten sind, werden Developer deshalb immer mehr in die Rolle des DevOps gedrängt -- die Software, die sie entwickeln, soll auch selbst betrieben werden -- You build it, you run it.
Doch diese Strukturierung ist nicht ganz kostenlos - Developer müssen dadurch immer mehr Verantwortung übernehmen. Um dieser Verantwortung gerecht zu werden, muss eine Schwachstelle ausgeschaltet werden: der Mensch. Im Talk gehe ich auf Prozesse der klassischen Softwareentwicklung ein und lege dar, wie diese in dem “You build it, you run it”-Modell verbessert werden.
In modernen Software-Landschaften werden die Fachlichkeiten mit Hilfe von DDD sauber voneinander abgegrenzt und als eigenständige Services umgesetzt.
Was muss in der Entwicklung eines solchen Services beachtet werden, um diese Eigenständigkeit zu gewährleisten und gleichzeitig sicherzustellen, dass alle Services gemeinsam als ein großes Ganzes funktionieren?
Service-Konsumenten sollen Schnittstellen nach Möglichkeit nutzen können, ohne Aufwand beim Anbieter der Schnittstelle zu verursachen. Das Ziel ist es, Features schnell und unabhängig umsetzen zu können.
In dem Vortrag wird vorgestellt, wie man eine hohe Nutzerzufriedenheit durch Consumer-Centric API Design und regelmäßige Produktiv-Deployments erzielt.
Möglich wird das durch ein sauberes API-Design, eine schlanke Microarchitektur und eine hohe Testautomatisierung. An praktischen Beispielen wird gezeigt, wie das erreicht werden kann.
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.
Das ist doch alles nur Frontend - Wer braucht da schon Architektur?OPEN KNOWLEDGE GmbH
Single-Page-Applications -ursprünglich als kleines fancy Frontend gestartet- sind in den letzten Jahren zu großen, schwergewichtigen eigenen Applikationen angewachsen, die fehleranfällig, schwer wartbar und langsam in der Weiterentwicklung sind. Aber woran liegt das eigentlich? Im Frontend gibt es als Abstraktion zumeist nur das Konzept der Komponenten. Eine tiefergehende Analyse der benötigten Bausteine bleibt in der Regel aus. Im Backend hingegen, erfolgen solche Analysen seit Jahren.
Aber lassen sich die Backend-Architektur-Konzepte ohne weiteres für das Frontend übernehmen? Was sind die Herausforderungen, in denen sich moderne Frontends von klassischen Backends unterscheiden? Wo braucht man daher andere Lösungen? Neben der Problemanalyse gibt dieser Talk konkrete Bausteine an die Hand.
9. Bekannte Vorfälle
• 2017
Equifax 143 Millionen
• 2016
Adult Friend Finder 422 Millionen
• 2015
Anthem 78 Millionen
• 2014
eBay 145 Millionen
JP Morgan Chase 76 Millionen
#WISSENTEILEN
10. Bekannte Vorfälle
• 2017
Equifax 143 Millionen
• 2016
Adult Friend Finder 422 Millionen
• 2015
Anthem 78 Millionen
• 2014
eBay 145 Millionen
JP Morgan Chase 76 Millionen OOPSIE!
#WISSENTEILEN
29. Warum?
• ca 90% der Anwendungen sind verwundbar
#WISSENTEILEN
30. Warum?
• ca 90% der Anwendungen sind verwundbar
• Netzwerklösungen sind nicht dafür entworfen worden auf
Anwendungslevel zu schützen
#WISSENTEILEN
31. Warum?
• ca 90% der Anwendungen sind verwundbar
• Netzwerklösungen sind nicht dafür entworfen worden auf
Anwendungslevel zu schützen
• Moderne Webanwendungen erhöhen die Sicherheitsrisiken enorm
#WISSENTEILEN
32. Warum?
• ca 90% der Anwendungen sind verwundbar
• Netzwerklösungen sind nicht dafür entworfen worden auf
Anwendungslevel zu schützen
• Moderne Webanwendungen erhöhen die Sicherheitsrisiken enorm
• Angriffe passieren im Geheimen
#WISSENTEILEN
34. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Development
Efforts
#WISSENTEILEN
35. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Development
Efforts
#WISSENTEILEN
36. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Development
Efforts
Development
Efforts
#WISSENTEILEN
37. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Version rollback
Development
Efforts
Development
Efforts
#WISSENTEILEN
38. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Impact Analysis
Version rollback
Development
Efforts
Development
Efforts
#WISSENTEILEN
39. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
40. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
41. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
42. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
43. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Reputation
damage
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
44. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Reputation
damage
Reimbursements
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
45. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Reputation
damage
Reimbursements
monitoring services
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
#WISSENTEILEN
46. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Reputation
damage
Reimbursements
monitoring services
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
Legal Costs
#WISSENTEILEN
47. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Reputation
damage
Reimbursements
monitoring services
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
Legal Costs
#WISSENTEILEN
48. Der richtige Zeitpunkt
Während der Entwicklung Nach dem Release Nach dem Datenverlust
Kosten
Re-Launch
Impact Analysis
Version rollback
Reputation
damage
Reimbursements
monitoring services
Schedule delays
Development
Efforts
Re-Launch
Impact Analysis
Version rollback
Schedule delays
Development
Efforts
Development
Efforts
Legal Costs
#WISSENTEILEN
52. OWASP & Co
• Open Web Application Security Project (OWASP)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• OWASP Top10
#WISSENTEILEN
53. OWASP & Co
• Open Web Application Security Project (OWASP)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• OWASP Top10
• Web Application Security Consortium (WASC)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• Best Practices in der Implementierung und Abwehr
#WISSENTEILEN
54. OWASP & Co
• Open Web Application Security Project (OWASP)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• OWASP Top10
• Web Application Security Consortium (WASC)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• Best Practices in der Implementierung und Abwehr
• SysAdmin, Networking and Security (SANS) Institut
• Anbieter für Cybersicherheitsschulungen und –zertifizierungen
• SANS Top20
#WISSENTEILEN
55. OWASP & Co
• Open Web Application Security Project (OWASP)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• OWASP Top10
• Web Application Security Consortium (WASC)
• Non-Profit-Organisation mit dem Ziel WWW Anwendungen sicherer zu machen
• Best Practices in der Implementierung und Abwehr
• SysAdmin, Networking and Security (SANS) Institut
• Anbieter für Cybersicherheitsschulungen und –zertifizierungen
• SANS Top20
• MITRE Corporation
• Non-Profit-Organisation für die Verwaltung von Forschungsinstituten in den USA
• CWE (Common Weakness Enumeration)
• Common Attack Pattern Enumeration and Classification (CAPEC)
#WISSENTEILEN
57. WebGoat
• Entwickelt von OWASP
• Java Spring
• Unsichere Webanwendung mit
Sicherheitslücken
• Spielwiese zum Lernen
https://github.com/WebGoat/WebGoat
#WISSENTEILEN
83. Static Application Security Testing
Vorteile
Skalierbarkeit
Präzise Fehlerbeschreibungen
Benötigt keine laufende Instanz
Entdeckt SQL Injection, Buffer
Overflows, NPE und ähnliches
Keine Auswirkungen auf
(Test-)Umgebungen
Nachteile
#WISSENTEILEN
84. Static Application Security Testing
Vorteile
Skalierbarkeit
Präzise Fehlerbeschreibungen
Benötigt keine laufende Instanz
Entdeckt SQL Injection, Buffer
Overflows, NPE und ähnliches
Keine Auswirkungen auf
(Test-)Umgebungen
Nachteile
False Positives
#WISSENTEILEN
85. Static Application Security Testing
Vorteile
Skalierbarkeit
Präzise Fehlerbeschreibungen
Benötigt keine laufende Instanz
Entdeckt SQL Injection, Buffer
Overflows, NPE und ähnliches
Keine Auswirkungen auf
(Test-)Umgebungen
Nachteile
False Positives
Entdeckt nicht alle Fehler z.B. in der
Konfiguration oder bei der
Authentifizierung
#WISSENTEILEN
89. SAST – Verwundbare Bibliotheken
CVE-2017-15708
Apache Commons Collection
Remote Code Execution während der Object Deserialisierung
in Version 3.2.2 und 4.1 behoben
#WISSENTEILEN
90. SAST – Verwundbare Bibliotheken
CVE-2017-15708
Apache Commons Collection
Remote Code Execution während der Object Deserialisierung
in Version 3.2.2 und 4.1 behoben
CVE-2018-11771
Apache Commons Compress
#WISSENTEILEN
91. SAST – Verwundbare Bibliotheken
CVE-2017-15708
Apache Commons Collection
Remote Code Execution während der Object Deserialisierung
in Version 3.2.2 und 4.1 behoben
CVE-2018-11771
Apache Commons Compress
Denial of Service beim Archiv lesen durch einen unendlichen Stream
in Version 1.18 behoben
#WISSENTEILEN
123. find-sec-bugs Beispiel
• Unsichere Hash Algorithmen z.B. MD5, SHA1
• Hard kodierte Werte z.B. Passwörter, Secret Keys
• Unsichere Cipher Benutzung, z.B. No Padding bei RSA
#WISSENTEILEN
130. sonarlint
• IDE / Editor Integration für SonarQube
• Eclipse
• Jetbrains Produkte
• Visual Studio
• VS Code
• Atom
https://www.sonarlint.org/
#WISSENTEILEN
131. sonarlint
• IDE / Editor Integration für SonarQube
• Eclipse
• Jetbrains Produkte
• Visual Studio
• VS Code
• Atom
• Kein Ersatz für PMD, findbugs und Co
https://www.sonarlint.org/
#WISSENTEILEN
132. sonarlint
• IDE / Editor Integration für SonarQube
• Eclipse
• Jetbrains Produkte
• Visual Studio
• VS Code
• Atom
• Kein Ersatz für PMD, findbugs und Co
• Regeln vergleichen!
https://www.sonarlint.org/
#WISSENTEILEN
137. Integration – IDE
Sehr hohe Sichtbarkeit für den Entwickler
wird nur lokal beim Entwickler ausgeführt
#WISSENTEILEN
138. Integration – IDE
Sehr hohe Sichtbarkeit für den Entwickler
wird nur lokal beim Entwickler ausgeführt
Keine Garantie der Ausführung
#WISSENTEILEN
139. Integration – IDE
Sehr hohe Sichtbarkeit für den Entwickler
wird nur lokal beim Entwickler ausgeführt
Keine Garantie der Ausführung
CI muss extra konfiguriert werden
#WISSENTEILEN
140. Integration – IDE
Sehr hohe Sichtbarkeit für den Entwickler
wird nur lokal beim Entwickler ausgeführt
Keine Garantie der Ausführung
CI muss extra konfiguriert werden
Konfigurationsaufwand / -pflege
#WISSENTEILEN
143. Integration – Build Tools
Kann immer ausgeführt werden
„native“ CI Unterstützung
#WISSENTEILEN
144. Integration – Build Tools
Kann immer ausgeführt werden
„native“ CI Unterstützung
Eingeschränkte Sichtbarkeit für den Entwickler
#WISSENTEILEN
145. Integration – Build Tools
Kann immer ausgeführt werden
„native“ CI Unterstützung
Eingeschränkte Sichtbarkeit für den Entwickler
Visualisierung in CI muss extra konfiguriert werden
#WISSENTEILEN
146. Integration – Build Tools
Kann immer ausgeführt werden
„native“ CI Unterstützung
Eingeschränkte Sichtbarkeit für den Entwickler
Visualisierung in CI muss extra konfiguriert werden
Konfigurationsaufwand / -pflege
#WISSENTEILEN
150. Integration – SonarQube
Hohe Sichtbarkeit für alle Entwickler
Zentrale Konfigurationspflege
Zentrale Fehlerpflege
#WISSENTEILEN
151. Integration – SonarQube
Hohe Sichtbarkeit für alle Entwickler
Zentrale Konfigurationspflege
Zentrale Fehlerpflege
o Analyse erfolgt verzögert oder Build muss warten
#WISSENTEILEN
152. Integration – SonarQube
Hohe Sichtbarkeit für alle Entwickler
Zentrale Konfigurationspflege
Zentrale Fehlerpflege
o Analyse erfolgt verzögert oder Build muss warten
o IDE Integration durch eigenes Plugin
#WISSENTEILEN
153. Integration – SonarQube
Hohe Sichtbarkeit für alle Entwickler
Zentrale Konfigurationspflege
Zentrale Fehlerpflege
o Analyse erfolgt verzögert oder Build muss warten
o IDE Integration durch eigenes Plugin
Einmaliger Installationsaufwand
#WISSENTEILEN
154. Integration – SonarQube
Hohe Sichtbarkeit für alle Entwickler
Zentrale Konfigurationspflege
Zentrale Fehlerpflege
o Analyse erfolgt verzögert oder Build muss warten
o IDE Integration durch eigenes Plugin
Einmaliger Installationsaufwand
Eigener Build Schritt in der CI / Build Tools
#WISSENTEILEN
167. Dynamic Application Security Testing
Vorteile
Entdeckt Fehler die nur zur Laufzeit
passieren können z.B.
Fehlkonfigurationen
Nachteile
#WISSENTEILEN
168. Dynamic Application Security Testing
Vorteile
Entdeckt Fehler die nur zur Laufzeit
passieren können z.B.
Fehlkonfigurationen
Analyse auf Client- und Serverseite
Nachteile
#WISSENTEILEN
169. Dynamic Application Security Testing
Vorteile
Entdeckt Fehler die nur zur Laufzeit
passieren können z.B.
Fehlkonfigurationen
Analyse auf Client- und Serverseite
Nachteile
Benötigt laufende Instanz
#WISSENTEILEN
170. Dynamic Application Security Testing
Vorteile
Entdeckt Fehler die nur zur Laufzeit
passieren können z.B.
Fehlkonfigurationen
Analyse auf Client- und Serverseite
Nachteile
Benötigt laufende Instanz
Kann Teile der Anwendungen
verpassen
#WISSENTEILEN
171. Dynamic Application Security Testing
Vorteile
Entdeckt Fehler die nur zur Laufzeit
passieren können z.B.
Fehlkonfigurationen
Analyse auf Client- und Serverseite
Nachteile
Benötigt laufende Instanz
Kann Teile der Anwendungen
verpassen
Manuelles „Zeigen“
#WISSENTEILEN
172. Dynamic Application Security Testing
Vorteile
Entdeckt Fehler die nur zur Laufzeit
passieren können z.B.
Fehlkonfigurationen
Analyse auf Client- und Serverseite
Nachteile
Benötigt laufende Instanz
Kann Teile der Anwendungen
verpassen
Manuelles „Zeigen“
Keine präzise Fehlerbeschreibungen
#WISSENTEILEN
212. Fazit
• Entwickler sind (meistens) keine Sicherheitsexperten
• Jeder muss sich mit dem Thema Sicherheit beschäftigen
#WISSENTEILEN
213. Fazit
• Entwickler sind (meistens) keine Sicherheitsexperten
• Jeder muss sich mit dem Thema Sicherheit beschäftigen
• Es muss Teil des Entwicklungsprozess sein
#WISSENTEILEN
214. Fazit
• Entwickler sind (meistens) keine Sicherheitsexperten
• Jeder muss sich mit dem Thema Sicherheit beschäftigen
• Es muss Teil des Entwicklungsprozess sein
• Entwicklerbewusstsein
#WISSENTEILEN
215. Fazit
• Entwickler sind (meistens) keine Sicherheitsexperten
• Jeder muss sich mit dem Thema Sicherheit beschäftigen
• Es muss Teil des Entwicklungsprozess sein
• Entwicklerbewusstsein
• CI Prozess
#WISSENTEILEN
216. Fazit
• Entwickler sind (meistens) keine Sicherheitsexperten
• Jeder muss sich mit dem Thema Sicherheit beschäftigen
• Es muss Teil des Entwicklungsprozess sein
• Entwicklerbewusstsein
• CI Prozess
• Niemand mag (Security-) Bugs
#WISSENTEILEN