With GraphQL a modern and flexible way of providing APIs for our data is emerging.
The clients specify which data they need, the provisioning of data becomes more flexible and dynamic. Over-fetching or under-fetching are history.
But does this mean we have to rewrite all APIs to benefit? How can we retrofit a GraphQL API onto our existing API landscape?
We will explore three different approaches.

Target Audience: Architects, Developers
Prerequisites: Basic knowledge in API design and Java
Level: Advanced

Extended Abstract:
In this talk we explore three different alternatives:
- The Developer Way: Writing a GraphQL API layer by hand
- The Cloud-native Way: Using lightweight API gateways such as Gloo or Tyk
- The Serverless Way: Using Cloud Provider native services
We will look at all three approaches conceptually and justify when and why each makes sense. Additionally, we will show in a live demo how GraphQL APIs can be added to an existing REST API.

How to structure your program right? This has been a central question since the beginning of software development. Layers are a start, but not enough. Hexagonal, Onion, and Clean Architecture have joined the club together with DDD's Tactical Design and Pattern Languages. Great system design is not achieved with one of these alone. Putting all the ingredients together we can build the Architecture Hamburger – the combination that makes high quality software possible.

Target Audience: Architects, Developers
Prerequisites: Experience in mid-size to large projects
Level: Advanced

One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less.

Target Audience: Software Architects, Software Developers
Prerequisites: Basic knowledge of agile, understanding of software architecture
Level: Advanced

Extended Abstract:
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.

In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less. We model to think things through, to identify potential avenues for moving forward so that we can choose what we believe to be the most likely path for success. But the more effort we spend doing so potentially motivates us to make commitments earlier than we should and to lose time, and value, doing so. Balancing these tensions is how we determine model sufficiency in the context that we face. Proven agile architecture strategies that enable us to invest in less up-front modeling will also be explored. It's never just about modeling.

Agenda:
1. Architecture throughout the agile lifecycle.
2. What is initial architecture modeling?
3. What does it mean to be just barely good enough (JBGE)?
4. What risk factors motivate us to invest in more up-front modeling?
5. What factors enable us to invest in less up-front modeling?
6. What are the development practices that support an agile approach to architecture?

In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. This talk will help you shape an answer for the typical questions (like shall I be synchronous or asynchronous and what's a good protocol to use?). You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Developers, Architects
Prerequisites: Basic programming skills helpful
Level: Advanced

Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions about this communication:

•    What are the general possibilities to communicate? For example, synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
•    What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
•    What do I have to consider when selecting a certain communication style?

For example, you need to apply certain resilience patterns if you want to use synchronous communication.
This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Software Development based on a distributed architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. These requirements can be covered by language frameworks or the underlying platform.

This talk will walk through a comparison of various approaches with focus on frameworks, Kubernetes and extending options like Service Meshes and eBPF. The talk will be lecture style with demo.

Target Audience: Developers, Architects, DevOps
Prerequisites: Introductory style, basic IT and dev skills probably helpful, but not required
Level: Basic

Extended Abstract:
Software Development based on a cloud-native (or distributed) architecture provides both several advantages and new challenges. In order to take advantage of the distribution it requires implementation of service discovery, routing, load-balancing, resilience mechanisms and more. Initially software frameworks provided dedicated implementations for API Gateways, Service Registries, Circuit Breakers and many more. These functionalities are declared as code dependencies and need to be set at build time.

With Kubernetes there are alternative options to address these requirements. Kubernetes provides concepts for service discovery, load-balancing and resilience. So-called service meshes extend this functionality with more granular network interaction. They are not part of the application code and can hence be added during runtime. A fairly new approach is emerging with the eBPF technology, which claims to enable service meshes with minimal overhead.

With this talk Matthias wants to explain "the why" of cloud-native application design and how various cloud-native technologies facilitate this. It shows the possibilities and limitations of technologies and which forms of integration can make sense. The talk mostly consists of graphical visualisations/explanations and contains a live demo.