The One with Architecture & Design 2021

Software architecture emerged in the 1990s, and has been evolving ever since, from a directive, up-front activity, where a single architect created the architecture, which was then implemented by others, to today’s team based adaptive architectural approaches where architecture is a shared activity owned by the entire team. In this talk we’ll explore the architectural practices that deliver architecture as a “shared commons” which supports the Agile+DevOps ways-of-working needed for success in the digital age.

The goal of architecture is to simplify the most complex parts of your logic. Any other goal should be secondary to this. The problem is that you can’t always anticipate where the complexity of your application will accumulate, especially when confronted with ever-changing requirements. The only way to keep your code simple is to gradually evolve the architecture without adding useless complexity up front, but always looking out for opportunities to break-down and refactor towards the most simple design that solves the problem. Drawing concepts from the Domain-Driven Development mindset, this talk summarizes the most important lessons learned designing and consulting many real-world projects. Along the way, you’ll hear about Value Objects and Entities, DTOs, Dependency Inversion Principle, Facades, the Onion Architecture and many pragmatic tips and tricks immediately applicable to your day-to-day work.

A glimpse into Mambu’s journey of breaking into microservices to continue their success and enable innovation in the banking sector. In this presentation you will see how they created a systemic approach of breaking the monolith by identifying capabilities, prioritizing their extraction and by preparing solid foundations like cloud agnostic platform, microservice chassis and readiness for the new capabilities. The presentation will include application of their systemic approach in practice with a couple of real world examples.

How does one choose to architect a system that has a Microservice / REST API endpoints? There are many solutions out there. Some are better than others. Should state be held in a server side component, or externally? Generally we are told this is not a good practice for a Cloud Native system, when the 12-factor guidelines seem to be all about stateless containers, but is it? It’s unclear and this confusion may lead to poor technology stack choices that are impossible or extremely hard to change later on as your system evolves in terms of demand and performance. While stateless systems are easier to work with, the reality is that we live in a stateful world, so we have to handle the state of data accordingly to ensure data integrity beyond securing it. We will examine and demonstrate the fundamentals of a Cloud Native system with Stateful Microservices that’s built with Open Liberty in Kubernetes: •Microservices/REST API – Options to use when running your apps in the JVM. Use of the Saga Programming Pattern, and the Long-Running Action feature of MicroProfile •Concurrency – how to take advantage of multi-core CPUs and clustered distributed systems •Stateful vs Stateless – while stateless apps are easier to implement, the bulk of the apps in production are stateful which involve a higher level of complexity and risk, especially when data would need to travel across multiple machines and network boundaries •Deployment – how about containerization and orchestration using Kubernetes?