- Back to Architecture
- Business Agility
- Design Erosion & Learning from Failure
- DevOps & Continuous Everything
- Diversity & Inclusion
- Domain-Driven Design moving forward
- Full Day Tutorial
- Fusion: IT-Future-Society
- Half Day Tutorial
- Modern C++ Programming
- Modern Enterprise Architecture
- Product Discovery, Customer Centricity & RE
- Signature Track: Back to the Future
- Social Integration
- Special Event
- Testing & Quality
- Trends & Techniques
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session.
Maximum number of participants: 75
Target Audience: Architects and Developers
Prerequisites: Java Programming
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session and you will be in a good position to put Reactive to use on your projects. We will start from foundational building blocks and scale up to full Reactive implementations. If you bring your laptop and Java 1.8+ or C# for .NET Core 2.1+ you can try out Reactive during the session.
Given an ancient codebase that makes refactoring risky and expensive, how do you clear a path to continued delivery? The old wisdom says the best time to plant a tree was 20 years ago. The next best time to preserve your software investment is today: plant a Strangler, a pattern for reaping continuous value from your existing system while growing new functionality alongside it.
We'll test-drive new features into a real legacy system. You'll leave with a powerful strategy for extending the useful life of valuable software.
Target Audience: Architects, Developers, Testers, Product Managers
Prerequisites: Familiarity with refactoring and legacy code; preference for learning-by-doing
Given an ancient codebase that makes refactoring risky and expensive, how do you clear a path to continued delivery? The old wisdom says the best time to plant a tree was 20 years ago, and the next best time is today. But if you already have a gnarled old source tree, preserve your software investment by planting a Strangler: a pattern for reaping continuous value from your existing system while growing new functionality alongside it.
We'll take a quick look at a Strangler and the basics of Mob Programming, then work together to test-drive new features into the system. You'll leave with a powerful strategy for extending the useful life of working, valuable software -- especially when it's hard to change -- and with a free bonus development practice to accelerate your team's learning. For a limited time only!
Software ist in nahezu allen Bereichen unseres Lebens unverzichtbar. Neben der Forderung, dass die Software fachlich tut, was sie soll, ist wichtig, dass unsere Softwaresysteme langfristig wartbar und erweiterbar bleiben.
In diesem Talk bekommen Zuhörende Anleitungen, Erkenntnisse, Hinweise und viele Beispiele aus der Praxis, wie die Techniken aus Domain-Driven Design für Softwaresysteme verwendet werden können, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider:innen
Voraussetzungen: Projekterfahrung, Architekturerfahrung
SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":
(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.
(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.
(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call.
(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency.
(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.
(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.
We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Apache Kafka became the de facto standard for microservice architectures. Decoupled applications and Domain-driven Design (DDD) are key benefits. However, that also introduces new challenges like observability of the whole ecosystem. This session explores the problems of distributed Microservices communication and how Kafka, Kubernetes and a Service Mesh like Istio address them. Learn some approaches for combining them to build a reliable and scalable microservice architecture with decoupled and secure microservices.
Target Audience: Software Architects, Consultants, Developers, Project Leads
Prerequisites: Experience with distributed systems / messaging frameworks is helpful
Apache Kafka became the de facto standard for microservice architectures. It goes far beyond reliable and scalable high-volume messaging. In addition, you can leverage Kafka Connect for integration and the Kafka Streams API for building lightweight stream processing microservices in autonomous teams. Decoupled applications and Domain-driven Design (DDD) are key benefits. However, microservices also introduce new challenges like observability of the whole ecosystem.
A Service Mesh technology like Istio (including Envoy) complements the architecture. It describes the network of microservices that make up such applications and the interactions between them. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
This session explores the problems of distributed Microservices communication and how both Apache Kafka and Service Mesh solutions address it together on top of Kubernetes. I cover different approaches for combining both to build a reliable and scalable microservice architecture with decoupled and secure microservices.
Microservices kommen als Architektur-Idee gut an, Kubernetes etabliert sich als ihre Laufzeitumgebung - plus seiner Komplexität.
Praktisch ist jedoch, dass es auch mit eigenen Operatoren erweitert werden kann. Sie können im Test und Deployment der Services mit all ihren definierten Abhängigkeiten und deren Konfigurationen durch Automatisierung helfen. Dies rundet Microservices ab und erleichtert das Leben.
Lassen Sie sich in die Idee und die Entwicklung von Operatoren einführen.
Zielpublikum: Entwickler:innen, DevOps
Voraussetzungen: Basiskenntnisse in Go und Kubernetes
Das Ausrollen von Microservices in einem Kubernetes-Cluster kann ein recht manueller Prozess sein, welcher sich mit externen Tools automatisieren lässt. Doch dies lässt von Service zu Service noch viel Freiraum zu, insbesondere in Bezug auf Abhängigkeiten wie Datenbanken, Message Queue und weiteren Tools.
Kubernetes Operatoren erlauben die Verlagerung der Automatisierung von außen nach innen. Die durch die Services zu nutzenden Tools und ihre Standardkonfigurationen lassen sich so zum Beispiel vordefinieren, sodass für das Rollout eines neuen Service nur mehr eine relativ begrenzte Konfiguration notwendig ist. Ebenso können Tests automatisch angestoßen werden. Die Einsatzzwecke sind vielfältig.
Die Session führt in die Idee der Operatoren ein, zeigt die Client-Bibliothek ebenso wie den Kubebuilder und nimmt dann in die Entwicklung eines Microservice Operators mit.
This talk will examine principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. It is important to commit to "stop adding to the monolith" - all new code is added as microservices; the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, when writing new microservices code, it is important to avoid dependencies to the monolith.
Target Audience: English, Developers, Architects, QAs, Testers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, focus on features provides a lot of value and starting with a monolith architecture can be advantageous. However, over time, although you might be committed to keeping the code clean, and having lots of tests — the architecture can become harder to evolve. Ultimately technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably. Also, evolving the system quickly can become harder. If things are changing quickly with lots of teams, evolving using the microservices architectural style can have many possible benefits.
Many Microservices architectures start from the evolution of a Monolith system by gradually applying the microservices architectural style. There are considerations and principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. There are good principles that help with this evolutionary process. For example, it is important to commit to "stop adding to the monolith" - all new code is added as microservices. This is the core of the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, there might be important pieces of the monolith that are getting hard to maintain and you want to pull these out. When this happens, you find design seams within the monolith, refactoring these out to components, that can ultimately be replaced with microservices. Early on, it is ok to create macro services first and then evolve (refactor) them to microservices. Also, when writing new microservices code, it is important to avoid dependencies to the monolith. Finally, you can use DDD modeling to identify aggregates and bounded contexts to pull them out from the monolith. This talk will examine various patterns when evolving from the monolith to microservices specifically with variations of the Strangler Pattern.
Raiffeisen Bank International (RBI) started in 2017 with “Group Digital Solutions” a journey in order not to oversleep the digitization of the banking industry.
Due to new approaches such as DevSecOps & Continuous Testing, the topic of software tests, whether manual or automated, had to be completely redesigned and implemented.
This talk gives insights into the test strategy & the fullstack test automation architecture that were used.
Target audience: testers, developers, architects, managers
So that Raiffeisen Bank International can keep up with digitization in the banking sector, the company relies on the use of native apps, microservices and REST APIs in the Amazon cloud when implementing its mobile banking strategy.
In order to support the DevOps mantra "Automate everything", a full stack test automation strategy was developed that is based on open source tools and takes all components of the system architecture into account.
The independent services of the microservice architecture make additional interfaces visible that are not available in a monolithic architecture. The advantage is that they can be deployed and tested independently of each other.
Testing these systems is much more complex than testing a conventional monolithic application and needs additional demands on test automation, with classic integration tests being even more important for the overall structure.
These integration tests were usefully supplemented by consumer contract tests. But end-2-end tests should not be missing either, since an effective test strategy must take into account both the isolated testing of individual services and the verification of the overall system behavior.
Aligning test automation with the classic test pyramid is a very useful approach if the individual layers are seen as the basis for “what is being tested” and not as a measure of the number of tests. Because the old wisdom still counts: “Quality over quantity!”.
Over the history of software systems, the way we build such artifacts, the way we design them, the way we express them have evolved in seemingly disruptive ways. Even today, the pendulum swings between low ceremony agile methods to more rigid waterfall-ish ones; from big balls of mud to microservices and then back to big balls of microservices. In this talk, we'll examine the past, the present, and the future of software architecture: the role it plays in software systems, and the timeless fundamentals that remain across the fullness of time.
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.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Management, Entscheider:innen
Voraussetzungen: Projekterfahrung, Enterprise Computing
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.
Eine wesentliche Auswirkung beim Einsatz einer Microservice-Architektur ist, dass ein großer Teil der Kommunikation zwischen den einzelnen Komponenten über das Netzwerk erfolgt. Um die Vorteile dieses Architekturstils auch wirklich nutzen zu können, dürfen die einzelnen Microservices lose miteinander gekoppelt sein. In dieser Session lernen Sie die grundlegenden Integrations-Muster kennen, und sehen anhand eines konkreten Szenarios, wie Sie diese Patterns zu einer funktionierenden Anwendung verknüpfen können.
Zielpublikum: Architects, Developers
Voraussetzungen: Basic architectural knowledge
Seit dem Artikel von M. Fowler und J. Lewis in 2012 sind Microservices die Antwort auf alle Fragen. Sie schienen die Antwort auf die steigende Komplexität von Softwareprojekten und Cloudanwendungen zu sein. Aber da sind Ausnahmen, die unterschiedlich beantwortet werden müssen. The Vortrag diskutiert Vorteile und Nachteile von Microservices, Modulithen und Monolithen unter Benutzung von realen Beispielen. Als Ergebnis werden Checklisten vorgestellt, die die Entscheidungen in einem solchen komplexen Umfeld einfacher machen.
Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider:innen
Voraussetzungen: Prinzipielles Verständnis von Software-Architektur
Microservices als ein einfacher Service ist einfach zu verstehen. Aber eine ganze Sammlung von ihnen ist schwierig zu verstehen. Ein Monolith als solcher ist einfach zu verstehen, aber all die komplexe Geschäftslogik innerhalb ist schwierig zu verstehen.
Wo ist die Linie zwischen beiden – was kann verstanden werden und wann wird es zu kompliziert? Der Vortrag diskutiert diese Fragen und gibt zumindest einige Antworten.
DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in with DevOps you need to provide a “Quality Delivery Pipeline” to assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners
Prerequisites: Basic Understanding of architecture and microservices and familiarity with DevOps
Many software development processes such as Agile and Lean focus on the delivery of working software that meets the needs of the end-users. Many of these development processes help teams respond to unpredictability through incremental, iterative work cadences, and through empirical feedback. There is a commitment to quickly deliver reliable working software that has the highest value to those using or benefiting from the software. DevOps has become a common practice to assist with quality delivery in these practices, specifically when developing using the microservices architectural style. DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in these practices you need to provide a “Quality Delivery Pipeline” to help assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. At the end of the pipeline the validated system will be deployed into production. There are various deployment techniques to help successfully and reliably deploy more quickly. The goal is to give confidence by providing "reliable, working software" to the user (making the user confident in the system). Also, the teams will have more confidence the system is working. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. However, to be successful organisations need to have the correct boundaries for the microservices. Using the bounded context pattern from Domain-Driven Design it is possible to achieve team autonomy!
Maximum number of participants: 24
Target Audience: Architects, Developers, Testers, Analysts, Product Owner, Manager, Decision Makers
Prerequisites: None. It is an interactive workshop, with brown paper, post-its and whiteboards
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. With the help of Continuous Delivery, teams have faster feedback cycles in which they can probe if a certain feature works. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. To be effective with a microservices architecture, we require Conway's alignment, engineering teams aligned to business models/products; to achieve Conway’s alignment it’s required to design and model the domain. Domain-Driven Design’s bounded context is the essential pattern that helps to create Conway’s alignment.
Join us in this hands-on session where we show you how visual collaboration is the most effective way in co-creating sustainable Conway’s alignment. We will distil bounded contexts with visual collaboration tools Big Picture EventStorming, Context Mapping and the Bounded Context Canvas.
With visual collaboration:
- We create a shared understanding of the business flow, uncovering inconsistencies and competing goals
- Using the Theory of Constraints, we can discover, highlight and create a shared vision and strategy to focus our effort
- A critical part of doing visual collaboration is effective facilitation, especially facilitating workshops with +30 people at the same time
You leave our session understanding that to be effective with microservices, you need to start discover and design bounded contexts. You will learn heuristics that guide you in using visual tools in specific situations, and how to move on towards microservices.