Tired of trying to manage and maintain servers? Never have a large enough operations team? Don’t have a budget for running lots of server? Don’t want to pay for servers siting idle? Afraid you might become so popular that you won’t be able to scale fast enough? Don’t worry, it is possible to alleviate these issues by moving to a serverless architecture that utilizes microservices hosted in the cloud. This type of architecture can support all different types of clients including web, mobile and IoT.
During this hands-on workshop, you will build a serverless application utilizing AWS services such as Lambda, API Gateway, S3 and a datastore.
During this session you will build a simple web application utilizing AWS services and Angular.
As a software architect, confronting the cloud can feel quite daunting. We are confronted with an onslaught of public cloud providers; which one should we choose? Are we ready for public cloud? Or do we need to focus on private cloud? And what does that even mean? Or are we looking for a hybrid solution? And these questions are only the beginning. Soon we’ll be looking at IaaS vs. PaaS. Containers vs. Unikernels. Servers vs. Serverless! Is there any way to make sense of all of the choices and cut through all of the hype?
Fortunately there is a way forward. There are clear architectural concepts and patterns that we can use as guideposts on our journey to the cloud. In this full-day workshop, we’ll gain an understanding of the unique characteristics of cloud infrastructure and how we can design and develop application architectures that fully exploit those unique characteristics. These “cloud native” architectures compose simple patterns with predictable performance, scaling, security and failure characteristics to create solutions to complex problems that can be quickly, flexibly, and continuously evolved to take advantage of new information. In many ways these architectures have more in common with organic systems than anything we’ve previously called software.
These characteristics of cloud native architectures allow us to practice an extreme flavor of continuous delivery that allows us to survive a new marketplace where speed is our primary competitive advantage and access to consumer services must be ubiquitous.
The newly trained cloud architect will leave this workshop equipped with an understanding of:
You’ll also leave with a rich catalog of cloud native architecture patterns that you should be able to apply regardless of your choice of cloud provider or technology stack. We'll enhance our understanding of these topics by alternating between a traditional lecture setting and breaking up into groups to do kata exercises.
Machine Learning is all the rage, but many developers have no idea what it is, what they can expect from it or how to start to get into this huge and rapidly-changing field. The ideas draw from the fields of Artificial Intelligence, Numerical Analysis, Statistics and more. These days, you'll generally have to be a CUDA-wielding Python developer to boot. This workshop will gently introduce you to the ideas and tools, show you several working examples and help you build a plan to for diving deeper into this exciting new field.
We will cover:
Please install Anaconda for Python 3 before the workshop if possible. https://www.anaconda.com/download
Microservices is one of the latest software architecture styles that promises to deliver benefits such as ease of testing, fast and easy deployments, fine-grained scalability, architectural modularity, and high overall agility. Unfortunately, coupled with these benefits comes a lot of complexity. This product-agnostic architecture class provides you with a full understanding of the Microservices architecture style and what hybrids and alternatives exist, which will help guide you in making the right architecture and design decisions for your organization. In this workshop I will start by discussing the core concepts of the Microservices architecture style, the primary benefits and drawbacks of Microservices, how Microservices differs from SOA, and also how to create hybrid architectures. Taking a deeper dive, I will then talk about the hard stuff in microservices, including how to identify services, various service template design strategies, event-driven services, service communication patterns, and distributed transactions. Finally, I'll talk about the hardest part of microservices, which is how to distribute your monolithic data.
“Emerge your architecture” goes the agile mantra. That’s great. Developers get empowered and fluffy papers make room for real code structure. But, how do you ensure the cohesiveness of the result?
In this talk, we expose how architecture is an emergent property, how it is a commons, and we introduce an approach for how it can be steered.
Testing, pair programming and code reviewing are the proposed means to approach this problem. However, testing is only concerned with the functional side of a system, and thus, it is not able to capture structural contracts. Pair programming and reviewing work well in the small, but they do not scale when you need to handle the millions of details entailed in modern systems.
Another way of approaching the structure of the system is through standard checkers, such as FindBugs or Checkstyle. These are fine tools, but when they are left to only check standard idioms, the specifics of your architecture remain unverified.
The architecture of the system is important and it deserves special attention because it is too easy for it to go wrong in the long run, and it is too expensive when that happens. In this tutorial we detail a method of approaching this challenge by steering the architecture on a daily basis through:
One challenging aspect is that of constructing custom analysis tools during development. This process requires a new kind of infrastructure and associated skills that enable you to craft such checkers fast and cheaply. However, this is a technical detail. The critical benefit comes from making architectural decisions explicit, and from the daily actions of cleaning the state of the system.
This talk is targeted to both engineers and managers. We cover the basics of the process, and we accompany the conceptual descriptions with real life examples.
This workshop highlights the ideas from the forthcoming Building Evolutionary Architectures, showing how to build architectures that evolve gracefully over time.
An evolutionary architecture supports incremental, guided change across multiple dimensions.
For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.
The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.
Outline:
No prerequisites or requirements–all exercises are done with paper, pen, and intellect.
Cloud continues to grow in importance in even the most conservative companies’ IT strategies. Because of this, even experienced software architects must confront a new world in which many of our normal architectural assumptions no longer hold. Before we create architectures that leverage cloud infrastructure, we need to rebuild our mental model of infrastructure around the appropriate concepts and principles. The purpose of this session is to do just that.
In this session we’ll:
The learner should leave this session prepared for deeper dives into cloud native architecture patterns and migration strategies.
NOTE: We'll cover roughly 50% of the material in Part 1.
Cloud continues to grow in importance in even the most conservative companies’ IT strategies. Because of this, even experienced software architects must confront a new world in which many of our normal architectural assumptions no longer hold. Before we create architectures that leverage cloud infrastructure, we need to rebuild our mental model of infrastructure around the appropriate concepts and principles. The purpose of this session is to do just that.
In this session we’ll:
The learner should leave this session prepared for deeper dives into cloud native architecture patterns and migration strategies.
NOTE: We'll cover roughly 50% of the material in Part 1. If you come to only Part 2, we'll be starting in the middle.
Now that we’ve been equipped with an understanding of how software architectures can exploit the unique aspects of cloud infrastructure environments, it’s time to construct a pattern catalog that can guide our decision making as we journey from concepts and principles to concrete implementations. The software industry has long been motivated by the promise of a “component marketplace” from which we can draw commodity components which can be composed via standardized mechanisms to create powerful systems. These systems are often compared to the myriad of possible creations that can be produced using Lego pieces. The power in the Lego “architecture” is found in the amazing diversity of individual pieces that are composed via a universal system of compatibility. Cloud native architectures approximate the same power via Lego-like patterns.
In this two-part series, we’ll divide the cloud native patterns into two categories:
In part one we’ll study “Brick Patterns” from the following categories:
The learner should leave this session prepared to design and implement cloud native “bricks” that can be composed via any “master builder” of cloud native solutions.
Now that we’ve been equipped with an understanding of how software architectures can exploit the unique aspects of cloud infrastructure environments, it’s time to construct a pattern catalog that can guide our decision making as we journey from concepts and principles to concrete implementations. The software industry has long been motivated by the promise of a “component marketplace” from which we can draw commodity components which can be composed via standardized mechanisms to create powerful systems. These systems are often compared to the myriad of possible creations that can be produced using Lego pieces. The power in the Lego “architecture” is found in the amazing diversity of individual pieces that are composed via a universal system of compatibility. Cloud native architectures approximate the same power via Lego-like patterns.
In this two-part series, we’ll divide the cloud native patterns into two categories:
In part one we’ll study “Mortar Patterns” from the following categories:
The learner should leave this session prepared to compose cloud native solutions from any available collection of cloud native “bricks.”
If you’ve been following along, you’ve realized by now that cloud native architectures are fundamentally different than most traditional architectures. Most of the cloud native architectures that we can see in the wild have been built by relatively young companies that began from a zero-legacy state. Architects in more mature organizations are faced with the daunting challenge of building modern systems that exploit the unique characteristics of cloud infrastructure while simultaneously attempting to migrate legacy systems into those same environments, all the while “keeping the lights on.”
Much of the last two years of my career have been spent helping Fortune 500 companies devise cloud native migration strategies, and I’ve built a increasingly large catalog of patterns that have proven useful across multiple systems and industry verticals. In this session we’ll dive into those patterns and more, including:
The learner should leave this session with a tool belt suitable for attacking an upcoming cloud native architecture migration effort.
In this presentation, we'll build, test, and deploy an image-processing pipeline using Amazon Web Services such as Lambda, API Gateway, Step Functions, DynamoDB, and Rekognition.
We'll take a look at some of the following topics:
The verdict is in: Cloud is NOT a fad. If you haven't already, as a software architect you will be called upon to evaluate various cloud services and determine their suitability for your company's use. In this session, we'll examine ten key criteria that you can use to evaluate any cloud service.
During our time together we'll examine the following criteria:
On the 2017 tour, I introduced the notion of “serverless” and Functions as a Service (FaaS) platforms. We understood the motivation for serverless computing, compared serverless to other cloud-native infrastructure approaches, navigated some architectural tradeoffs, and took a whirlwind tour of the Big 3 FaaS providers.
In this 2018 edition of the talk, we’ll still cover a few of the same themes to bring new folks up to speed, but we’ll also look at what’s changed in this ecosystem over the past year, take a look at new or enhanced features, offerings, runtimes, and programming models, and examine what use cases are becoming popular for serverless computing. We’ll also look at how tradeoffs have evolved, and definitely throw in a few demos.
Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.
In this workshop we will learn about some critical qualities of design and how to measure those. We will learn about these by working through some example code, refactoring it, and evaluating the design again at each stage of refactoring.
-Java 8 JDK or later version
-Your favorite IDE (Preferably IntelliJ IDEA Community Edition)
-git
Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.
In this workshop we will learn about some critical qualities of design and how to measure those. We will learn about these by working through some example code, refactoring it, and evaluating the design again at each stage of refactoring.
-Java 8 JDK or later version
-Your favorite IDE (Preferably IntelliJ IDEA Community Edition)
-git
Most nontrivial software systems suffer from significant levels of technical and architectural debt. This leads to exponentially increasing cost of change, which is not sustainable for a longer period of time. The single best thing you can do to counter this problem is to carefully manage and control the dependencies among the different elements and components of a software system.
This session will first look at the major reasons why so many systems end up in an unmaintainable state and then show how to address the problem by defining an enforceable architectural blue-print for a software system using an innovative domain-specific language for the description of software architecture. I the workshop part you will be able to create an architectural blueprint for a system of your choice. See workshop requirements for details.
Here are a couple things we will go over:
Bring a laptop with a system you would like to analyze. The system can be written in Java, C# or C/C++. For the analysis we will use a tool called Sonargraph-Architect. You can download the tool from www.hello2morrow.com after registering there. I will also bring USB sticks with the tool and the necessary licenses for those who did not have a chance to register and download before the workshop. You will get a three months free license for the tool, so you can continue to work with the tool after the workshop.
Most nontrivial software systems suffer from significant levels of technical and architectural debt. This leads to exponentially increasing cost of change, which is not sustainable for a longer period of time. The single best thing you can do to counter this problem is to carefully manage and control the dependencies among the different elements and components of a software system.
This session will first look at the major reasons why so many systems end up in an unmaintainable state and then show how to address the problem by defining an enforceable architectural blue-print for a software system using an innovative domain-specific language for the description of software architecture. I the workshop part you will be able to create an architectural blueprint for a system of your choice. See workshop requirements for details.
Here are a couple things we will go over:
Bring a laptop with a system you would like to analyze. The system can be written in Java, C# or C/C++. For the analysis we will use a tool called Sonargraph-Architect. You can download the tool from www.hello2morrow.com after registering there. I will also bring USB sticks with the tool and the necessary licenses for those who did not have a chance to register and download before the workshop. You will get a three months free license for the tool, so you can continue to work with the tool after the workshop.
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!
This session will focus on big data tools. It will take a broad high level look at big data technologies such as Kafka, HBase, HDFS, Spark, Hive, and variety of others. It will also include discussions of AWS big data technologies.
Come to this session if you want to learn more about big data technologies.
This session will focus on architecting enterprise big data systems. This will include developing a big data architectural perspective, looking at key big data capabilities, how to deal with governance, and other aspects of big data in an enterprise environment including cloud.
Come to this session if you want to learn about architecting and delivering enterprise big data systems.
Traditional approaches to software architecture do not address the core tenet of all agile practices - feedback! We make many of the most important architectural decisions early in the development lifecycle and fail to get accurate feedback on those decisions throughout implementation. Compounding the problem? Agile methods offer no architectural advice. This session explores several architectural practices that help increase architectural agility.
What’s the goal of architecture? To serve as a blueprint of the system that everyone understands? Possess the flexibility to evolve as new requirements emerge? To satisfy the architectural qualities, including performance, security, availability, reliability, and scalability? Yes. Yes. Yes. At the heart of these three questions are the three pillars of architecture - social, process, and structure. But how do we create software architectures that achieves all of these goals? And how do we ensure no disconnect occurs between developers responsible for implementation and architects responsible for the vision? In this session, we’ll explore several principles to increase architectural agility and provide some actionable advice that will help you get started immediately.
Recently, microservices have take the development community by storm. Though a modern architectural paradigm, the underlying principles of microservices are embedded across many proven traditional architectural approaches, especially modularity. At the end of the day, microservices are just one way to the increase modularity of our software system. But there are others.
In this session we will examine several different ways to modularize large software systems. We'll start with the “modular monolith” and demonstrate how this modular monolith gives us a significant degree of architectural agility to evolve the architecture to microservices by incrementally breaking pieces of the application off and deploying them as microservices.
Microservice architecture is a modern architectural approach that focuses on breaking apart the monolith and building modular services. But the framework we use has a tremendous impact on how we build and deploy services. A new type of framework has emerged that provides a lightweight stack for building microservices.
In this session, we will explore some modern Java micro frameworks for building microservices. Example frameworks you may see include Dropwizard, Spark, Ninja, RestExpress, Play, Restlet, and RestX.
The way we build and deliver software is changing. We must deliver software more quickly than ever before and traditional approaches to software architecture, infrastructure and methodology do not allow us to meet demand. We’ve reached the limits of agility through process improvement alone, and further increases demand we focus on improving architecture, infrastructure, and methodology simultaneously. 12 Factor is an app development methodology for building modern apps in the modern era.
Building modern apps requires modern methods and 12 Factor is an app development methodology that helps development teams build software by emphasizing development practices that meld together modern architectural paradigms with agile practices like continuous delivery for deployment to cloud platforms. In this session, we’ll examine the 12 Factors and explore how to apply them to apps built using Java.
Design patterns are common place 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.
Using lambda expressions, programming with streams, making use of lazy evaluations, putting the functional pipeline to good use, all of those are well intended use of functional programming. Once we get past the syntax and the semantics, the real challenge emerges. How in the world to actually build systems to use this paradigm? Is it practical to build applications that honor immutability, how to structure the applications using higher-order functions, and how to deal with those gnarly exceptions?
This presentation assumes that the audience is already familiar with functional style, with functions like map, filter, and reduce. It starts with the challenges to build realistic applications and dives into ways to structure the application to get the most out of the functional programming paradigm.
Every developer takes pride in the code they write, as they should. But, we know not all code are created equal. Not all of us create good quality code all the time. So, putting aside personal biases, how can we measure the quality of code.
In this presentation we will look at both qualitative metrics and also quantitative metrics and tools that can benefit software developers create maintainable better quality code.
Creating code is easy, creating good code takes a lot of time, effort, discipline, and commitment. The code we create are truly the manifestations of our designs. Creating a lightweight design can help make the code more extensible and reusable.
In this presentation we will take an example oriented approach to look at some core design principles that can help us create better design and more maintainable code.
Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business.
In this presentation we will discuss the reasons to evolve the architecture, some of the core principles that can help us develop in such a manner, and the ways to minimize the risk and succeed in creating a practical and useful architecture.
If you're not terrified, you're not paying attention.
Publishing information on the Web does not require us to just give it away. We have a series of tools and techniques for managing identity, authentication, authorization and encryption so we only share content with those we trust.
Before we tackle Web Security, however, we need to figure out what we mean by Security. We will pull from the worlds of Security Engineering and Software Security to lay the foundation for technical approaches to protecting our web resources. We will also discuss the assault on encryption, web security features and emerging technologies that will hopefully help strengthen our ability to protect what we hold dear.
Topics include:
If you're not terrified, you're not paying attention.
Publishing information on the Web does not require us to just give it away. We have a series of tools and techniques for managing identity, authentication, authorization and encryption so we only share content with those we trust.
Before we tackle Web Security, however, we need to figure out what we mean by Security. We will pull from the worlds of Security Engineering and Software Security to lay the foundation for technical approaches to protecting our web resources. We will also discuss the assault on encryption, web security features and emerging technologies that will hopefully help strengthen our ability to protect what we hold dear.
Topics include:
Big data applications have entire different demands than typical CRUD applications that have ruled the enterprise for decades. When dealing with high frequency and high volume of data, we have to reach to a different set of tools than we have been used to.
The objective of this presentation is to first discuss the issues with dealing with big data and high performance computing. Then we will take a look at libraries and tools that can more easily help us address those issues.
Unlock your latent photographic memory. In this session you'll learn failsafe techniques and systems that allow you to never forget names, appointments, or numbers. In the process you'll be more effective and imaginative at work; improve reading speed and comprehension, and shorten study times.
An improved memory will change your life, literally. In the session we will describe in detail several memory techniques that, with a little practice, will have you remembering virtually anything you want.
Encryption is great, especially when it works.
You put a lot of trust that the encryption offered by browsers, frameworks and libraries is giving you the protection you need to exchange sensitive information over the web. E-commerce, remote shells, bearer token-based authorization schemes and more would not be possible without technologies like the Transport Layer Security (TLS). Come listen to how it works, how it breaks and how you can become more confident that it does what you think it does.
What happens if web applications got really fast?
We are increasingly able to do more in the browser because of faster networks, optimized JavaScript engines, new standard APIs and more. There is a new initiative to allow a binary format called WebAssembly that will provide a compiled, cross-platform representation that will take us to the next level. Complex business applications and 3D video games will alike will benefit from this new standard. Come hear about what it can do for you.
At some point, graphics cards became serious business computationally. We'll explore why and how this switch has happened.
The most basic introduction to computers spells it out: software runs on the CPU. At some point, this became not entirely true. Graphics cards now support general purpose computing via apis such as CUDA and OpenCL. This talk will introduce you to how and why you can take advantage of these capabilities for a wide variety of applications. Moore's Law may have petered out, but we have plenty of other ways to make our applications run faster.
Bitcoin has roundly entered the public consciousness, but it is limited in its use beyond the specific constraints of the cryptocurrency. Ethereum is a new platform that has enabled developers to innovate in creating their own cryptocurrencies, platforms, smart contracts and more.
This talk will introduce the larger concepts of blockchains and decentralized applications as well as details on how to build running applications on the Ethereum platform.
These ideas and tools will help innovators disrupt organizations, markets, entire industries and even aspects of society. It's sounds like science fiction, but these thing are already happening. Come learn how.
We will cover:
Machine Learning is a huge, deep field. Come get a head start on how you can learn about how machines learn.
This talk will be an overview of the Machine Learning field. We’ll cover the various tools and techniques that are available to you to solve complex, data-driven problems. We’ll walk through the algorithms and apply them to some real but accessible problems so you can see them at work.
Documents contain a lot of information. We'll introduce you to a variety of techniques to extract them.
Machine Learning techniques are useful for analyzing numeric data, but they can also be useful for classifying text, extracting content and more. We will discuss a variety of open source tools for extracting the content, identifying elements and structure and analyzing the text can be used in distributed, microservice-friendly ways.
The toolset for building scalable data systems is maturing, having adapted well to our decades-old paradigm of update-in-place databases. We ingest events, we store them in high-volume OLTP databases, and we have new OLAP systems to analyze them at scale—even if the size of our operation requires us to grow to dozens or hundreds of servers in the distributed system. But something feels a little dated about the store-and-analyze paradigm, as if we are missing a new architectural insight that might more efficiently distribute the work of storing and computing the events that happen to our software. That new paradigm is stream processing.
In this workshop, we’ll learn the basics of Kafka as a messaging system, learning the core concepts of topic, producer, consumer, and broker. We’ll look at how topics are partitioned among brokers and see the simple Java APIs for getting data in and out. But more than that, we’ll look at how we can extend this scalable messaging system into a streaming data processing system—one that offers significant advantages in scalability and deployment agility, while locating computation in your data pipeline in precisely the places it belongs: in your microservices and applications, and out of costly, high-density systems.
Come to this workshop to learn how to do streaming data computation with Apache Kafka!
Workshop Repo:
https://github.com/confluentinc/kafka-workshop.git
Here's what we need:
Install Docker for Windows or Docker for Mac on your machine. If you're using Linux, you probably know better than I do how to get Docker running. :)
Clone the workshop repo and perform exercise 0. This is very important, because it will do the bulk of the downloading you need to do to get the exercises running. I may make some small tweaks to the Docker Compose file between now and the workshop, but this should result in minimal additional downloading that conference wifi can accommodate. If you do the docker-compose pull on workshop day, it might be painful.
Software development is hard enough with one team, but coordinating work across multiple teams can be especially challenging. The more brains involved, the more complex the dependencies, the easier it is to make mistakes.
What are the biggest pains you see out in the wild? What types of strategies have you found to work? Come share your stories and lessons learned.
In this group discussion, we'll dig into one story at a time, explore the nuts & bolts, then distill lessons learned and improvement ideas.
If you love a good war story, or have your own story to share, you won't want to miss this session!
Software development is hard enough with one team, but coordinating work across multiple teams can be especially challenging. The more brains involved, the more complex the dependencies, the easier it is to make mistakes.
What are the biggest pains you see out in the wild? What types of strategies have you found to work? Come share your stories and lessons learned.
In this group discussion, we'll dig into one story at a time, explore the nuts & bolts, then distill lessons learned and improvement ideas.
If you love a good war story, or have your own story to share, you won't want to miss this session!
No single architectural style solves all needs. Though microservices have taken the developer community by storm recently, they are not always the optimal solution. In some cases, a more monolithic architecture may be more suitable short term. Or perhaps a more traditional system of web services that allow you to leverage existing infrastructure investment is preferable. Fortunately, proven architectural practices allow you to build software that transcends specific architectural alternatives and develop a software system that gives the development team the agility to shift between different architectural styles without undergoing a time-consuming, costly, and resource intensive refactoring effort. Modularity is the cornerstone of these alternatives.
In this workshop, we will examine the benefits and drawbacks of several different modular architecture alternatives and we’ll explore the infrastructure, skills, and practices necessary to build software with each of these alternatives. There will be straightforward exercises and demonstrations that show the alternatives and how to create software that provides the architectural agility to easily shift between architectural alternatives.
Topics discussed include:
Pen and paper
Java 8+
Ant
Gradle
Graphviz (Optional)
Heroku account and Heroku CLI (Optional, only if you want to deploy to Heroku PaaS)
It seems like everyday there is a new headline about a security breach in a major company’s web application. These breaches cause companies to lose their credibility, cost them large sums of money, and those accountable undoubtedly lose their jobs. Security requires you to be proactive. Keep your employer out of the headlines by learning some key security best practices.
This hands-on workshop is designed to teach you how to identify and fix vulnerabilities in Java web applications. Using an existing web application, you will learn ways to scan and test for common vulnerabilities such as hijacking, injection, cross-site scripting, cross-site forgery and more. You will learn best practices around logging, error handling, intrusion detection, authentication and authorization. You will also learn how to improve security in your applications using existing libraries, frameworks and techniques to patch and prevent vulnerabilities.
It seems like everyday there is a new headline about a security breach in a major company’s web application. These breaches cause companies to lose their credibility, cost them large sums of money, and those accountable undoubtedly lose their jobs. Security requires you to be proactive. Keep your employer out of the headlines by learning some key security best practices.
This hands-on workshop is designed to teach you how to identify and fix vulnerabilities in Java web applications. Using an existing web application, you will learn ways to scan and test for common vulnerabilities such as hijacking, injection, cross-site scripting, cross-site forgery and more. You will learn best practices around logging, error handling, intrusion detection, authentication and authorization. You will also learn how to improve security in your applications using existing libraries, frameworks and techniques to patch and prevent vulnerabilities.
The end has come. REST is finally dead. The world of reactive data sources has killed it, and your users will be forever grateful. Gone from your applications are 'Refresh' buttons. Gone from your sever code are the polling routines, pinging remote services for changes. Customers dashboards update seamlessly and in real time. Your users have never been happier.
If this sounds like a world that you want to live in, join us for this awesome workshop exploring the various options available to the enterprise architect when designing and implementing the reactive software layers and constructs necessary to make this dream a reality today!
Users are demanding applications which keep them informed of new events as soon as they happen. They are no longer willing to accept “Just hit the refresh button” or “It will update in a few minutes by itself” when demanding satisfaction of this new basic requirement. They are collaborating in real time, co-editing, co-authoring, 'co-laborating' with colleagues across the country and around the world, chatting over the phone or VOIP while working together via your app. They want their updates to travel from their laptop to their co-workers screens as fast as their voice reaches them through the phone. This is a tough requirement to meet, especially when trying to put a modern face on a legacy app or integrating a shiny, new, reactive app with a legacy, REST-based datasource.
And it is not just your end-users that are clamoring for reactive data sources. No, the requirements for server-to-server communication of changes to data or state have forever changed. REST no longer is King in the world of web services. REST just doesn't cut the mustard any longer. Corporate users of your data services are demanding more flexible, reactive options when consuming your endpoints.
Join us for this thought provoking and exploratory workshop and learn the what, why and how of dealing with these new architectural challenges as we explore how you can architect your new or existing stack to satisfy the ever-increasing demand for 'real-time' applications and data services fed by reactive data sources regardless of your current technology choices.
This workshop is for developers of all levels from any programming language background. The patterns discussed will be applicable to all software stacks.
Java 9 with the Jigsaw module system is here. In this session, we'll explore the basics of the Jigsaw module system and examine the impact it will have on how we build Java applications. We will dig into it's major features, including dependency management and Jigsaw services. Once we understand Jigsaw's basics, we will explore what it's going to take to migrate existing Java application to Java 9 and leverage Jigsaw.
Jigsaw's impact stands to be consequential. Jigsaw will restrict application code from accessing non-published JDK classes (ie. sun.com), require you to be explicit in declaring your dependencies, and more. We will explore Jigsaw basics and then dig into the impact Jigsaw will have on migrating existing Java applications to Java 9.
Reactive architecture patterns allow you to build self-monitoring and self-healing systems that can react to both internal and external conditions without human intervention. How would you like to design systems that can automatically grow as the business grows, automatically handle varying load (cyber Monday?), and automatically handle (and repair) internal and external errors, all without human interaction? I'll show you how to do this with your current technology stack (no special languages, tools, frameworks, or products). In this two-part session I will leverage both slides and live coding using Java and RabbitMQ to describe and demonstrate how to build reactive systems. Get ready for the future of software architecture - that you can start implementing on Monday.
Part 1 Agenda:
Reactive architecture patterns allow you to build self-monitoring and self-healing systems that can react to both internal and external conditions without human intervention. How would you like to design systems that can automatically grow as the business grows, automatically handle varying load (cyber Monday?), and automatically handle (and repair) internal and external errors, all without human interaction? I'll show you how to do this with your current technology stack (no special languages, tools, frameworks, or products). In this two-part session I will leverage both slides and live coding using Java and RabbitMQ to describe and demonstrate how to build reactive systems. Get ready for the future of software architecture - that you can start implementing on Monday.
Part 2 Agenda
There are many different uses for Apache Kafka. It can be used as a streaming broker, event broker for transactional data, and even a database. This session is about understanding streaming architecture and how to implement it using Apache Kafka. I start this session by talking about some of the streaming architecture patterns, then dive into how Apache Kafka works using the Core API. Using live coding examples in Apache Kafka, I also talk about the differences between Kafka and regular messaging (RabbitMQ, ActiveMQ, etc.) and when you should use each. I end this session by putting everything together, showing an actual streaming architecture using Kafka within a Microservice ecosystem for gathering various metrics for business and operational monitoring and reporting.
Agenda:
One of the expectations of any software architect is to analyze the current technology environment and recommend solutions for improvement. This is otherwise known as continually assessing architecture vitality. Too many times software architects fail to regularly perform this task, leading to emergency refactoring efforts to save a troubled system from failure. The question is, what does it mean to assess an application architecture? In this session we will explore static analysis metrics and tools and techniques for leveraging those metrics for determining structural decay. Using a real-world large-scale application, I'll show you how to leverage code metrics to find (and fix) structural decay before it gets you into trouble.
Agenda
It seems like all we talk about these days is making our architectures more modular. Buy why? In this session I will discuss the drivers and reasons why it is essential to move towards a level of modularity in our architectures. I will discuss and show real-world use cases of distributed modular architectures (specifically microservices and service-based architecture), and then discuss in detail the core differences between microservices and service-based architecture and when you should consider each. I'll end the talk by discussing the most effective way of migrating to modular distributed architectures.
Agenda:
Even though teams are gaining more experience in designing and developing microservices, nevertheless there is still a lot to learn about this highly distributed and somewhat complicated architecture style. Unfortunately, lots of microservices anti-patterns and pitfalls emerge during this learning curve. Learning about these anti-patterns and pitfalls early on can help you avoid costly mistakes during your development process. While anti-patterns are things that seem like a good idea at the time and turn out bad (see martinfowler.com/bliki/AntiPattern.html), pitfalls are those practices that are never a good idea at the time - ever. In this session I will cover some of the more common anti-patterns you will likely encounter while creating microservices, and most importantly describe some of the techniques for avoiding these anti-patterns.
Agenda
Even though teams are gaining more experience in designing and developing microservices, nevertheless there is still a lot to learn about this highly distributed and somewhat complicated architecture style. Unfortunately, lots of microservices anti-patterns and pitfalls emerge during this learning curve. Learning about these anti-patterns and pitfalls early on can help you avoid costly mistakes during your development process. While anti-patterns are things that seem like a good idea at the time and turn out bad (see martinfowler.com/bliki/AntiPattern.html), pitfalls are those practices that are never a good idea at the time - ever. In this session I will cover some of the more common pitfalls you will likely encounter while creating microservices, and most importantly describe some of the techniques for avoiding these pitfalls.
Agenda
Organizing and governing enterprise architecture models and processes is a daunting task. No wonder so many people are wondering whether an enterprise architecture framework will help. Understanding various enterprise architecture frameworks like Zachman, TOGAF, and FEAF is the first step. More important, however, is knowing whether you need an EA framework at all. In this session I will start with the basics of the Zachman Framework, TOGAF (The Open Group Architecture Framework), and FEA (Federal Enterprise Architecture) so that you can gain a complete understanding of how each of these frameworks work. During the journey of these frameworks I will continually point out the strengths and weaknesses of each framework to arrive at the best part of the session - how to build your own EA Framework that works for you and your situation.
Agenda
While there are dozens of activities within an enterprise architecture effort, there is only one primary outcome - an enterprise architecture roadmap. Roadmaps describe what efforts (i.e., projects) need to be done to meet a specific objective, the dependencies between those efforts, and the prioritization of those efforts. In this session I'll cover the four main models that make up an EA roadmap and show you techniques for how to identify projects, classify projects, prioritize projects, and finally illustrate these efforts through consolidated roadmap views. By the end of this session you'll have a clear view of why enterprise architecture is needed, the purpose behind it, and how to create an effective and clear enterprise architecture roadmap.
Agenda
There are many traditional approaches to enterprise architecture. Unfortunately, these traditional approaches are one of the reasons EA fails in today's world. In the first part of this session I'll describe and demonstrate the traditional approaches to EA, explain why they fail, and then show you several modern approaches to enterprise architecture that hold lots of promise in transforming EA to the 21st century. In the second part of this session I'll then describe 4 different enterprise architecture strategies for overall EA team structure, governance, process, and standards.
Agenda
A prior Gartner survey found that 40% of all enterprise architecture efforts were failing or had failed. One of the primary reasons for these failed attempts at enterprise architecture is that no one really knows what it is or how to properly establish and run an effective enterprise architecture program. Interestingly enough, a recent Gartner survey showed that 70% of all businesses were looking to start or restart their enterprise architecture programs. But how do you make sure you don't fail once again? One of the ways is by embracing agile enterprise architecture. In this session you will learn the ingredients for creating an agile enterprise architecture practice in areas of communication, modeling, and governance.
Agenda
Everywhere you look, reactive applications and programming techniques are all the rage. NgRx is a set of reactive extensions that provide tools to help you develop reactive applications in JavaScript. Flexible and powerful, applying these tools can yield amazing results … or can result in the stuff nightmares are made of. Following a simple set of guidelnes and best practices can help your project maximize the benefits of using these tools while avoiding the potential pitfalls. Join us to explore these guidelines and give your projects the edge they need to be successful!
Everywhere you look, reactive applications and programming techniques are all the rage. NgRx is a set of reactive extensions that provide tools to help you develop reactive applications in JavaScript. Flexible and powerful, applying these tools can yield amazing results … or can result in the stuff nightmares are made of. Following a simple set of guidelines and best practices can help your project maximize the benefits of using these tools while avoiding the potential pitfalls. Join us to explore these guidelines and give your projects the edge they need to be successful!
The traditional 'App' is dead. Engaging your users has never been more important than it is today. Competition for user attention is fierce and ruthless. Web Push Messaging, Smart Speakers and BOTs can thrill your users and give you the edge over your competitors. But it is imperative that you design your apps and services to be both user and developer friendly if you want to take advantage of these next generation engagement technologies. Join us to ensure you are armed with the latest best practices in designing and implementing these game changing devices which will let you delight and retain new and existing users of your services.
Engaging your users has never been more important than it is today. Competition for user attention is fierce and ruthless. Web Push Messaging, Smart Speakers and BOTs can thrill your users and give you the edge over your competitors. But it is imperative that you design your apps and services to be both user and developer friendly if you want to take advantage of these next generation engagement technologies. Join us to ensure you are armed with the latest best practices in designing and implementing these game changing interaction aids.
Routers are probably the most unappreciated, underutilized and misused component in your application architecture. Join us as we fully explore the architectural patterns that make up this cross-cutting aspect of your overall technology stack and how you can optimally make use of all of what this layer should be delivering to your developers and your users!
As an architect on a SPA project, there are many decisions you will face. One of the most important decisions you have to make is how to design your routing topology: The routing patterns, hirarchy and data flow used within your application. Often, wrong decisions can lead to performance, usability and reliability issues which are difficult to diagnose and even more difficult to correct mid-project. Join us as we explore design considerations and best practices that will help you navigate this dark science to emerge victorious!
Security should always be built with an understanding of who might be attacking and how capable they are. Typical threat modeling exercises are done with a static group of threat actors applied in “best guess” scenarios. While this is helpful in the beginning, the real data eventually tells the accurate story. The truth is that your threat landscape is constantly shifting and your threat model should dynamically adapt to it. This adaptation allows teams to continuously examine controls and ensure they are adequate to counter the current threat actors. It helps create a quantitative risk driven approach to security and should be a part of every security teams tools.
Join Aaron as he demonstrates how to look at web traffic to analyze the threat landscape and turn request logs into data that identifies threat actors by intent and categorizes them in a way that can be fed directly into quantitative risk analysis. Aaron will show how important this data is in driving risk analysis and creating an effective and appropriate security program.
Are you using or moving to AWS? Have you considered how you organize and secure your AWS environments? The growing push to cloud providers has allowed us to move faster and tackle problems more efficiently. The same freedoms that have allowed us to move faster have also created scenarios where security issues are exposed by accident and/or without proper management and review. As companies move toward more and more cloud usage, teams are pushed harder to ensure the same compliance and security requirements that exist in slower moving private environments. This has the potential to put us right back where we came from.
Join Aaron as he talks through the most critical security decisions you can make for you AWS environments. He will identify issues and solutions in an automation friendly fashion that aim to fit seamlessly into the development and deployment lifecycle. This session will cover the following topics:
In addition to these topics a heavy emphasis on both platform and server automation will be included. Please note that this session is heavily tuned to people using Amazon Web Services. If you are using another Cloud provider the ideas will still be relevant, but not all solutions will be available for your provider.
This talk discusses the progression from a monolithic application, where the application and user data are in the same database, to a microservice architecture, where the application and user data are in separate databases.
It covers the history behind sessions and some of the issues with them. It then builds on this by introducing tokens to manage identity and finally ends with a complete discussion of JSON Web Tokens (JWTs). I cover what JWTs are, how they are used, the benefits and some of the issues with them.
Vue is a new, powerful framework for building real-world applications. Enterprise ready, with a rich and diverse ecosystem, Vue is the currently ranked as the #2 front end framework and is rapidly gaining on its older brother, ReactJS. Join us for this first in a comprehensive series of session which will take you from blind novitiate to visionary VueJS expert in no time!
This first session in our VueJS series begins our journey to Vuetopia with an exploration of the basics of the framework including:
This is my story of lessons learned on how to stop the crushing effects of business pressure… I was team lead with full control of our green-field project. After a year, we had continuous delivery, a beautiful clean code base, and worked directly with our customers to design the features. Then our company split in two, we were moved under different management, and I watched my project get crushed.
As a consultant, I saw the same pattern of relentless business pressure everywhere, driving one project after another into the ground. I made it my mission to help the development teams solve this problem. This is my story of lessons learned on how to transform an organization from the bottom up. I'll show you how to lead the way.
The crushing business pressure is caused by a broken feedback loop that's baked into the organization's design. In this presentation, I'll show you how to fix the broken feedback loop. Learn how to:
If the system is broken, we need to fix the system. You can change the system by making the decision to lead.
Developers and architects are increasingly called upon to solve big problems, and we are able to draw on a world-class set of open source tools with which to solve them. Problems of scale are no longer consigned to the web’s largest companies, but are increasingly a part of ordinary enterprise development. At the risk of only a little hyperbole, we are all distributed systems engineers now.
In this talk, we’ll look at four distributed systems architectural patterns based on real-world systems that you can apply to solve the problems you will face in the next few years. We’ll look at the strengths and weaknesses of each architecture and develop a set of criteria for knowing when to apply each one. You will leave knowing how to work with the leading data storage, messaging, and computation tools of the day to solve the daunting problems of scale in your near future.
As Cloud computing becomes more popular and many businesses are keen to adopt it,one of their major concerns is security. In spite of the hype accompanying it and the success stories from the large organisations who have adopted, there are also numerous examples of breaches that have been experienced in the cloud. Many businesses would like to know how to create a secure cloud infrastructure to ensure that all their applications and data is well protected.
This talk is based on my experience in different projects that I have been involved in, some pitfalls that my team has fallen into and considerations that we can take while preparing for new cloud infrastructure.
This talk is not about a particular cloud vendor solutions but about the questions and considerations to take to ensure that your cloud infrastructure is secure.
The considerations include:
Ensuring data is securely protected from anyone who would want to access it.
Encrypting the data so that if it got to the wrong people
Authentication to ensure that only the authorised people can access the data
Enabling due diligence so that data is not accessible by those who eavesdrop and would like to modify it.
Protecting the infrastructure from Denial of Service attacks(DOS) from both internal and external sources
This talk also highlights some common pitfalls:
Using components for a different purpose other that what it is created to for.
Waiting till after the application is built before preparing the infrastructure.
Creating the infrastructure then thinking about the security at the last minute.
At the end of this session, attendees:
Are able to evaluate the level of security that they need
Can reorganise their priority while designing for their cloud infrastructure
Are equipped to create a highly secure infrastructure
We all have seen our share of bad code and some really good code as well. What are some of the common anti patterns that seem to be recurring over and over in code that sucks? By learning about these code smells and avoiding them, we can greatly help make our code better.
Come to this talk to learn about some common code smell and to share your experiences as well.
Engaging your users has never been more important than it is today. Competition for user attention is fierce and ruthless. BOTs and Smart Speakers can thrill your users and give you the edge over your competitors. Join us for a fast-paced and entertaining exploration of this new way to attract, engage, retain and amaze your users!
BOTs are a new and compelling way to engage with users. Want to increase your conversion rates by 10 or 20%? Deploy an effective BOT and watch your engagement rates soar!
In this cool and compelling session, we will create, deploy and demonstrate a fully functional BOT. Join us for a fast-paced and entertaining exploration of this new way to attract, engage, retain and amaze your users!
Chaos Engineering, pioneered by Netflix, is the discipline of experimenting on a distributed system in order to build confidence in the system's capability to withstand turbulent conditions in production.
In this presentation, we'll take a look at the problem of building resilient software, and discuss how applying Google's SRE principles and patterns for architectural resiliency can help us to solve it. We'll then examine how the practice of Chaos Engineering can help us to prove or disprove the resiliency of our systems.
Back in the day, it used to be so simple. Our projects had a main.js file that contained a few hundred lines and every so often the corporate communication department would ship out some new CSS files. But now things are not quite so easy. With more and more single page apps containing thousands or hundreds of thousands of lines of JavaScript, we're going to need a bigger boat.
In this talk I will explore various options you can deploy on your projects to tame the mass of code that lives on the front end of our applications. From NPM to Gulp to Webpack, this talk will help you establish a front end pipeline.
How is your architecture group perceived in your organization? Be honest now…is it seen as a group of ivory tower dilettantes intent on saying NO while filling a whiteboard with boxes and arrows? Or is it seen as a key component in developing rock solid software? If it's the former, how do you shift things towards the latter? Even if everyone thinks the world of the architecture team, odds are you have more work than you can handle and a bunch of tech leads that may (or may not) be thinking of all the right ilities. How do we reach out to them, mentor them, and bring them in to the fold?
Building an architectural community can help grow architects, improve the architect group's standing in the organization and ensure projects are built to last. This talk will discuss the steps one group took to grow a community of practicing architects, recognizing that not all those doing architecture work have “architect” in their job titles.
Stories and lessons from architecture, design, process, and other sources, each illustrating important principles and pitfalls for modern architects.
Those who cannot remember the past are condemned to repeat it. –George Santayana
The past is never dead. It's not even past. –William Faulkner
Most developers pursue the Latest and Greatest with intense fervor, yet the history of engineering, including software projects, contains rich lessons that we risk repeating ad nauseam. This session recounts a variety of stories of projects that failed architecturally…and why. Ranging from the Vasa in 1628 to Knight Capital in 2012, each story tells of a mistaken interpretation of some architectural fundamental principle and the consequences–some good, some less so. I I also look at the common threads for these stories, which resonates with problems many companies have but don't realize.
nullOn the one hand, agile processes, like Scrum, promote a set of practices. On the other hand, they are based on a set of principles. While practices are important at present time, principles allow us to adapt to future situations.
In this talk we look at Inspection and Adaptation and construct an underlying theory to help organizations practice these activities. Why a theory? Because, as much as we want to, simply invoking “Inspect and Adapt” will not make it happen.
It turns out that for almost half a century the software engineering community has been working on a theory of reflection, which is defined as “the ability of a system to inspect and adapt itself”. We draw parallels between the design of software systems and the design of organizations, and learn several lessons:
Reflection must be built into the organization.
Reflection incurs a cost that must be planned for.
Inspection is easier than adaptation.
We can only reflect on what is explicit.
Reflection is a design tool that enables unanticipated evolution.
This sounds technical, but the most important observation is that reflection is an inherent human ability. It only requires training to develop it into a capability.
We produce software systems at an ever increasing rate, but our ability to cleanup after older systems does not keep up with that pace. Because of the impact of our industry, we need to look at software development as a problem of environmental proportions. We must build our systems with recycling in mind. As builders of the future world, we have to take this responsibility seriously.
On the one hand, this is great. On the other hand, our ability to get rid of older systems does not keep up with that pace. Let’s take an example: a recent study showed that there are some 10’000 mainframe systems still in use containing some 200 billion lines of code. These systems are probably older than most developers. This shows that software is not that soft, and that once in use, systems produce long lasting consequences. We cannot continue to disregard how we will deal with software systems at a later time.
Engineers spend as much as half of the effort on understanding software systems and the percentage grows with the size and age of the system. In essence, software engineering is more about dealing with existing systems than it is about building them. Two decades ago, Richard Gabriel coined the idea of software habitability. Indeed, given that engineers spend a significant part of their active life inside software systems, it is desirable for that system to be suitable for humans to live there. We go further and introduce the concept of software environmentalism as a systematic discipline to pursue and achieve habitability.
We must build our systems with recycling in mind. We have to be able to understand these systems in the future and be able to reuse and evolve them as needed.
Engineers have the right to build upon assessable systems and have the responsibility of producing assessable systems. For example, even if code has often a textual shape, it is not text. Hence, reading is not the most appropriate approach to deal with code. The same applies to logs, configurations and anything else related to a software system. It’s all data, and data is best dealt with through tools. Not any tools would do either. We need custom tools that can deal with specific details. No system should get away without dedicated tools that help us take it apart and recycle it effectively.
Who should build those tools? Engineers. This implies that they have to be empowered to do it. We need to go back to the drawing board to (1) construct moldable development environments that help us drill into the context of systems effectively, (2) reinvent our underlying languages and technologies so that we can build assessable systems all the way down, and (3) reeducate our perception of what software engineering is.
Because of the spread and impact of the software industry, we need to look at software development as a problem of environmental proportions. As builders of the future world, we have to take this responsibility seriously.
This two session workshop covers messaging concepts, standards (JMS, EIP), and technologies including hands-on exercises with ActiveMQ, Spring, and Camel.
Topics
Fundamentals: JMS, EIP
Technologies and Architectures: ActiveMQ
Enterprise Integrations: Spring Framework & Apache Camel
Demos and Hands-on Exercises
Download Prior to Workshop
This two session workshop covers messaging concepts, standards (JMS, EIP), and technologies including hands-on exercises with ActiveMQ, Spring, and Camel.
Topics
Fundamentals: JMS, EIP
Technologies and Architectures: ActiveMQ
Enterprise Integrations: Spring Framework & Apache Camel
Demos and Hands-on Exercises
Download Prior to Workshop
“Technical debt” is a successful metaphor that exposes software engineers to economics, and managers to a significant technical problem. It provides a language that both engineers (“technical”) and managers (“debt”) understand.
But, “technical debt” is just a metaphor that has its limitations, too. The most important limitation is that it presents a negative proposition: The best thing that can happen to you is having no technical debt.
Technical debt is both brought about and solved as a result of decisions. As such, we turn our attention to how people reach decisions about a software system. Decision making is a critical software engineering activity. Developers alone spend some half of their time reading code. This means half of the budget. Even though it is the single most significant development activity, nobody really talks about how this effort is being spent.
It’s time to change this. The talk motivates the need for software assessment as an explicit discipline, it introduces the humane assessment method and outlines the implications.
Software has no shape. Just because we happen to type text when coding, it does not mean that text is the most natural way to represent software.
We are visual beings. As such we can benefit greatly from visual representations. We should embrace that possibility especially given that software systems are likely the most complicated creations that the human kind ever produced. Unfortunately, the current software engineering culture does not promote the use of such visualizations. And no, UML does not really count when we talk about software visualizations. As a joke goes, a picture tells a thousand words, and UML took it literally. There is a whole world of other possibilities out there and as architects we need to be aware of them.
In this talk, we provide a condensed, example-driven overview of various software visualizations starting from the very basics of what visualization is.
Visualization 101:
How to visualize
What to visualize
Interactive software visualizations
Visualization as data transformation
While the Web itself has strong decentralized aspects to how it is used, the backend technologies are largely centralized. The naming systems, the routing systems and the traffic that all points back to the same place for a website are all centralized technologies. This creates both a liability as well as a control point.
In order to break free of some of these limitations, new technologies are emerging to provide a more decentralized approach to the Web.
This talk will walk you through some emerging technology to provide decentralized content storage and distribution, edge computing and more. We will touch upon the Interplanetary Filesystem, WebTorrent, Blockchain spin offs and more.
This open source machine learning framework from Google has taken off. Come learn what you can do with it in your own organization.
TensorFlow is a powerful data flow-oriented machine learning framework developed by Google's Brain Team. It was designed to be easy to use and widely applicable on both numeric, neural network-oriented problems as well as other domains. We'll cover the over view as well as apply it to several fun, realistic problems.
This two session workshop covers AMQP messaging concepts and technologies including hands-on exercises with RabbitMQ, Spring and Docker
Topics
Fundamentals: AMQP
Technologies and Architectures: RabbitMQ & Spring
Demos and Hands-on Exercises
Download Prior to Workshop
This two session workshop covers AMQP messaging concepts and technologies including hands-on exercises with RabbitMQ, Spring and Docker
Topics
Fundamentals: AMQP
Technologies and Architectures: RabbitMQ & Spring
Demos and Hands-on Exercises
Download Prior to Workshop
Deploying simple serverless applications using AWS Lambda is getting easier every day, but for software architects dealing with complex systems, Lambda’s constrained execution environment seems to put it out of consideration, especially when combined with organizational technology choices like Java.
John explores AWS Lambda in depth, covering the Lambda execution environment, Lambda’s Java runtime characteristics and best practices for Java-based Lambdas, and techniques for effectively using services like Cloudwatch, DynamoDB, and Kinesis with Lambdas. Some techniques will be supported by live demos. You’ll come away with a set of best practices that will enable you to effectively architect and operate serverless applications that include Java-based Lambdas.
In this sessions we'll see how to use components of Spring Cloud to configure and discover microservices in a cloud native microservice-architected application. Specifically, we'll look at Spring Cloud Netflix and Netflix' Eureka and Ribbon projects for service discovery as well as the Spring Cloud Config project's configuration server to provide a central point of external configuration.
Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.
If the individual microservices are to work together in service of the greater application, then they must know about each other. Rather than hardcode the specifics of each microservice within every other microservice, it's better to provide a registry with which a service can register and other services may use to lookup those service details.
Microservices, like any application, will also likely depend on application-level configuration. It's generally a good idea to keep that configuration separate from the application itself, and this is even more true with microservices. Using a centralized configuration service, microservices can obtain their configuration details, some of which may be shared across many microservices. Because it is separate from the application/microservice code, that configuration itself can be versioned and evolve at a pace independent of the microservices it serves.
In this session, we'll look at how to monitor the health of individual services in a microservice-architected application as well as trace the path of data and processing as it flows from service to service. Specifically, we'll look at Spring Cloud Netflix and Netflix OSS' Hystrix project to not only apply the circuit breaker pattern for failure and latency protection to microservices and monitor the health of those circuit breakers in a running application. Additionally, we'll look at Spring Cloud Sleuth and Zipkin to trace processing through a microservice-based application.
Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.
Failure is always a possibility in any application. But when an application is composed of microservices, it's important for that each service contain its failure and keep its problems to itself to avoid cascading errors to other services. Likewise, latency can be a concern that is compounded when felt across multiple microservices and it's important to avoid cascading latency issues. By applying the circuit breaker pattern in your microservices, you can ensure that if anything goes wrong in a given service, it stays in that service and doesn't have any negative impacts to other services. Moreover, metrics published by those circuit breakers can provide helpful insight into the health of an application.
When things do go wrong, it may also be helpful to trace the flow and processing of information as it passes from one microservice to another. Traditionally, tracing involves following the logs of a single application. But in a microservice-based application where many services and many instances of those services are involved, tracing is much more challenging. What's needed is a way for microservices to submit timing and tracing information to a central tracing service that coordinates that data and can present the flow of data in a single, easily digested view.
In this session, we'll see how to develop microservices that are components of a flow of data, but that do not necessarily involve REST. We'll also see how to develop ephemeral microservices–microservice that are triggered to perform a job, then shutdown when that job is complete. Specifically, we'll look at Spring Cloud Stream for flow-based microservices, Spring Cloud Task for ephemeral microservices, and Spring Cloud Data Flow which orchestrates those stream- and task-based services.
Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.
Microservices are commonly thought of as small REST-based services that are assembled to form a larger, more complete application. In reality, however, REST is only the communication mechanism which is only a implementation detail and not intrinsic to the notion of microservices. Meanwhile, data processing and integration between various components of an application and external services is a key factor of many applications. In cloud native applications, this kind of data flow and processing is still relevant.
In this session, you'll learn how to take advantage of the latest features of Spring Security and Spring Boot to secure an application, both at the web layer and at the method-level.
Information is probably the most valuable item we now have; crooks are looking for ways to steal our data and identities by sneaking into unsecured applications. As software developers, we must take steps to protect the information that resides in our applications. Whether it’s an email account protected with a username/password pair or a brokerage account protected with a trading PIN, security is a crucial aspect of most applications.
Spring Security is an extension to the Spring Framework that provides security to Spring applications both at the HTTP request level as well as at method invocation.
In this session we'll consider how to put a face on the services in the cloud that comprise an application and how to ensure that communication between the user interfaces and the backend services is secure. Specifically, we'll look at Spring Cloud Netflix and the Zuul project to create an API gateway through which the UI can communicate with the services. And we'll see how to use Spring Security and Spring Security OAuth (along with Spring Boot autoconfiguration) to secure that communication.
Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.
In this session, we'll see how to define contracts for microservice APIs using Spring Cloud Contract that can assist in testing clients of those services. Additionally, we'll look at Spring RestDocs, a project that provides semi-automatic production of API documentation.
Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.
Testing microservices, particularly when testing the code in one service that invokes another, can be challenging. It involves writing tests that mock out the remote service. But since it they target a remote service whose code is separate, those mocks may fall out of sync with changes in the service that they mock. Rather than manually write mocks against our own understanding of an API, it would be better to define a contract that both the remote API and the mock agree upon. And for testing purposes, mocks can be generated from that contract.
When it comes to documenting microservice APIs, you have a few choices: You can either fully automate documentation, based on the implementation code, or you can manually document the API. The former creates a tight-coupling between the documentation and the code, which makes the documentation fragile when the code changes. The latter requires much more effort, both in the initial creation as well as in keeping it in sync with API changes. But what if there were a middle-ground, a semi-automatic way to document an API?
Serverless is a big topic these days. More specifically, Function as a Service (FaaS) enables small-scale functions deployed in the cloud to be enabled only as needed. Compared to Platform as a Service (PaaS) services which are “always on” and require explicit scaling, FaaS services wake up when needed and are scaled by the platform automatically.
Imagine a service that only gets invoked one per hour. In PaaS, that service is always running and ready to handle requests, consuming processor resources and ultimately costing more to be ready at a moment's notice. In contrast, FaaS services awaken quickly upon invocation and go away when finished, conserving resources and cost.
In this example-driven session, we'll see how to create and deploy Function as a Service (FaaS) services with Spring and Spring Boot.
In this session, we'll explore the new reactive features in Spring 5 to build reactive, non-blocking applications using Spring's familiar programming model.
Traditionally, applications have been built using a blocking, synchronous model. Although comfortable and intuitive for most programmers, this model doesn't scale well. And although there are several new approaches to reactive programming, they don't necessarily fit into the familiar programming model that Spring developers are accustomed to working with.
Spring 5 has introduced a set of new reactive features, enabling non-blocking, asynchronous code that scales well using minimal threads. Moreover, it builds on the same concepts and programming models that Spring developers have used for years.
This is my story of lessons learned on why improvement efforts fail… I had a great team. We were disciplined about best practices and spent tons of time on improvements. Then I watched my team slam into a brick wall. We brought down production three times in a row, then couldn’t ship again for a year.
Despite our best efforts with CI, unit testing, design reviews, and code reviews, we lost our ability to understand the system. We thought our problems were caused by technical debt building up in the code base, but we were wrong. We failed to improve, because we didn’t solve the right problems. Eventually, we turned our project around, but with a lot of tough lessons along the way.
In this talk, we'll go through a deep-dive case study that starts with project failure, then revisit all the mistakes we made over a 3 year journey to turn the project around. We'll discuss bad assumptions, strategies that failed, ideas that changed, techniques and tools that changed, and how we eventually learned our way to victory.
After reviewing each mistake, we'll have a group discussion about the underlying reasons, so you can avoid these mistakes on your own project.
Are you considering a switch to microservices and trying to determine the benefits and tradeoffs?
This talk will cover the core tenants of a microservice architecture and how they can help guide you through the decision making process. You’ll uncover the reasons why sometimes microservices aren’t the right solution and when they will truly save you time and money. We’ll also cover core components of a microservice architecture that need to be implemented early in the process including storage, identity, security, scaling and more.
As your organization changes from a monolithic architecture to microservices, or you are looking at what this type of change requires, a key component to consider is identity and user management.
This talk will discuss the progression from monolithic identity to microservice based identity. You’ll learn about techniques to make the switch less painful and pitfalls to watch out for during the process.
In this session, you'll learn how to design and develop REST APIs using Spring MVC, leveraging hypermedia to make those APIs easier for clients to consume and OAuth to make them more secure.
TBD
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!
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.
This session covers two critical soft skills for architects:
New architects find soft skills like creating lucid documentation and building compelling presentations challenging. This presentation covers a variety of ways to document ideas in software architecture, ranging from diagramming techniques (that aren't UML) to Architecture Decisions Records and ultimately to presentations. The second part of the talk leverages patterns and anti-patterns from the Presentation Patterns book to help architects build clear and concise representations of their ideas.
Architecture doesn't exist in a vacuum, a painful lesson developers who built logically sound but operationally cumbersome architectures learned. Continuous Delivery is a process for automating the production readiness of your application every time a change occurs–to code, infrastructure, or configuration. Some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery.
Yesterday's best practice is tomorrow's anti-pattern. Architecture doesn't exist in a vacuum, a painful lesson developers who built logically sound but operationally cumbersome architectures learned. Continuous Delivery is a process for automating the production readiness of your application every time a change occurs–to code, infrastructure, or configuration. Some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery. I first set context for the information you must master before delving into the nuances of modern architectural concerns. I discuss the role of metrics to understand code, how Domain Driven Design's Bounded Context reifies in architecture, how to reduce intra-component/service coupling, the tension between coupling and cohesion, microservices architectures, and other engineering techniques.
This workshop allows you to apply techniques either against a sample codebase…or bring one of your own. Suggested exercises include using metrics to learn more about the structure of your class, how to determine how to partition a mono-lithic architecture into a service-based ond, and Architectural Katas with Devops added.
Architecture doesn't exist in a vacuum, a painful lesson developers who built logically sound but operationally cumbersome architectures learned. Continuous Delivery is a process for automating the production readiness of your application every time a change occurs–to code, infrastructure, or configuration. Some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery.
Yesterday's best practice is tomorrow's anti-pattern. Architecture doesn't exist in a vacuum, a painful lesson developers who built logically sound but operationally cumbersome architectures learned. Continuous Delivery is a process for automating the production readiness of your application every time a change occurs–to code, infrastructure, or configuration. Some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery. I first set context for the information you must master before delving into the nuances of modern architectural concerns. I discuss the role of metrics to understand code, how Domain Driven Design's Bounded Context reifies in architecture, how to reduce intra-component/service coupling, the tension between coupling and cohesion, microservices architectures, and other engineering techniques.
This workshop allows you to apply techniques either against a sample codebase…or bring one of your own. Suggested exercises include using metrics to learn more about the structure of your class, how to determine how to partition a mono-lithic architecture into a service-based ond, and Architectural Katas with Devops added.
How do you build an API that isn't obsolete as soon as it goes live? This Lessons from the Field talk will take you on our 8 year journey culminating with the current rollout of api.nfl.com.
From previous generations of the API yields API Design Principles, hints on how to be pragmatic, various technologies tried and technologies currently is use.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Kubernetes Koncepts (1 of 2)
Aha moments with apps in containers can be quite liberating. The mobile space is saturated with “there's an app for that”. For us, we now expect “there's a container for that”. “Write once, run anywhere” (WORA) has changed to “Package once, run anywhere” (PORA). The growing community of containers is riding up the hype curve. We will look at many ways to assemble pods using architecture patterns you already know.
Your software package delivery and installation is no longer an rpm, deb, dmg, jar, war, native executable or a run script, it is simply an image that has a common run container command.
During the presentation, we will explore some examples on Katacoda.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Kubernetes Koncepts
At the 2009 Agile conference, J.B.Rainsberger declared “Integration tests are a scam”. I agree. Come see some compelling reasons why consumer-driven contract testing is a much better approach. Particularly for microservices.
We will explore different testing techniques on Kubernetes, including an important one called “Consumer-Driven Contracts”.
After a brief overview of the concepts a live demonstration will show you how to:
This is the droid you are looking for. Within this droid are hundreds of rules designed to review your code for defects, hotspots and security weaknesses. Consider the resulting analysis as humble feedback from a personal advisor. The rules come from your community of peers, all designed to save your butt.
We will explore techniques on how to add these checks to your IDE, your build scripts and your build pipelines.
Too much chatter in your pull requests? See how the analysis tools teach best practices, without ego or criticism, to a spectrum of developers. As a leader see how to develop an effective code quality intern program around this technique. We will also see some techniques to use Kubernetes to obtain reports and dashboards right on your local machine and from your continuous integration pipeline.
You have some modular code with a REST API. You are on your way to Microservices. Next, you package it in a container image that others can run. Simple. Now what? Your service needs to log information, needs to scale and load balance between its clones. Your service needs environment and metadata way outside its context. What about where the service will run? Who starts it? What monitors its health? What about antifragility? Updates? Networking? Oh my.
Don't get flustered. We will explore how Kubernetes simplifies the complexity of distributed computing.
This session will help you understand the terms, architecture and the mechanics of the Kubernetes tools. You will understand how to target your applications to a seemingly complex distributed compute platform.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Kubernetes Koncepts.
From operating system on bare metal, to virtual machines on hypervisors, to containers orchestration platforms. How we run our code and bundle our applications continues to evolve. Serverless computing continuous our evolutionary path for our architectures.
Kubernetes provides an ideal, vendor-agnostic platform for serverless computing. Serverless promises to developers that we can worry less about the cluster and focus more on their logic. Based on your Kubernetes knowledge we will discover the various contributors of serverless frameworks on Kubernetes. Specifically, we will unpack how two open source serverless frameworks, Kubeless and OpenFaaS, leverage Kubernetes to achieve their promises. We will explore how Knative is helping the serverless providers evolve to the next levels sophistication.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Kubernetes Koncepts.
Kubernetes is a powerful platform for running containers and distributing computation workloads across resources. A significant question is how do you get all your code to this platform, continuously.
In 2019 our community is bursting with new solutions to assist our delivery pipelines. While Jenkins is a dominant player, there is a growing array of new ideas and choices. From coding at your laptop to building containers to deployments, we will explore the various tools and techniques to reduce the delivery frictions.
Kubernetes is also a fitting platform for hosting your continuous tools, pipeline engines, registries, testing, code analysis, security scans, and delivery workflows.
From this session, you will understand the latest tools and techniques for pipelining on Kubernetes. Let's up the game on your Maturity Model.
Prerequisite: If you are unfamiliar with Kubernetes or Istio meshing be sure to attend: Understanding Kubernetes: Fundamentals or Understanding Kubernetes: Meshing Around with Istio.
Kubernetes is a complex container management system. Your application running in containers is also a complex system as it embraces the distributed architecture of highly modular and cohesive services. As these containers run, things may not always behave as smoothly as you hope. Embracing the notions of antifragility and designing a system to be resilient despite the realities of resource limitations, network failures, hardware failures and failed software logic. All of this demands a robust monitoring system to open views into the behaviors and health of your applications running in a cluster.
Three important aspects to observe are log streams, tracing, and metrics.
In this session, we look at some example microservices running in containers on Kubernetes. We add Istio to the cluster for meshing. We observe how logs are gathered, We see transactions are traced and measured between services. We inspect metrics and finally add alerts when metrics are indicating a problem.
At the end of the day, an architect's primary job is to communicate. Not only do we need to make sure our teams understand the design of the system well enough to implement it, we must be able to explain our decisions to an audience that isn't impressed with how many TLAs you can rattle off in one sentence. Successful architects need to seamlessly transition from in depth technical conversations to budget meetings to discussions with end users adjusting the message to fit the audience.
While oral communication is key, good architects also spend a good deal of time putting pixel to screen via email, IM and various architectural documents we're expected to create. We need to write clearly and concisely while also knowing when the best course of action is to pick up the phone or walk to someone's desk.
In this talk, we'll explore the various methods that we as architects use to communicate with our stakeholders. We'll talk about knowing our audience, being able to present as well as how to run a good meeting. We'll discuss various patterns (and antipatterns) of presenting along with some concrete advice on how to do it better. At the end of the day, our job is to tell effectively tell a story - this talk will look at ways to do that.
Flow AI is an emotional intelligence AI platform based on I.flow() theoretical brain models, and is in the very early stages of being developed as a co-operative community effort. Given the inevitable evolution toward generalized AI, what does this mean for our future?
In this group discussion, we'll talk about the implications of the next major scientific revolution in AI, the similarities and differences from scifi movies, the challenges, the risks, and how advancements in AI will change our world.
What type of future do we want? What will it take to build that future? Is there a path to get us from where we are to where we want to be?
Flow AI is an emotional intelligence AI platform based on I.flow() theoretical brain models, and is in the very early stages of being developed as a co-operative community effort. Given the inevitable evolution toward generalized AI, what does this mean for our future?
In this group discussion, we'll talk about the implications of the next major scientific revolution in AI, the similarities and differences from scifi movies, the challenges, the risks, and how advancements in AI will change our world.
What type of future do we want? What will it take to build that future? Is there a path to get us from where we are to where we want to be?
Reactive Programming is receiving quite a bit of attention and for good reasons. It’s a nice logic next step from functional programming. It takes the concept of function composition and lazy evaluations to the next level. It streamlines handling of many critical issues that are architectural in nature: resilience, scale, responsiveness, and messaging.
In this workshop, we will start with a quick introduction to reactive programming. We will then dive into code examples and learn how to create reactive applications. We’ll learn to implement observables, to deal with errors in a graceful manner, learn both synchronous and asynchronous solutions, hot vs. cold observables, and dealing with backpressures.
Attendees will pair up to work on the labs. Please be prepared with the following on your systems:
svn (or git-svn) to access the version control for code examples and labs
Java 1.8
Your favorite IDE/TextEditor
The above are the minimum requirements. The reactive library and any other things needed will be downloaded during the workshop. Should you have any questions, please drop an email to Venkat at venkats@agiledeveloper.com.
Reactive Programming is receiving quite a bit of attention and for good reasons. It’s a nice logic next step from functional programming. It takes the concept of function composition and lazy evaluations to the next level. It streamlines handling of many critical issues that are architectural in nature: resilience, scale, responsiveness, and messaging.
In this workshop, we will start with a quick introduction to reactive programming. We will then dive into code examples and learn how to create reactive applications. We’ll learn to implement observables, to deal with errors in a graceful manner, learn both synchronous and asynchronous solutions, hot vs. cold observables, and dealing with backpressures.
Attendees will pair up to work on the labs. Please be prepared with the following on your systems:
svn (or git-svn) to access the version control for code examples and labs
Java 1.8
Your favorite IDE/TextEditor
The above are the minimum requirements. The reactive library and any other things needed will be downloaded during the workshop. Should you have any questions, please drop an email to Venkat at venkats@agiledeveloper.com.
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.
As a developer, your focus was squarely on the “functional requirements” aka the business capabilities your application must meet. But once you step in the architect role, you discover a world inhabited by “the ilities” otherwise known as the non functional or quality attributes of a software system. But how do we know which ilities matter and which ones don't? And much as we may want to turn every knob up to 11, many ilities are inversely related - maximize one and you by definition minimize another.
In this talk we will look at various architectural problems giving participants opportunities to try and balance non functional requirements. We'll discuss the consequences of various approaches as well as how we can best document the inevitable decisions we arrive at.
This session compares Service-oriented, Service-based, and Micro-service architectures, describing the problem each is designed to solve, differences and similarities, variants and hybrids, and engineering practices.
Microservice architectures are quite popular, described as “SOA done correctly”. But what are the real differences between SOA, Microservice, and service-based architectures? What about middle ground between the shared everything of SOA versus shared nothing of microservices? This talk explores the similarities and differences between various service-oriented architectural styles. I describe the characteristics of SOA, microservices, and hybrid service-based architectures, along with the considerations and constraints for each. I also discuss specific engineering practices, orchestration styles, reuse strategies, and migrating from monolithic applications to service-based or microservice architectures. No one architecture can solve every problem, and many projects take on more complexity than necessary by choosing the wrong paradigm.
An evolutionary architecture supports incremental, guided change along multiple dimensions.
For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.
The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This keynote illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.
Creating new domain objects in a microservice architecture can result in the following quandry: should an existing service be augmented or should a new service be created. When the objects do not fit within existing services, this results in having pico services, many trivial services to support the new domain objects.
Enter GOLD - a GraphQL based open source library that allows for the dynamic specification of domain objects and management of their instances. It is the central component of a single microservice that powered superbowl.com for Superbowl LI. Going foward, the service will power key aspects of both nfl.com and the mobile products.
The GraphQL specification has been gaining traction at incredible speed but the need to define, and then maintain, a separate GraphQL schema can be a substantial barrier to entry. GLiTR is an open source framework developed at the NFL with the express purpose to help us bridge this gap.
With GLiTR, it is now possible to build a GraphQL schema directly off of the existing domain POJOs prevalent in Java programming thereby leveraging existing code and greatly reducing the development time needed to get started with GraphQL.
Should Information Management systems apply the services architecture? Many data provisioning and BI systems are monolithic, tightly coupled, difficult to scale, and stumble when it comes to delivering MVP in a timely manner.
In this session we will look at the common obstacles such systems inherently bring with them, and how the Data as a Service architecture pattern addresses many of these issues.
Agenda
Data as a Service delivers MVP of real-time data management, while avoiding many of the anit-patterns that traditional data provisioning and BI systems portray. However, building out a Data as a Service system doesn't require high up-front costs and the welding of multiple products. Learn how the open source product Talend Open Studio can be used to build out a DaaS system that delivers faster and more scalable solutions to your customer.
In this session we will look a close look at the key components of the Data as a Service architecture pattern by walking through an example implemented using Talend.
Agenda
Normally simple tasks like running a program or storing and retrieving data become much more complicated when we start to do them on collections of computers, rather than single machines. Distributed systems has become a key architectural concern, and affects everything a program would normally do—giving us enormous power, but at the cost of increased complexity as well.
Using a series of examples all set in a coffee shop, we’ll explore topics like distributed storage, computation, timing, messaging, and consensus. You'll leave with a good grasp of each of these problems, and a solid understanding of the ecosystem of open-source tools in the space.
We all have an innate sense of what's possible. Not only is this how magicians fool you, but it might also be what's holding you back.
In this session Michael Carducci shares how he applied lessons learned in his career as a professional magician to his “day-job” as a software engineer.
Magicians have a simple process for creating new material; think of the most impossible thing you can imagine, the engineer a way to make it possible. Michael has been engineering solutions to “impossible” problems for nearly 20 years and this has given him a unique perspective on dealing with challenges in all aspects of his life.
This talk combines illusion, anecdotes and real-world examples to help identify and overcome your mental obstacles.
It happens to us all; there are simply days where it seems impossible to get anything done. This session focuses on techniques and tips to get into the zone, stay in the zone and to protect your productivity, even in disruptive environments.
Rather than focusing on any one productivity methodology (e.g. GTD) This talk analyzes the internal and external factors that affect our productivity and offers broader strategies to get back on track.
A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.
ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.
A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.
ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.
The toolset for building scalable data systems is maturing, having adapted well to our decades-old paradigm of update-in-place databases. We ingest events, we store them in high-volume OLTP databases, and we have new OLAP systems to analyze them at scale—even if the size of our operation requires us to grow to dozens or hundreds of servers in the distributed system. But something feels a little dated about the store-and-analyze paradigm, as if we are missing a new architectural insight that might more efficiently distribute the work of storing and computing the events that happen to our software. That new paradigm is stream processing.
In this workshop, we’ll learn the basics of Kafka as a messaging system, learning the core concepts of topic, producer, consumer, and broker. We’ll look at how topics are partitioned among brokers and see the simple Java APIs for getting data in and out. But more than that, we’ll look at how we can extend this scalable messaging system into a streaming data processing system—one that offers significant advantages in scalability and deployment agility, while locating computation in your data pipeline in precisely the places it belongs: in your microservices and applications, and out of costly, high-density systems.
Come to this workshop to learn how to do streaming data computation with Apache Kafka!
The toolset for building scalable data systems is maturing, having adapted well to our decades-old paradigm of update-in-place databases. We ingest events, we store them in high-volume OLTP databases, and we have new OLAP systems to analyze them at scale—even if the size of our operation requires us to grow to dozens or hundreds of servers in the distributed system. But something feels a little dated about the store-and-analyze paradigm, as if we are missing a new architectural insight that might more efficiently distribute the work of storing and computing the events that happen to our software. That new paradigm is stream processing.
In this workshop, we’ll learn the basics of Kafka as a messaging system, learning the core concepts of topic, producer, consumer, and broker. We’ll look at how topics are partitioned among brokers and see the simple Java APIs for getting data in and out. But more than that, we’ll look at how we can extend this scalable messaging system into a streaming data processing system—one that offers significant advantages in scalability and deployment agility, while locating computation in your data pipeline in precisely the places it belongs: in your microservices and applications, and out of costly, high-density systems.
Come to this workshop to learn how to do streaming data computation with Apache Kafka!
Software architecture involves inherent trade-offs. Some of these trade-offs are clear, such as performance versus security or availability versus consistency, while others are more subtle, like resiliency versus affordability. This presentation will discuss various architectural trade-offs and strategies for managing them.
The role of a technical lead or software architect is to design software that fulfills the stakeholders' vision. However, as the design progresses, conflicting requirements often arise, affecting the candidate architecture. Resolving these conflicts typically involves making architectural trade-offs (e.g. service granularity vs maintainability). Additionally, with time-to-market pressures and the need to do more with less, adopting comprehensive frameworks like TOGAF or lengthy processes like ATAM may not be feasible. Therefore, it is crucial to deeply understand these architectural trade-offs and employ lightweight resolution techniques. Prezi Presentation
No matter the techniques used to make enterprise solutions Highly Available (HA), failure is inevitable at some point. Resiliency refers to how quickly a system reacts to and recovers from such failures. This presentation discusses various architectural resiliency techniques and patterns that help increase Mean Time to Failure (MTTF), also known as Fault Tolerance, and decrease Mean Time to Recovery (MTTR).
Failure of Highly Available (HA) enterprise solutions is inevitable. However, in today's highly interconnected global economy, uptime is crucial. The impact of downtime is amplified when considering Service Level Agreement (SLA) penalties and lost revenue. Even more damaging is the harm to an organization's reputation as frustrated customers express their grievances on social media. Resiliency, often overlooked in favor of availability, is essential. Prezi Presentation
We constantly hear that change should be affordable and cost effective. True, but, in reality, that's easily said than done. Complexity makes change hard. We can't shy away from the hard problems posed by domains and business needs. So, how can we solve complicated problems without getting dragged into the quagmire of what appears to be an inevitable complexity? In this keynote, an award winning author and software practitioner will share experiences and observations from working on multiple software projects, about what leads to complexities, the traps developers and organizations fall into, and what we can do to effectively deal with these common, recurring issues we see across domains and products.
.
This session will focus on the essential skills that are needed by software architects on a daily basis from ideation to product delivery. For many architects, it’s not the technology related areas that give you problems, but people related areas.
Come to this session if you want to learn some tricks and tips for how to raise your game as an architect.
Too often, developers drill into the see of data related to a software system manually armed with only rudimentary techniques and tool support. This approach does not scale for understanding larger pieces and it should not perpetuate.
Software is not text. Software is data. Once you see it like that, you will want tools to deal with it.
Developers are data scientists. Or at least, they should be.
50% of the development time is typically spent on figuring out the system in order to figure out what to do next. In other words, software engineering is primarily a decision making business. Add to that the fact that often systems contain millions of lines of code and even more data, and you get an environment in which decisions have to be made quickly about lots of ever moving data.
Yet, too often, developers drill into the see of data manually with only rudimentary tool support. Yes, rudimentary. The syntax highlighting and basic code navigation are nice, but they only count when looking into fine details. This approach does not scale for understanding larger pieces and it should not perpetuate.
This might sound as if it is not for everyone, but consider this: when a developer sets out to figure out something in a database with million rows, she will write a query first; yet, when the same developer sets out to figure out something in a system with a million lines of code, she will start reading. Why are these similar problems approached so differently: one time tool-based and one time through manual inspection? And if reading is such a great tool, why do we even consider queries at all? The root problem does not come from the basic skills. They exist already. The main problem is the perception of what software engineering is, and of what engineering tools should be made of.
In this talk, we show live examples of how software engineering decisions can be made quickly and accurately by building custom analysis tools that enable browsing, visualizing or measuring code and data. Once this door is open you will notice how software development changes. Dramatically.
It has been a while since you left the easy days of batch processing behind: the lazy ETL jobs that had all night to run, the relaxed SLAs that let you take lunches like Don Draper, the languid bankers’ hours: the salad days of your data processing career. Those days are over now, and producing real-time results on streaming data is the new order of the day. Two seconds is the new overnight.
Apache Kafka is a de facto standard streaming data processing platform, being widely deployed as a messaging system, and having a robust data integration framework (Kafka Connect) and stream processing API (Kafka Streams) to meet the needs that common attend real-time message processing.
On top of that, Kafka now offers ksqlDB, a declarative, SQL-like stream processing language. What once took some moderately sophisticated Java code can now be done at the command line with a familiar and eminently approachable syntax. Come to this talk for an updates on the latest ksqlDB features with live coding on live streaming data.
Your goal is simple: take that is happening in your company—every click, every database change, every application log—and made it all available as a real-time stream of well-structured data? No big deal! You’re just taking your decades-old, batch-oriented data integration and data processing and migrating to to real-time streams and real-time processing. In your shop, you call that Tuesday. But of the several challenges to tackle, you’ll have to get data in and out of that stream processing system, and there’s a whole bunch of code there you don’t want to write. This is where Kafka Connect comes in.
Connect is a standard part of Apache Kafka that provides a scalable, fault-tolerant way to stream data between Kafka and other systems. It provides an API for developing standard connectors for common data sources and sinks, giving you the ability to ingest database changes, write streams to tables, store archives in HDFS, and more. We’ll explore the standard connector implementations offered in the Confluent Open Source download, and look at a few operational questions as well. Come to this session to get connected to Kafka!
As the cloud becomes more popular, many cloud-inexperienced architects wonder whether migration to the cloud is the correct way to scale. When they decide to migrate they have to figure out where to start from and which components to use. This talk is not about a particular cloud vendor but the questions and considerations to take while deciding on a cloud architecture for your business.
After deciding to migrate to the cloud, the architecture design will determine the success rate of the infrastructure. This architecture needs to be robust and well thought of to ensure that it handles all the requirements at hand and flexible enough for the future.
This talk is about considerations to take while designing a system, including:
The intended clients
Investment decisions
The business strategy
The development team
Choice of tools
Good development practices
Here we also discuss common pitfalls of the architecture design process, including choosing tools.
When we have a problem which can be solved using a software, we first design an architecture that will guide how the system will look like. This architecture needs to be robust and well thought of to ensure that it handles all the requirements at hand and flexible enough for the future.
This talk is about some considerations to take while designing a system:
The problem to be solved
The users of the system
Systems integrations
The talk also highlights some common pitfalls that teams fall into during this process:
Database management
Buzzword-oriented architecture
Outcome of the talk:
By the end of this session the listener is be able to:
Interpret the most important considerations while designing a system
Evaluate the business and customer requirements to determine their architecture
Analyse past organisation strengths and shortcomings to make better decisions
Think back over your career as a software developer. How many great–and I mean truly great–software developers have you worked with? The chances are you can count them on one hand? Developers with 20-30 years experience can rarely name more than two or three. What does it take to be considered truly great? Michael can certainly tell you what NOT to do… from cold, bitter experience.
Ego Driven Development is a humorous and brutally honest look at a career spanning nearly two decades. We dive into war stories, train wrecks and so many misguided attempts at greatness. There is a path to becoming a truly great software engineer, but it's not always where we first look.
Deploying simple serverless applications using AWS Lambda is getting easier every day, but for software architects dealing with complex systems, Lambda’s constrained execution environment seems to put it out of consideration, especially when combined with organizational technology choices like Java.
John explores AWS Lambda in depth, covering the Lambda execution environment, Lambda’s Java runtime characteristics and best practices for Java-based Lambdas, and techniques for effectively using services like Cloudwatch, DynamoDB, and Kinesis with Lambdas. Some techniques will be supported by live demos. You’ll come away with a set of best practices that will enable you to effectively architect and operate serverless applications that include Java-based Lambdas.
Serverless is the hot new way to develop applications in the cloud. At the core of a Serverless Architecture is Functions-as-a-Service, also known as Serverless Compute - small, lightweight, operations that you deploy simply as code snippets, and let your vendor platform do the work of operating. The most popular implementation of Serverless Compute is AWS Lambda.
This session will teach you how to develop applications using AWS Lambda functions implemented in Java. You don’t need any prior AWS experience, Lambda or otherwise. We start from first principles, and explain what is going on in the Lambda environment as we proceed. After this session you’ll be able to:
• Setup a development environment ready for working with AWS Lambda
• Develop, deploy and test Java Lambdas
• Make decisions about how to configure your Lambdas
• Understand the programming model that Lambda gives you
• Be able to decide what libraries you may or may not want to include
• Setup clean logging and monitoring
• Integrate Lambda with AWS API Gateway to build Java-backed Serverless web services.
One of the most compelling Serverless architectures doesn’t need to involve AWS Lambda at all. Amazon’s Simple Storage Service, or S3, is a great option for hosting a website or other static content. However, the naive approach to S3 static content hosting doesn’t account for concerns like custom domains, edge caching, transport encryption (SSL), backups, stale file deletion, and disaster recovery.
In this talk, Symphonia’s John Chapin gives an overview and demonstration of a fully-automated, CloudFormation-based static website stack that incorporates a custom domain name using Route53, SSL using Amazon Certificate Manager, cross-region replication, S3 object versioning and deletion, and edge caching using CloudFront. Common patterns for deployment and idiosyncrasies of the approach will also be covered.
Over the last 20 years we’ve seen the lead time for delivering software decrease from years to weeks. Now we see an opportunity to reduce this further to days or even hours. This enables us to think about how we approach product development in a new way - one of 'Continuous Experimentation'. What advantages would doing this bring? What challenges would we face in doing this, and how would we surmount them? These are the questions that Mike Roberts addresses in this talk.
Serverless is a new technological approach to architecture and deployment. While cost benefits are one of the drivers of Serverless, its most interesting advantage is reducing ‘conception-to-production lead time’. Serverless does this by reducing the amount of code we need to write; by simplifying the deployment and operations of applications; and by minimizing the cost commitment of creating infrastructure.
Modern Agile (http://modernagile.org/) is a new take on ‘agile development’ as it was originally considered, and brings it up to date with conceptually aligned ideas - Lean Startup, Continuous Delivery and DevOps. Modern Agile is defined, simply, by four guiding principles: make people awesome; make safety a prerequisite; experiment and learn rapidly; and deliver value continuously.
Mike drills into the benefits that the combination of Serverless, Modern Agile, and a few other ideas can bring to accelerating how we work. Through this he shows how Continuous Experimentation might just be the next big change in the way we deliver software.
Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world – the clash of top-down control, money, and economics, versus art, freedom, working with our friends, and bringing awesome creations to life.
Overcoming these challenges in our industry requires a huge paradigm shift – rather than building organizations as money-making machines with top-down control, our organizations need to become thinking, feeling, interconnected social organisms, where our humanity isn't boiled down to a few numbers.
How do we shift the paradigm of the organization, to bridge these two worlds together? The short answer – with the help of software.
By measuring the friction in a developer's Flow, we have a data-driven feedback loop for personal improvement. What if we measure Flow across the team? Across team dependencies? Across the organization?
What would it take to build an organizational operating system, that uses our past experience and lessons learned as the foundation for an intelligent hive mind, that helps everyone in the organization make better decisions? What if we codified our organizational ideals into the business accounting rules of the software, then sold it as the “the next big thing” in the industry?
At the end of the day, business is a game. If we take responsibility for making up the rules, we can redefine the game we wish to play. In this session, we'll discuss a potential future for our industry, where we design the organizational operating system that runs the world.
If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.
In this talk, I will explore what criteria we should consider when comparing technologies, how we can avoid burning platforms as well as what to do when we’ve reached a dead end. We will also apply these techniques to a current technology or two.
Good architects are, almost by definition, good story tellers. And while good communication skills are vital to success as an architect, so too is an ability to constructively critique an architecture. In this talk, we'll explore why reviews are important and what it takes to perform them well. Additionally, we'll talk about the importance of planning and preparation in conducting a successful review.
Good architects are, almost by definition, good story tellers. And while good communication skills are vital to success as an architect, so too is an ability to constructively critique an architecture. In this talk, we'll explore why reviews are important and what it takes to perform them well. Additionally, we'll talk about the importance of planning and preparation in conducting a successful review.