JCON ONLINE 2022

Today's system landscapes are massively distributed: Many systems exchanging data online. Microservices, cloud native, mobile devices and the growing impact of IoT and Edge Computing reinforce the challenges of distribution: Failures constantly happen at runtime and we cannot anticipate when. Also our infrastructure cannot completely hide the failures from us. They hit us at the application level. Time to add more resilience to our applications. But how to get started? In this session, I will present 10 simple patterns that will help you to build more resilience into your applications. I will show how to implement them and what their trade-offs and hidden caveats are. Get ready for more resilience!

Hibernate and relational databases have been the standard persistence for traditional monolithic applications for decades. However, using traditional persistence concepts for cloud-native microservices is mostly oversized, complex, and expensive.

With MicroStream there is a cloud-native alternative. It is a micro persistent layer built for microservices that delivers lots of benefits. It allows persisting any Java object graph of any size and complexity in plain files, cloud blob stores, or any cloud DB. It enables ultra-fast in-memory data processing with microsecond query and response time, and now clustering and elastic auto-scaling containerized microservices. Implementing is even way faster and simpler than any database, to reduce complexity, effort, time-to-market, and cloud costs. MicroStream is open source and integrated with Micronaut and Helidon.

Die Mondlandung ist gut 50 Jahre her und die Menschheit plant erneut große Raumfahrtprogramme. Bei der ersten Mondlandung hat die IT eine wesentliche Rolle gespielt und es wurden wichtige Fundamente des Software Engineering geschaffen. Der Begriff selbst wurde von Margaret Hamilton während der Entwicklung des Apollo Guidance Computer (AGC), des Steuermoduls der Mondlandefähre, geprägt. Ich möchte etwas Software-Archäologie betreiben und mit einem Rückblick auf die bahnbrechenden Erfindungen des AGC einen Kontrastpunkt zum Technologie-Hype setzen. Für eines der ersten eingebetteten Systeme wurden Prioritätsscheduling, Multitasking und ein Echtzeitbetriebssystem entwickelt. Eine der ersten virtuellen Maschinen stellte mathematische Funktionen bereit und abstrahierte von der Hardware. Ein wesentlicher Erfolgsfaktor war die Robustheit der Software, die sich durch eine gute Fehlerbehandlung auszeichnete und vor Bedienungsfehlern abgesichert wurde, nachdem Hamiltons Tochter beim Herumspielen mit dem AGC einen Absturz verursacht hatte. Diese Eigenschaft kam Minuten vor der Landung zum Tragen und bewahrte die Mission vor dem Abbruch. Werfen wir einen Blick zurück in die Zukunft!

Java applications are widely used and often several years old. You can use these applications in the cloud via lift-and-shift (helps nothing) or you can rewrite the application in cloud-native style and use the advantages of the cloud. An alternative for existing applications is missing here. It must be possible to go to the cloud and use advantages such as serverless and scale-to-zero WITHOUT having to rewrite the entire application. I will show what is already working well today and where the rough edges are. In the session, we'll move an existing application to the cloud and save over 70% of operating and maintenance costs with serverless and scale-to-zero.

Resilient software design is around for some years meanwhile. Still, there seems to be a mismatch between popularity and progress - while patterns and libraries are quite well known for a while and microservices are still all the rage, only little progress in terms of creating better robust applications seems to be made. In this session we will examine the probably biggest obstacles and pitfalls on our way towards creating resilient systems. You will learn what they are, how you identify them and what you can do about it. Get ready to create more resilient applications.

Flexible Geschäftsmodelle benötigen flexible Softwarearchitekturen. Setzt die Softwarearchitektur die Bedürfnisse der fachlichen Domäne optimal um, können entscheidende Wettbewerbsvorteile erzielt werden. Neben einer fachlichen Ausrichtung der Softwarearchitektur werden Architekturmuster benötigt, die "Design for Change" und weiterführend "Flexibility by Design" unterstützen. Die Clean Architecture verspricht eine Entkopplung der fachlichen Domäne von infrastrukturellen Aspekten. Dies ist die Basis für eine flexible Softwarearchitektur. Die zu Grunde liegende Idee von Ports und Adapters ist mächtig und hilft technische, fachliche sowie organisatorische Flexibilität in der Anwendungsarchitektur zu realisieren. Im Vortrag Flexibile Softwarearchitektur lernen Sie Flexibilitätstreiber aus der Praxis und die Clean Architecture als Architeturmuster für "Flexibility by Design" kennen. Sie erhalten ein tiefgehendes Verständnis und können Einschätzen wann der Einsatz der Clean Architecture zielführend ist und wie Sie diese auf der technischen Ebene realisieren. Anhand von Codebeispielen in Java diskutieren wir Vorteile, Nachteile sowie Kompromisse für pragmatische Lösungen.

Almost 20 years after the start of Domain-driven Design (DDD), the approach is widely used - but that is no guarantee that DDD projects will be successful. This talk will highlight typical mistakes, misunderstandings, and problems that occur with Domain-driven Design and in particular with Strategic Design. Of course, the presentation also discusses how to solve such problems , not just to avoid failure, but even to score a true success...

Payment is part of everyday life. Whatever we buy, we need to pay for, right? For consumers this seems simple: only engineers understand the deep complexities inside payments – and consumers’ low tolerance for error. With every new feature added to a payments platform, the potential risks increase. After launching the world’s first pure-play grocery retailing website 20 years ago, we’ve developed the Ocado Smart Platform (OSP), our end-to-end online grocery fulfilment solution, adopted by 11 of the world’s most forward-thinking retailers. How did we develop our payments solution to rapidly scale, while avoiding pitfalls like highly coupled code, low cohesion modules, transactional script-based layers, anaemic models, or fragile tests? In this talk, we’ll share: 1) How we are restructuring our core payment monolith into decoupled modules - Modular Monolith - using Hexagonal Architecture driven by UseCase semantics - to improve our system’s modularity, allow for fast parallel work, and seamless evolution of the codebase. 2) Our Behaviour Driven Development based testing strategy, which allows us to freely refactor our code without tests breaking due to mocking side effects. 3) Finally, we'll share how we leverage Domain Events to increase our system's modularity.

In 2008 Amazon released their death star, a very complex graph of their MicroServices architecture. Twitter and Netflix released their own versions in 2015. The complexity and interconnectedness that were shown in those graphs highlight long-running challenges in MicroServices development that have been killing us for 15+ years. A world where MicroServices is agile and code quality meets the needs of the business sound amazing, but in reality managing, the complexities of typical Java programming standards and techniques is challenging to say the least. In this talk, we will explore the idea that the JVM and non-traditional Java programming techniques can be used to provide a compiler enforced JVM firewall, that limits the undesirable traditional broad and public access given with typical Java development. We will funnel all requests into one well-known, tested, and validated access point. This technique will limit the amount of code we write and deliver great abstractions with robust and well-tested capabilities. What we cover aligns nicely with the principles of Domain-Driven Design, allowing you to simplify the typical 100s of artifacts in each of just a few packages. This talk will also explore ideas around telemetry and reporting on throughput. We will look at test-driven development and finish up with some specific items to consider when creating your MicroServices using this technique. To round out the theory an example will be used.