In this day-long work workshop, we will walk through a catalog of all the common architectural design patterns. For each design pattern, we will run docker-compose files that demonstrate the strengths and weaknesses of those design patterns. So you have a first-hand, full-on, and highly engaged full-day workshop to give you the knowledge you need to make critical architectural choices.
We will cover:
A GitHub Account
“Humans became behaviourally modern the moment they committed to storing abstract information outside their brains.” —Lyn Wadley
As architects, we often bridge the gaps that exist between all of the teams and stakeholders involved in the success or failure of a system. Because of this, information is hitting us from every direction. How we capture, organize, distill, and express this information is critical to our own success or failure.
Unfortunately, while excellent at abstract thinking, our brains are equally terrible at random recall. What we need is a second brain that excels at providing us with the right information at the right time. In this session, we're going to learn Digital Knowledge Management workflows and tools that will help us build and use that second brain.
By now your organization has planted a flag in “the Cloud” and it up to you to figure out just what that means to your application portfolio. Should everything be a microservice? Wait, what is a microservices anyway? How do you deal with massively distributed applications? How can event storming fix the gap between your business problems and domain model?
In this workshop, you will take a kata from event storming through to an initial design stopping along the way to discuss:
Machine Learning is clearly here to stay. While it is a far cry from actual Artificial Intelligence, it provides many invaluable and remarkable ways to learn from the data we are collecting about our customers, products and daily activities. The past afforded us machine learning libraries which became machine learning frameworks. Now, we are designing and building machine learning platforms that facilitate entire initiatives in reusable and extensible ways.
We will discuss many of the drivers of modern machine learning systems and the architectures that we are seeing emerge as well as the security implications of protecting them.
Architecture is not a static representation of a system. There are several complexities and risks involved in creating them. One way to mitigate the risk is to evolve the architecture. But, there are risks of evolving as much as there are the risks of not evolving. In this interactive workshop we will explore a set of practices that we can use to mitigate the risks. Then we will dive into discussing some common and popular architectural patterns.
Finally, we will take some example applications and discuss how to evolve architecture to meet the needs of those applications.
Computer with git client installed to access the version control system which will have lab related material.
Architecture is not a static representation of a system. There are several complexities and risks involved in creating them. One way to mitigate the risk is to evolve the architecture. But, there are risks of evolving as much as there are the risks of not evolving. In this interactive workshop we will explore a set of practices that we can use to mitigate the risks. Then we will dive into discussing some common and popular architectural patterns.
Finally, we will take some example applications and discuss how to evolve architecture to meet the needs of those applications.
Computer with git client installed to access the version control system which will have lab related material.
Many developers around the world have jumped on the Microservices bandwagon. Several organizations, in the past and also in the present, have built around monolithic and also service oriented architectures. What separate, however, Microservices from those efforts at large? How does a Microservices based architecture influence the design of the software applications, what are the key design principles we should keep in mind, and how to leverage design goals like reuse and extensibility?
In this presentation we will revisit the design goals we often focus on in software development and how those evolve in the context of Microservices.
The vast majority of developers have experience creating monoliths. Whereas that experience is really good to have from the point of view of building monoliths, they may become a hindrance when creating microservices. There are a few things we have to do differently, we have to unlearn a few design principles, we have to adhere to a few different architectural goals, and yet carry forward some of the techniques that have worked well before.
In this presentation, we will focus on how to transition from building monoliths to creating microservices.
Design patterns are commonplace in OO programming. With the introduction of lambda expressions in languages like Java, one has to wonder about their influence on design patterns.
In this presentation, we will take up some of the common design patterns and rework them using lambda expressions. We will also explore some other patterns that are not so common but are quite useful ways to apply lambdas.
git client
Java 8 or newer
Your favorite IDE, IntelliJ IDEA community edition recommended
Design patterns are commonplace in OO programming. With the introduction of lambda expressions in languages like Java, one has to wonder about their influence on design patterns.
In this presentation, we will take up some of the common design patterns and rework them using lambda expressions. We will also explore some other patterns that are not so common but are quite useful ways to apply lambdas.
git client
Java 8 or newer
Your favorite IDE, IntelliJ IDEA community edition recommended
Awareness is the knowledge or perception of a situation or fact, which based on myriad of factors is an elusive attribute. Likely the most significant unasked for skill… perhaps because it's challenging to “measure” or verify. It is challenging to be aware of aware, or is evidence of it's adherence. This session will cover different levels of architectural awareness. How to surface awareness and how you might respond to different technical situations once you are aware.
Within this session we look holistically an engineering, architecture and the software development process. Discussing:
* Awareness of when process needs to change (original purpose of Agile)
* Awareness of architectural complexity
* Awareness of a shift in architectural needs
* Awareness of application portfolio and application categorization
* Awareness of metrics surfacing system challenges
* Awareness of system scale (and what scale means for your application)
* Awareness when architectural rules are changing
* Awareness of motivation for feature requests
* Awareness of solving the right problem
The focus of the session will be mindful (defined as focusing on one's awareness), commentating in sharing strategies for heightening awareness as an architect and engineer.
The organization has grown and one line of business has become 2 and then 10. Each line of business is driving technology choices based on their own needs. Who and how do you manage alignment of technology across the entire Enterprise… Enter Enterprise Architecture! We need to stand up a new part of the organization.
This session will define the role of architects and architectures. We will walk through a framework of starting an Enterprise Architecture practice. Discussions will include:
When architecting a critical system the Availability of CAP theorem becomes the most important element. Architecture measures availability in 9s with 99.99% equating less than 1 hour of unplanned downtime. This session will focus on what it takes to get there.
After establishing high availability expectations and measurements, this session will dive into what it takes to establish the highest scale possible. It includes a look at infrastructure needs with a separation between capacity and scale. A look a service discovery with pro and cons of service to service dependencies. We look at infrastructure necessary such as health checks and monitoring. The session will include a look at different layers of fault domains including cross region.
How does designing Microservices differ from designing more traditional applications?
What is a better way to learn than to take a problem, analyze the requirements, explore the design options, apply the concepts of bounded context, and arrive at the architecture and design of Microservices to realize the requirements?
Come to this workshop to get a practical, hands-on practice to navigate from requirements all the way to a workable solution and along the way learn about different architectural goals and approaches that can help with the design.
git client to fetch the examples and labs from a git repository.
We all are familiar with SOLID and other software design principles and have explored many design patterns. There is no better way to get a deeper understanding than to practice the concepts. Furthermore, some of the principles and patterns manifest themselves in what appear to be rather unconventional ways when applied under a set of constraints and requirements.
In this hands-on intensive workshop, we will take some problems and device elegant lightweight design, in code, and discuss the tradeoffs. Come experience the evolution of ideas into code and take shape by way of incremental development.
Computer with git client to access git repository.
Java 8 or newer
Your favorite IDE
We all are familiar with SOLID and other software design principles and have explored many design patterns. There is no better way to get a deeper understanding than to practice the concepts. Furthermore, some of the principles and patterns manifest themselves in what appear to be rather unconventional ways when applied under a set of constraints and requirements.
In this hands-on intensive workshop, we will take some problems and device elegant lightweight design, in code, and discuss the tradeoffs. Come experience the evolution of ideas into code and take shape by way of incremental development.
Computer with git client to access git repository.
Java 8 or newer
Your favorite IDE
There are some amazing features that are being introduced in Java in the coming years. Some of these features are just around the corner. However, these features, in various forms, have been in other languages for a while.
In this presentation we will take a look at some features in Kotlin, Scala, and JavaScript that are soon to be features of Java, understand their power and benefits and how we can make use of them. We will relate these features to how they are manifesting in Java.
Mixins and traits are intriguing concepts in computer science and in object modeling.
In this presentation, we will first take a problem and discuss why rudimentary facilities in languages are not sufficient nor elegant to solve the problem. Then we will discuss, with a live example, how mixins and traits tactfully tackle the requirements.
As we migrate towards distributed applications, it is more than just our architectures that are changing, so too are the structures of our teams. The Inverse Conway Maneuver tells us small, autonomous teams are needed to produce small, autonomous services. Architects are spread thin and can’t be involved with every decision. Today, we must empower our teams but we need to ensure our teams are making good choices. How do we do that? How do you put together a cohesive architecture around distributed teams?
This talk will discuss creating “paved roads”, well worn paths that we know works and we can support. We will also explore the importance of fitness functions to help our teams adopt appropriate designs.
With globally distributed applications (and teams!) the job of software architect isn’t getting any easier; applications are growing increasingly complex and architects are spread thin. You can’t be involved with every decision, you must empower your teams while ensuring they are making good choices. How do you do that? How can frameworks like Spring not only make your life easier but help your teams deliver robust applications to production? Spring Cloud has a veritable plethora of sub projects from circuit breakers to functions simplifying the task of building cloud native applications while making it easy for developers to adhere to best practices. At the same time it can be overwhelming to get your head wrapped around all the features Spring offers. This talk will show how Spring allows architects to focus on the critical design decisions they need to make while ensuring developers are empowered to implement critical business use cases. Today’s cloud native applications have similar pitfalls, luckily Spring is here to help you resolve them!
This talk will show how Spring allows architects to focus on the critical design decisions they need to make while ensuring developers are empowered to implement critical business use cases. Today’s cloud native applications have similar pitfalls, luckily Spring is here to help you resolve them!
Becoming a software architect is a longed-for career upgrade for many software developers. While the job title suggests a work day focused on technical decision-making, the reality is quite different. In this workshop, software architect Nathaniel Schutta constructs a real world job description in which communication trumps coding.
Discover the skill sets needed to juggle multiple priorities, meetings, and time demandsLearn why your best team leadership tool is not a hammer, but a shared cup of coffeeHear the best ways to give and take criticismUnderstand the necessity of writing effective email and formal architecture documentsGet tips for delivering confident career-building presentations to any audienceReview essential techniques for stakeholder management and relationship buildingExplore the critical needs for architecture reviews and an effective process for conducting themThrough lecture and small group exercises, Nathaniel will help you understand what it means to be a successful architect. Working through various problems, attendees will have opportunities to think through architectural decisions and patterns, discuss the importance of non functional requirements and why architects cannot afford to practice resume driven design.
Becoming a software architect is a longed-for career upgrade for many software developers. While the job title suggests a work day focused on technical decision-making, the reality is quite different. In this workshop, software architect Nathaniel Schutta constructs a real world job description in which communication trumps coding.
Discover the skill sets needed to juggle multiple priorities, meetings, and time demandsLearn why your best team leadership tool is not a hammer, but a shared cup of coffeeHear the best ways to give and take criticismUnderstand the necessity of writing effective email and formal architecture documentsGet tips for delivering confident career-building presentations to any audienceReview essential techniques for stakeholder management and relationship buildingExplore the critical needs for architecture reviews and an effective process for conducting themThrough lecture and small group exercises, Nathaniel will help you understand what it means to be a successful architect. Working through various problems, attendees will have opportunities to think through architectural decisions and patterns, discuss the importance of non functional requirements and why architects cannot afford to practice resume driven design.
Rich Hickey once said programmers know the benefits of everything and the trade offs of nothing…an approach that can lead a project down a path of frustrated developers and unhappy customers. As architects though, we must consider the trade offs of every new library, language, pattern or approach and quickly make decisions often with incomplete information. How should we think about the inevitable technology choices we have to make on a project? How do we balance competing agendas? How do we keep our team happy and excited without chasing every new thing that someone finds on the inner webs?
As architects it is our responsibility to effectively guide our teams on the technology journey. In this talk I will outline the importance of trade offs, how we can analyze new technologies and how we can effectively capture the inevitable architectural decisions we will make. I will also explore the value of fitness functions as a way of ensuring the decisions we make are actually reflected in the code base.
Although the Resource-Oriented Architecture is one of the oldest and most successful distributed architectures, it remains poorly understood and often completely overlooked today.
Much of the microservices architecture pattern is focused on taking applications apart although seemingly everyone has different ideas on how to put things back together again.
In this session, we will start with a summary of the resource-oriented architecture along with it's strengths and weaknesses. Michael will share hard-earned, real-world experience applying ROA concepts to complex microservice environments to successfully build an infinitely scalable, extensible, and understandable system.
Mob Programming is a style of programming in which the entire team sits together and
works on a single task at a time. Teams that have worked this way have found that
many of the problems that plague normal development just melted away, possibly because communication and learning increases. Teams also find that the quality of their code increases. They find their capacity to create increases. However, the best part of all this is that teams end up being happier and more cohesive.
In this session we introduce the core concepts of mob programming and then get handson mobbing on a coding kata.
Integration, once a luxury, is now a necessity. Doing this well, however, continues to be elusive. Early attempts to build better distributed systems such as DCOM, CORBA, and SOAP were widely regarded as failures. Today the focus is on REST, RPC, and graphql style APIs.
Which is best? The goto answer for architects is, of course, “it depends.”
In this session, we look at the various API approaches, how they attempt to deal with the challenge of decoupling client from server, evolvability, extensibility, adaptability, composability.
The biggest challenge is that needs change over time, and APIs must necessarily evolve. Versioning is challenging, and breaking changes are inevitable. You'll leave this session with a highlevel understanding of these approach, their respective tradeoffs and ultimately how to align your API approach with your architectural and organizational goals.
Since 1994, the original Gang of Four Design Patterns book, “Design Patterns: Elements of Reusable Object-Oriented Software” has helped developers recognize common patterns in development. The book was originally written in C++, but there have been books that translate the original design patterns into their preferred language. One feature of “The Gang of Four Design Patterns” that has particularly stuck with me has been testability for the most part. With the exception of singleton, all patterns are unit testable. Design Patterns are also our common developer language. When a developer says “Let's use the Decorator Pattern” we know what is meant.
What's new though is functional programming, so we will also discuss how these patterns change in our new modern functional programming world. For example, functional currying in place of the builder pattern, using an enum for a singleton and reconstructing the state pattern using sealed interfaces. We will cover so much more, and I think you will be really excited about this topic and putting it into practice on your own codebase.
We will be using a cloud environment, so you can relax
But if you want to, you don't have to, but if you want to run locally, you should have JDK 19
Since 1994, the original Gang of Four Design Patterns book, “Design Patterns: Elements of Reusable Object-Oriented Software” has helped developers recognize common patterns in development. The book was originally written in C++, but there have been books that translate the original design patterns into their preferred language. One feature of “The Gang of Four Design Patterns” that has particularly stuck with me has been testability for the most part. With the exception of singleton, all patterns are unit testable. Design Patterns are also our common developer language. When a developer says “Let's use the Decorator Pattern” we know what is meant.
What's new though is functional programming, so we will also discuss how these patterns change in our new modern functional programming world. For example, functional currying in place of the builder pattern, using an enum for a singleton and reconstructing the state pattern using sealed interfaces. We will cover so much more, and I think you will be really excited about this topic and putting it into practice on your own codebase.
We will be using a cloud environment, so you can relax
But if you want to, you don't have to, but if you want to run locally, you should have JDK 19
Cloud native applications are distributed to reap the benefits of resource scaling. Distributed computing is powerful but it also makes you think differently in designing applications. Atomic, modular, highly cohesive, and low coupled applications play nicely on these distributed systems. But it comes with costs.
We’ll look at architecture styles that adapt well to running in containers and on Kubernetes. Along the way, we’ll note the extra things your application should do to play nicely with distributed cloud native targets.
Don't fear entropy, embrace it.
When you move toward distributed computing the likelihood of failure proportionally increases. It's not your fault, it's simply physics. Once you start spreading your data and applications across more devices, then access to resources such as CPU, memory, and I/O have a higher rate of failure.
Embrace entropy with chaos experiments and increase your cloud native capability model. We’ll investigate some of the leading chaos frameworks for Kubernetes and dive into hands-on experiments targeted within blast radiuses.
Hopefully, your DevOps team is ensuring that your platform is healthy and its delivery system is frictionless with new updates continuously rolling out. How can you achieve an automated and reliable delivery pipeline? Fortunately, your pipelines can all be run on Kubernetes. One of the highest maturity model goals with pipelines is automated delivery models. Specifically Progressive Delivery.
We’ll look at delivery model techniques and how Kubernetes and meshes provide a framework to make deliveries successful.
Distributed computing has surprising challenges. When targeting applications for Kubernetes your capabilities should meet its demands. If you can raise your team’s understanding of the cloud native maturity model, then it will increase your success with Kubernetes solutions.
I get it, we don’t always follow the best techniques and your team does not do everything perfectly. However, it would be sad if you did not lay out some plans to eventually raise your capability goals. We’ll examine some worthwhile goals and applicable techniques.
Distributed computing is hard. A significant challenge is typically when you want to get something done you have to call another service. Understanding how services are discovered and connected is fundamental to understanding Kubernetes' strengths.
We’ll walk through some networking concepts and hands-on examples of various techniques to understand simple to sophisticated traffic control and routing. Ingress and Istio will be demystified.
Out of the box (remember when software used to come in a box), Kubernetes was never meant to be secure. There is configuration work that must be applied to lockdown and shore up its various attack vectors. You can put up all the perimeters, regions, and safety zones you want but these do not ensure ZT security.
Implementation of Zero Trust (ZT) and Zero Trust Architecture (ZTA) is not a nice to have or something that should be addressed eventually. The January 2022 White House Memo M-22-09 requests that:
> This memorandum sets forth a Federal zero trust architecture (ZTA) strategy, requiring agencies to meet specific cybersecurity standards and objectives by the end of Fiscal Year (FY) 2024 in order to reinforce the Government’s defenses against increasingly sophisticated and persistent threat campaigns. Those campaigns target Federal technology infrastructure, threatening public safety and privacy, damaging the American economy, and weakening trust in Government.
Zero Trust is a necessity, not just from a government edict, but also from an imperative need for cloud computing security.
This session is for developers that would like to understand the tools and techniques that can be applied to help their teams prepare for ZT Kubernetes clusters.
There are multiple elements to Kubernetes where each component seems like a character in a book, pods, services, deployments, secrets, jobs, config maps, and more. In this presentation, we just focus on the security aspect of Kubernetes and the components involved. Particularly centered around RBAC and ServiceAccounts. What they are, what they do. We discuss etcd and secrets. We will also discuss other options for security in Kubernetes.
There are multiple elements to Kubernetes where each component seems like a character in a book, pods, services, deployments, secrets, jobs, config maps, and more. In this presentation, we just focus on the security aspect of Kubernetes and the components involved. Particularly centered around RBAC and ServiceAccounts. What they are, what they do. We discuss etcd and secrets. We will also discuss other options for security in Kubernetes.
Service Accounts
Secrets
Kubernetes API
Authentication
Authorization
RBAC
Roles and Cluster Roles
Hashicorp Vault stores encrypted secrets securely. You can store anything that you want into Vault including API keys, passwords, and certificates. Vault can also store dynamic secrets where it can negotiate with a cloud service on your behalf without direct interaction with your API keys. Hashicorp Vault is well thought out “bank” of information that handles storage, encryption, leasing, sealing.
In this presentation, we will discuss setup, securing content, creating automatic secrets for AWS, sealing, how to deploy into Kubernetes, and how to integrate with code.
This workshop builds an entire event driven data pipeline with Machine Learning and Kafka. From Kafka where we use producers or Kafka Connect to generate information, we then will Kafka Streams to apply a machine learning model to make business decisions.
This intensive lab will start by integrating sources into our backplane, then train our models, and operationalize our model using Kafka Streams. We will then create result topics when we can read in as a report and display visualizations of our data. The result will also be scalable and fault tolerant.
*Github Account
This workshop builds an entire event driven data pipeline with Machine Learning and Kafka. From Kafka where we use producers or Kafka Connect to generate information, we then will Kafka Streams to apply a machine learning model to make business decisions.
This intensive lab will start by integrating sources into our backplane, then train our models, and operationalize our model using Kafka Streams. We will then create result topics when we can read in as a report and display visualizations of our data. The result will also be scalable and fault tolerant.
*Github Account
The difference between a junior and a senior dev isn't coding skills. A developer's coding skills are just their ante; necessary to get into the game but, like an ante, they only get you into the game.
Everything that happens from that point on depends on what else you bring to the table.
In this session, we explore the key skills necessary to make an impact, be effective, and will ultimately pave the way to grow into senior/principal level developers and architects.
This session will be a deep dive into the machine learning & artificial intelligence services and associated MLOPS within AWS. This will include updates to existing services, Amazon Data Wrangler, Sagemaker Studio, Sagemaker Pipelines, Sagemaker Endpoints, and any new services added (Amazon is constantly evolving in this space). We will cover key concepts of each of the services, common use cases, and design patterns.
Come to this session if you want to get up to speed on the ML/AI services in AWS.
This session will be a deep dive into the machine learning & artificial intelligence services and associated MLOPS within AWS. This will include updates to existing services, Amazon Data Wrangler, Sagemaker Studio, Sagemaker Pipelines, Sagemaker Endpoints, and any new services added (Amazon is constantly evolving in this space). We will cover key concepts of each of the services, common use cases, and design patterns.
Come to this session if you want to get up to speed on the ML/AI services in AWS.
This session will take a look at how the pandemic has impacted the skills needed by software architects from ideation to product delivery. For many architects, it’s not the technology-related areas that give you problems, but people-related areas (some things never change). We will dive into both areas.
Come to this session if you want to learn some tricks and tips for how to raise your game as an architect.
This session will be a deep dive into the software architecture and ecosystem surrounding cryptocurrencies. This will include mining, staking, hardware and software wallets, ledgers, and exchanges. We will also take a look at several of the latest design patterns, features, and trends in this marketplace.
Come to this session if you want to get up to speed on cryptocurrencies, the underlying software architecture, and the surrounding ecosystem.
In some organizations, architects are dismissed as people that draw box and arrow diagrams - the dreaded whiteboard architect. While we don't want to foster that stereotype, it is important for an architect to be able to construct basic architectural diagrams. An architect must also be able to separate the wheat from the chaff eliminating those models that don't help tell the story while fully leveraging those that do.
In this workshop, we'll discuss the various diagrams at our disposal. We'll walk through a case study and as we go, we'll construct a set of diagrams that will help us effectively communicate our design. We'll talk about stakeholders and who might benefit from each typ of diagram. Additionally we'll discuss how to constructively review an architectural model.
Neither a laptop nor special software is required for this workshop though your modeling tool of choice (Spark, Visio, OmniGraffle, etc.) is welcome for the exercises. Of course paper and pencil are very effective too and frankly recommended! Feel free to work in pairs or teams. That's it! Well, and a willingness to participate!
In some organizations, architects are dismissed as people that draw box and arrow diagrams - the dreaded whiteboard architect. While we don't want to foster that stereotype, it is important for an architect to be able to construct basic architectural diagrams. An architect must also be able to separate the wheat from the chaff eliminating those models that don't help tell the story while fully leveraging those that do.
In this workshop, we'll discuss the various diagrams at our disposal. We'll walk through a case study and as we go, we'll construct a set of diagrams that will help us effectively communicate our design. We'll talk about stakeholders and who might benefit from each typ of diagram. Additionally we'll discuss how to constructively review an architectural model.
Neither a laptop nor special software is required for this workshop though your modeling tool of choice (Spark, Visio, OmniGraffle, etc.) is welcome for the exercises. Of course paper and pencil are very effective too and frankly recommended! Feel free to work in pairs or teams. That's it! Well, and a willingness to participate!
Development teams often focus on getting code to production losing site of what comes after the design and build phase. But we must consider the full life cycle of our systems from inception to deployment through to sunset, a discipline many companies refer to as site reliability engineering.
While your organization may or may not have an SRE team, you have someone playing that role and we can all benefit from looking at the principles and practices that we can bring to bear on our projects. In this talk, I will introduce the concepts of SRE and how you can adopt these ideas on your applications.
Spring has always been defined by its lightweight core. While there has been an overwhelming explosion in the external projects and protocols it integrates seamlessly with, it has also evolved internally to meet the needs of modern development requirements.
One of the biggest changes in the last several years has been the emergence of Reactive Spring, an attempt to embrace the idea of Reactive Systems in the Spring ecosystem. This is a vision of responsive, resilient, elastic systems. Unfortunately, code alone cannot solve the problems so this is a case where software and architecture meet.
You will learn about:
- The Reactive System vision
- How Spring absorbed these ideas without complicating or
eliminating the more conventional styles
- How to build, test and consume Reactive Spring applications
- How to architect entire Reactive chains of interacting systems
Spring has always been defined by its lightweight core. While there has been an overwhelming explosion in the external projects and protocols it integrates seamlessly with, it has also evolved internally to meet the needs of modern development requirements.
One of the biggest changes in the last several years has been the emergence of Reactive Spring, an attempt to embrace the idea of Reactive Systems in the Spring ecosystem. This is a vision of responsive, resilient, elastic systems. Unfortunately, code alone cannot solve the problems so this is a case where software and architecture meet.
You will learn about:
- The Reactive System vision
- How Spring absorbed these ideas without complicating or
eliminating the more conventional styles
- How to build, test and consume Reactive Spring applications
- How to architect entire Reactive chains of interacting systems
Knowledge graphs are a rapidly emerging concept for machine-processable models of complex and dynamic domains. They represent the intersection of Web architecture and information. If your organization wants to resolve its most pernicious data integration problems or facilitate machine learning initiatives, knowledge graphs are likely to be part of your future.
We will discuss the emergence of Knowledge Graphs as an emerging solution to a missing capability in most organization's IT strategies. We will discuss how some of the biggest organizations in the world are heading in this direction, it's impact on API design and more. We will focus on specific tools, platforms and standards that are making Knowledge Graphs a crucial part of your overall solutions.
Event-driven architectures are not new, but they are newly ascendant. For the first time since the client-server revolution of 40 years ago, a new architectural paradigm is changing the way we build systems. Apache Kafka and microservices are at the center of this movement.
In this workshop, we’ll discuss the issues that arise turning a monolith into a set of reactive services, including issues like data contracts, integrating with the systems you can't change, handling request-response interfaces, and more. We'll also discuss common infrastructure choices like Apache Flink and Apache Pinot. Hands-on exercises will focus on understanding your organization's data and forming a plan to refactor that monolith that seems like it will never go away.
I'm looking forward to having you in the Event-Driven Architecture Workshop! To get the best use of our time together, the in-person exercises will focus on understanding the systems you're currently using at work and planning their refactoring to microservices. You should bring a laptop, a pen, and energy for the day!
When things get a little bit cheaper, we buy a little bit more of them. When things get cheaper by several orders of magnitude, you don't just see changes in the margins, but fundamental transformations in entire ecosystems. Apache Pinot is a driver of this kind of transformation in the world of real-time analytics.
Pinot is a real-time, distributed, user-facing analytics database. The rich set of indexing strategies makes it a perfect fit for running highly concurrent queries on multi-dimensional data, often with millisecond latency. It has out-of-the box integration with Apache Kafka, S3, Presto, HDFS, and more. And it's so much faster on typical analytics workloads that it is not just a marginally better data warehouse, but the cornerstone of the next revolution in analytics: systems that expose data not just to internal decision makers, but to customers using the system itself. Pinot helps expand the definition of a “decision-maker” not just down the org chart, but out of the organization to everyone who uses the system.
In this talk, you'll learn how Pinot is put together and why it performs the way it does. You'll leave knowing its architecture, how to query it, and why it's a critical infrastructure component in the modern data stack. This is a technology you're likely to need soon, so come to this talk for a jumpstart.
Have you ever stopped to think about how to build a database? The thing is, there isn't just one way, as we can see by the massive number of data infrastructure options we have to choose from. It's a nonstop series of tradeoffs, each motivated by the constraints the database wants to satisfy. An in-memory transactional database would be one thing. A general-purpose, single-server relational database would be another. A low-latency, horizontally scalable analytics database would be…the journey we're going to take.
In this talk, we'll start by picking a data model, make decisions about serialization and storage, choose indexing strategies, pick a query language, and figure out how to scale, eventually ending up with something that looks remarkably like Apache Pinot, a real-time analytics database. Pinot was built on a journey like this, always optimized for ultra low-latency, user-facing analytics at scale. In the real world, Pinot is used by applications like LinkedIn and UberEats to expose the state of the system not just to internal decision-makers, but to the users of the system itself, including all of us people who consumers of analytical queries. By focusing on the internals of Pinot and the tradeoffs made along the way to build a database of its kind, we'll see how it enables a new class of applications that every user of a system into a decision maker.
Alistair Cockburn has described software development as a game in which we choose among three moves: invent, decide, and communicate. Most of our time at No Fluff is spent learning how to be better at inventing. Beyond that, we understand the importance of good communication, and take steps to improve in that capacity. Rarely, however, do we acknowledge the role of decision making in the life of software teams, what can cause it to go wrong, and how to improve it.
In this talk, we will explore decision making pathologies and their remedies in individual, team, and organizational dimensions. We'll consider how our own cognitive limitations can lead us to to make bad decisions as individuals, and what we might do to compensate for those personal weaknesses. We'll learn how a team can fall into decisionmaking dysfunction, and what techniques a leader might employ to healthy functioning to an afflicted group. We'll also look at how organizational structure and culture can discourage quality decision making, and what leaders to swim against the tide.
Software teams spend a great deal of time making decisions that place enormous amounts of capital on the line. Team members and leaders owe it to themselves to learn how to make them well.
The LLVM Project has been around for over a decade, but is increasingly important as a compiler infrastructure to get reuse and portability, shared optimizations and a faster time to market. It achieves this by having a pluggable, layered architecture compared to other compiler infrastructure. Many newer programming languages have chosen it as the basis of their toolchain including Swift, Julia, Rust and more.
In this talk, we will talk about the tools, components and layers of LLVM and how it is helping usher in new visions of portability and reuse.
According to a CareerBuilder study, only 40% of new tech leaders receive formal training when they become a boss for the first time. The rest are forced to get scrappy to quickly equip themselves with new skills, techniques, and mindsets to effectively transition into their new roles.
This workshop was designed to fill this gap; providing tactical techniques and resources for both new and seasoned technical leaders!
In this full day workshop, you will learn how successfully navigate the complexities of Engineering Management. Topics include:
Purposeful leadership, emotional intelligence, self awareness, time management, prioritizing the right things, social styles, giving feedback, career conversations, 1:1s, psychological safety, recruiting, interviewing, onboarding, measuring team metrics, motivation, engagement, team building, and building sustainable relationships.
Interactive group exercises will help you practice these new ideas and techniques in a safe and engaging environment.
You will leave with new perspectives on Engineering Management, as well as handouts and plenty of resources to grow and further develop skills in your daily work.
Please download (and print if possible) the handout before joining this workshop! (located with session slides).
Please download (and print if possible) the handout before joining this workshop! (located with session slides).
In this workshop, take a practical approach to creating fitness functions that assess the architectural soundness of your systems.
We will learn about different fitness functions that can help architects and their teams create and comply with the architectural expectations expressed by their architect in collaboration with the team. Then we’ll see how we can implement those constraints, as guardrails, using ArchUnit, and get a continuous feedback on the teams' efforts.
git client
Java 8 or newer
Your favorite IDE, IntelliJ IDEA community edition recommended.
In this workshop, take a practical approach to creating fitness functions that assess the architectural soundness of your systems.
We will learn about different fitness functions that can help architects and their teams create and comply with the architectural expectations expressed by their architect in collaboration with the team. Then we’ll see how we can implement those constraints, as guardrails, using ArchUnit, and get a continuous feedback on the teams' efforts.
git client
Java 8 or newer
Your favorite IDE, IntelliJ IDEA community edition recommended.
Sharing code and internal libraries across your distributed microservice ecosystem feels like a recipe for disaster! After all, you have always been told and likely witnessed how this type of coupling can add a lot of friction to a world that is built for high velocity. But I'm also willing to bet you have experienced the opposite side effects of dealing with dozens of services that have had the same chunks of code copied and pasted over and over again, and now you need to make a standardized, simple header change to all services across your platform; talk about tedious, frictional, errorprone work that you probably will not do! Using a variety of codesharing processes and techniques like inner sourcing, module design, automated updates, and service templates, reusing code in your organization can be built as an asset rather than a liability.
In this talk, we will explore the architectural myth in microservices that you should NEVER share any code and explore the dos and don'ts of the types of reuse that you want to achieve through appropriate coupling. We will examine effective reuse patterns, including what a Service Template architecture looks like, while also spending time on the lifecycle of shared code and practically rolling it out to your services. We will finish it off with some considerations and struggles you are likely to run into introducing code reuse patterns into the enterprise.
Modern HTTP APIs power today’s connected world, acting as the core interface not only for developers, but also for the ever-growing ecosystem of machines, services, and now AI agents. As every organization is increasingly expected to produce and consume APIs at scale, the ability to design, build, deploy, and operate consistent, high-quality APIs has become a key competitive differentiator. With AI accelerating the need for composable, well-structured, and discoverable interfaces, API maturity is no longer optional—it’s essential. However, building and scaling effective API Design First practices across an enterprise is still fraught with manual processes, inconsistent standards, and slow governance models. To succeed, organizations must reimagine API Governance as a strategic enabler—one that prioritizes collaboration, stewardship, and automation.
In this session, we’ll explore the core stages of the API design lifecycle and share how to implement practical, modern governance models that increase productivity without sacrificing control. Drawing on real-world examples from SPS Commerce, as well as off-the-shelf tooling and custom solutions, we’ll show how to align your teams, accelerate delivery, and produce APIs that are robust, reusable, and ready for both human and AI consumers.
The architecture paradigms we’re using are changing. The platforms we deploy our software to are changing. We are confronted with several new architecture paradigms to choose from, such as microservices and miniservices. Should we automatically discard some of the proven architectures we’ve used in the past, including more traditional web services? Likewise, new platforms, such as cloud, complicate the decision. Yet, at the heart of this transformation is modularity. From monoliths to microservices and everything in between, modularity is the foundation.
In this session, we’ll explore how modularity is impacting the platforms we are leveraging and the architecture paradigms we’ll use and offer a clear roadmap with proven guidance on navigating the architecture decisions we must make.
In today’s volatile technology and business climate, big architecture up front is not sustainable. Attempts to define the architectural vision for a system early in the development lifecycle does not work. To accept change, teams are moving to agile methods, but agile methods provide little architectural guidance. In this session, we provide practical guidance for software architecture on agile projects.
We will explore several principles that help us create more flexible and adaptable software systems.We’ll expose the true essence of what’s meant when we say “architectural agility.” And we’ll explore the real goal of software architecture and how we can accommodate architectural change to help increase architectural agility.
Software development is an amazing profession, requiring the delicate combination of analytical and creative skills. Understanding architectural patterns, agile best practices, and exploring the depths of platforms, tool, and languages requires deep analytical skills. Yet crafting a system also requires vision and understanding when to deviate from traditional best practices.
In this session, we will explore lessons learned over many years of building large software systems. We will challenge traditional assumptions and explore new ways of thinking.
A barrage of software philosophies have hit the industry over the last few years, all claiming to reduce friction in digital transformation. But what does that mean organizationally and where does open source play into all of this?
We'll talk about the roots of DevOps in the Theory of Constraints, how 12-Factor principles can guide your microservice and cloud migration refactor efforts, and how building an optimal strategy for the use of open source within your organization can tie all of these concepts together.
A lot of development teams have built out fully automated CI/CD pipelines to deliver code to production fast! Then you quickly discover that the new bottleneck in delivering features is their existence in longlived feature branches and no true CI is actually happening. This problem compounds as you start spinning up microservices and building features across your multirepo architecture and coordinating some ultrafancy release schedule so it all deploys together. Feature flags provide you the mechanism to reclaim control of the release of your features and get back to shortlived branches with true CI. However, what you're not told about feature flags in those simple “if/else” getting started demos is that there is an upfront cost to your development time, additional complexities, and some pitfalls to be careful of as you begin expanding feature flag usage to the organization. If you know how to navigate these complexities you will start to unleash true velocity across your teams.
In this talk, we'll get started with some of the feature flagging basics before quickly moving into some practical feature flagging examples that demonstrate its usage beyond the basic scenarios as we talk about UI, API, operations, migrations, and experimentation. We will explore some of the hard questions around “architecting feature flags” for your organization.
If there is one thing guaranteed to be part of the micro-services story, networking and service stand out. Network management in a highly orchestrated world of networks, subnets and overlays increases the challenge. Add the topic of security and traffic management and the picture can be overwhelming.
This session will cover solutions to day 2 operations of networking a micro-service based cluster leveraging Istio, Jaeger and Kiali. Demonstrations of specific solutions and on the fly network management will part of the presentation covering the following:
Our software engineering teams are facing new challenges every day that come with the rapidly changing industry and recent events.
People don't seem to be motivated by the same things that they previously found compelling. Organizations are giving up glamorous office spaces and pivoting to remote teams. These changes require us to quickly pivot as leaders to learn new skills, frameworks, and techniques to continue supporting our teams while maintaining our own sanity.
In this workshop, you will learn and practice key skills to help your team propel through today's modern challenges and setbacks. The topics will be relevant to all Software Engineering leaders who wish to find ways to motivate and inspire their teams - regardless of their organization's existing circumstances.
Specific topics will include:
Activities will require a handout - please download (and print if preferred) the course handout located in the Slides folder.
Our software engineering teams are facing new challenges every day that come with the rapidly changing industry and recent events.
People don't seem to be motivated by the same things that they previously found compelling. Organizations are giving up glamorous office spaces and pivoting to remote teams. These changes require us to quickly pivot as leaders to learn new skills, frameworks, and techniques to continue supporting our teams while maintaining our own sanity.
In this workshop, you will learn and practice key skills to help your team propel through today's modern challenges and setbacks. The topics will be relevant to all Software Engineering leaders who wish to find ways to motivate and inspire their teams - regardless of their organization's existing circumstances.
Specific topics will include:
Activities will require a handout - please download (and print if preferred) the course handout located in the Slides folder.
While still new to most people, WebAssembly provides a formidable vision of safe, fast, portable code. Through clever choices and well-considered design, the basic vision allows us to target browsers as a platform using a variety of languages other than (but compatible with) Javascript. This technology coupled with advancements in the Web platform are setting up the future of Web-delivered applications to look more like (and likely to replace) desktop applications.
The more interesting possibilities, however, will be realized when WebAssembly escapes the browser and ushers in a whole new era of ubiquitous, secure computing. We will discuss the various container environments and how they will solve some of the more persistent issues with more conventional software development technologies. Given the heterogeneity of modern architectures, you need a strategy for code use, reuse and positioning to best meet your customer’s needs.
While still new to most people, WebAssembly provides a formidable vision of safe, fast, portable code. Through clever choices and well-considered design, the basic vision allows us to target browsers as a platform using a variety of languages other than (but compatible with) Javascript. This technology coupled with advancements in the Web platform are setting up the future of Web-delivered applications to look more like (and likely to replace) desktop applications.
The more interesting possibilities, however, will be realized when WebAssembly escapes the browser and ushers in a whole new era of ubiquitous, secure computing. We will discuss the various container environments and how they will solve some of the more persistent issues with more conventional software development technologies. Given the heterogeneity of modern architectures, you need a strategy for code use, reuse and positioning to best meet your customer’s needs.
What if we could achieve completely ‘contactless’ software security scanning? As the lines between physical and digital security become blurrier and blurrier, software quality standards and testing methodologies must continue to keep pace. Software fuzzing has long been a trusted method for finding vulnerabilities that are difficult to discover using traditional methods.
The application of AI and ML to this field has already begun to bear very promising results. By leveraging deep learning techniques to improve our input corpus and better understand our program's states, we can shine areas on the code logic that would be hidden by approaches like vulnerability scanning and static code analysis, and even traditional software fuzzing.
These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.
Microservices demand more than just a new architecture, they require a cultural shift. In this workshop, we'll cover:
These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.
Microservices demand more than just a new architecture, they require a cultural shift. In this workshop, we'll cover:
In the last 30 years, our industry has been upended by advancements that unlock previously unimaginable capabilities. It still seems like there is far too much failure and not enough success in IT systems though. To be successful in the 21st Century, you will need to understand where we are and where we are going. It is a complex amalgamation of developments in hardware, computer languages, architectures and how we manage information. Very few people understand all of the pieces and how they connect.
In this talk we will cover how technology changes are enabling longer term capture of business value, modernization of legacy systems, resilience in the face of increased mobile user bases, IT sovereignty and distributed, layered, heterogeneous architectures.
By now I bet your company has hundreds, maybe thousands of services, heck you might even consider some of them micro is stature! And while many organizations have plowed headlong down this particular architectural path, your spidey sense might be tingling…how do we keep this ecosystem healthy?
In this talk, I will go beyond the buzzwords into the nitty gritty of actually succeeding with a service based architecture. We will cover the principles and practices that will make sure your systems are stable and resilient while allowing you to get a decent night's sleep!
We build development teams based on individual ability to write code but development of a software project of any significance is beyond a single persons effort with a very particular set of skills. It requires a team of members with a number array of skills. It requires social skills. It requires tools and alignment. It requires shared contextual models.
This session will distill a couple decades of software consulting lessons learn in software engineering along with Ugandan fun to uncover the true way to developing more with less.
Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one?
Come to this presentation to learn about things that can make that journey to be a successful architect a pleasant one.
Over the last decade, DevOps has emerged as an influential business philosophy and practice, helping businesses drive high quality software to market faster. DevOps focuses on the elimination of bottlenecks that occur when development and operational resources are too divorced from one another. But what about friction in the development and test process? What about the delayed feedback cycles that come from slow builds and test flakiness? How can we reduce friction in areas that are outside of the focus of DevOps? The presentation will include examples of DPE practices in action from Java projects using the Maven or Gradle build tool.
Attendees will walk away from this presentation with a better understanding of:
Please follow the workshop requirements here:
https://nfjs.nyc3.cdn.digitaloceanspaces.com/static/pdf/DPE_Workshop_Prerequisites.pdf