Four days of deep, practitioner-led technical sessions — agentic AI, architecture patterns, security, cloud, and the craft of being an architect. No fluff, no vendor pitches.
Cloud-native architectures combine the unique aspects of cloud platforms with the principles of DevOps and Continuous Delivery to enable the rapid development, deployment, and management of applications. As the speed of innovation becomes one of the key drivers of business success, these architectures ensure teams are able to meet the need of the business, to move quickly, while at the same time ensuring important non-functional characteristics like availability and scalability.
Many of the innovators in this space, including Amazon, Twitter, LinkedIn, and Netflix, leverage small, autonomous teams which focus on business capabilities and build twelve-factor style, microservice applications. Microservices integration is achieved via lightweight, decentralized, and choreographed point-to-point interactions rather than the heavyweight, centralized, and orchestrated ESB-style integration found in traditional SOA.
With the advent of cloud-native architectures, building distributed systems will become increasingly common for the enterprise Java developer. Fortunately many of these same innovators have embraced the JVM as they’ve built increasingly complex systems, with Netflix open-sourcing much of its toolkit for constructing these systems at NetflixOSS.
Cloud Foundry and Spring provide open source framework tooling and platform services for developers to quickly build some of the common patterns in found in distributed, cloud-native systems. Many of these patterns are provided by the Spring Cloud project, which wraps many of the battle-tested components found at NetflixOSS with the Spring programming model, and provides easy deployment of NetflixOSS services to Cloud Foundry.
In this class the learner will have the opportunity to practice working with cloud-native architectures using Spring and Cloud Foundry.
To be successful, you'll need certain prerequisite tools installed on the laptops that you'll be bringing to the session:
Java 8 JDK (not just JRE)
Install the Spring Boot CLI, version 1.4.1.RELEASE. Choose an installation method from the Spring Boot reference docs.
Once you have installed the Spring Boot CLI, ensure that it is on your execution path with the following command:
$ spring --version
Spring CLI v1.4.1.RELEASE
Assuming that this command works and you see the correct version, install the Spring Cloud CLI plugin using the following command:
$ spring install org.springframework.cloud:spring-cloud-cli:1.2.1.RELEASE
Installing into: /Users/mstine/.sdkman/candidates/springboot/1.4.1.RELEASE/lib/ext
Resolving dependencies...
You should see similar output, but the installation location will depend on the method you chose to install the Spring Boot CLI. The output above is based on an SDKMAN!-based installation.
Git (latest)
Cloud Foundry Client (latest)
ngrok (latest)
You'll need a free GitHub account. If you don't already have one, create one here.
Also, you'll need to create a Pivotal Web Services account here.
Pivotal Web Services is a hosted instance of Cloud Foundry that is operated by Pivotal.
You will likely find your favorite Java IDE helpful for things like auto-importing packages and classes. Spring Tool Suite, Eclipse, or IntelliJ IDEA are all perfectly valid choices!
New architectural paradigms are emerging that challenge traditional assumptions about the way that scalable and adaptable software is built. At the heart of these paradigms is a modular approach that breaks apart the monolithic application. But breaking apart the monolith has implications beyond software architecture and never before has architecture, infrastructure, and methodology been linked in a way that demands a new approach to software development.
In this workshop, we will explore modularity’s role in a large scale software technology agnostic architecture. We’ll compare and contrast different implementation technologies, including Dropwizard and OSGi, for building modular architectures. And we’ll discover the impact that modern architecture has on infrastructure and methodology. Throughout the discussion, we will examine how modern web and mobile apps fit into this overall architectural story. This session is a workshop and hands on labs are available, so bring your laptop if you’d like to perform the exercises.
The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren’t there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it’s a fast moving discipline, where entire suites of best practices become obsolete overnight. This workshop provides the fundamentals to transition from developer to architect, or to help “accidental” architects.
Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, and soft skills. While we can’t make you an architect overnight, we can start you on the journey with a map and a good compass.
Part 1, From Developer to Architect, covers:
Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including evaluating architectures via Agile ATAM, the impacts of continuous delivery on architecture, comparing architectures, SOA, SOAP, and REST, integration hubs, and enterprise architecture approaches and strategies.
Part 2, Deeper Dive, covers:
To fully leverage knowledge, you need application. The last part of this workshop uses the public domain Architectural Katas exercise to apply learnings from the first two parts.
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.
Hypothesis and data driven development ties together current thinking about requirements, Continuous Delivery, DevOps, modern architecture, and engineering techniques to help rethink building software.
Agile development claims to abhor “Big Design Up Front”…yet what is that giant backlog building session but BDUF in other clothing? Back in the olden days of software development, we were forced to speculate on what users want, then build it. We were basically running a buffet. But what if we could switch to à la carte? With modern engineering practices like Continuous Delivery, we can shift our perspective and start building by hypothesis rather than speculation. This talk shows the full spectrum of software development, from ideation through execution and deployment, through the lens of modern software engineering practices. I discuss building a platform using feature toggles, canary releases, A/B testing, and other modern DevOps tools to allow you to run experiments to see what your users really want. By building a platform for experimentation, product development shifts from up-front guessing to market driven. This talk unifies the practices of modern architecture, DevOps, and Continuous Delivery to provide a new approach to feature development. This talk also demonstrates how to undertake major architectural restructuring with zero regression failures by relying on data and the scientific method.
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.
Being a software architect is a tough job. Not only do you have to have significant technical depth and breadth, but you also need to understand the business domain you are working in. While these aspects are important, there is another perhaps more vital aspect of being an architect - the soft skills. Too many architects fail to realize the importance of soft skills, and as a result do not achieve success in their career as an architect. In this two-part session I will focus on the soft skills of architecture. In part one I will cover skills related to techniques such as architecture decisions, architecture refactoring, and communicating your software architecture through diagrams, documentation, and presentation.
Agenda:
Being a software architect is a tough job. Not only do you have to have significant technical depth and breadth, but you also need to understand the business domain you are working in. While these aspects are important, there is another perhaps more vital aspect of being an architect - the soft skills. Too many architects fail to realize the importance of soft skills, and as a result do not achieve success in their career as an architect. In this two-part session I will focus on the soft skills of architecture. In part two I will cover the people skills side of architecture, including working in architecture teams, making implementation teams effective, negotiation techniques, and leadership skills.
Agenda:
This session will focus on the soft skills that are needed by software architects and pretty much any technical person. One of the chief things that changes when you go from being a tech lead to an architect is the need for soft skills. For many architects, it’s not the technology related areas that give you problems, but people related areas – at least this was the case for case for me.
Come to this session if you want to learn some tricks and tips for how to better interact others – especially executives.
This session will focus on the technical skills that are needed by software architects. The role of an architect is not always clear – we often get referred to as glue – because we fill in wherever we are needed.
If you are wondering what an architect should be doing – this presentation will give tips and tricks for being an architect from ideation through product delivery.
In this 2 part session (each part 1.5 hours), I will deep dive into the deployment architectures of large scale Java platforms. I will first set the context of the discussion around what problems exist in our industry before I proceed to lay out the concept of platform engineering and its renaissance among the developer/deployment community today. It is astonishing to see that majority of new application platforms being rolled out today miss their SLA, and 90% of these systems require 2X more hardware than what they actually need in order to run. This is an industry suffering from a double whammy, where you spend 2X on hardware and still miss your SLA; clearly something is completely broken. Now prior to delving into these new concepts, such as Microservices, Cloud Native, 3rd Platform, & 12Factor App, it is imperative to first understand the problem at hand before we apply these deployment architectural patterns. I will layout the definition of Platform Engineering as the software engineering science needed in order to understand how to precisely deploy application components onto application runtimes and how in-turn one should appropriately map the application runtimes onto the infrastructure that it needs. With this knowledge you should be able to more effectively decide when to scale-out (by how many instances), and when to scale-up.
We will conclude with covering various GC tuning techniques, and how to best build platform engineered systems; in particular, the focus will be on tuning large scale JVM deployments and various sizing techniques. While predominantly most enterprise class Java workloads can fit into a scaled-out set of JVM instances of less than 4GB JVM heap, there are workloads in the in memory database space that require fairly large JVMs. We will look at various Java platform scales, some holding a few large JVMs of 90GB heap space – servicing large multi-terabyte in memory DBs, while other platforms are of thousands of JVM instances of less than 4GB heap space on each, typical of web-app deployments. We will also take a close look at an example XYZCars.com, where a microservices approach was designed and deployed. The discussion will cover how to more correctly deploy microservices, without causing fragmentation of scale, and hence without impeding performance. In this session, we take a deep dive into the issues and the optimal tuning configurations for tuning large JVMs in the range of 4GB to 360GB, using the GC tuning recipes that were gained over the past 15 years of GC tuning engagements. You should be able to walk away with the ability to commence a decent GC tuning exercise on your own, and your way to platform engineer your application runtimes to feasibly meet your SLAs.
In this 2 part session (each part 1.5 hours), I will deep dive into the deployment architectures of large scale Java platforms. I will first set the context of the discussion around what problems exist in our industry before I proceed to lay out the concept of platform engineering and its renaissance among the developer/deployment community today. It is astonishing to see that majority of new application platforms being rolled out today miss their SLA, and 90% of these systems require 2X more hardware than what they actually need in order to run. This is an industry suffering from a double whammy, where you spend 2X on hardware and still miss your SLA; clearly something is completely broken. Now prior to delving into these new concepts, such as Microservices, Cloud Native, 3rd Platform, & 12Factor App, it is imperative to first understand the problem at hand before we apply these deployment architectural patterns. I will layout the definition of Platform Engineering as the software engineering science needed in order to understand how to precisely deploy application components onto application runtimes and how in-turn one should appropriately map the application runtimes onto the infrastructure that it needs. With this knowledge you should be able to more effectively decide when to scale-out (by how many instances), and when to scale-up.
We will conclude with covering various GC tuning techniques, and how to best build platform engineered systems; in particular, the focus will be on tuning large scale JVM deployments and various sizing techniques. While predominantly most enterprise class Java workloads can fit into a scaled-out set of JVM instances of less than 4GB JVM heap, there are workloads in the in memory database space that require fairly large JVMs. We will look at various Java platform scales, some holding a few large JVMs of 90GB heap space – servicing large multi-terabyte in memory DBs, while other platforms are of thousands of JVM instances of less than 4GB heap space on each, typical of web-app deployments. We will also take a close look at an example XYZCars.com, where a microservices approach was designed and deployed. The discussion will cover how to more correctly deploy microservices, without causing fragmentation of scale, and hence without impeding performance. In this session, we take a deep dive into the issues and the optimal tuning configurations for tuning large JVMs in the range of 4GB to 360GB, using the GC tuning recipes that were gained over the past 15 years of GC tuning engagements. You should be able to walk away with the ability to commence a decent GC tuning exercise on your own, and your way to platform engineer your application runtimes to feasibly meet your SLAs.
HotSpot provides a variety of garbage collectors with a variety of strengths and weaknesses. To get the most out of our applications, we need to pick the right garbage collector and design to take advantage of its strengths and avoid its
weaknesses.
In this presentation, you'll learn about criteria for picking a garbage collector, how to measure GC performance, and how to write code that works with rather than against the GC.
As we move toward microservices, we learn to properly decompose not only our behavior model, but also our data model into bounded contexts. This data decomposition is not without consequences. By placing strict boundaries around ownership of domain concepts, we make it more difficult to refer to concepts that naturally want to cross these boundaries. How do we “denormalize” these entities effectively? How do we keep these representations in sync? What do transactions look like? How do we ask BIG questions that span multiple contexts? These are the questions that we’ll dive into in this session.
Topics to include:
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.
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.
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.
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!
While microservices may be smaller than some of their architectural cousins, that doesn’t mean that testing the internal components of a microservice takes a back seat.
In this presentation we’ll walk through the test-driven workflows that you can use to build a well-factored microservice.
Much is said about the decentralized governance of and local autonomy given to “two pizza teams” build microservices. But how do you organize teams to effectively collaborate to build the eventual composite system?
In this presentation we’ll examine how to apply the Tracer Bullet Development methodology described in Ship It! to effectively construct distributed systems composed of microservices.
Embracing microservices also means embracing distributed systems. Distributed systems carry with them multiple challenges. One set of challenges includes problem of visibility into the behavior of the composite system, understanding that behavior, and being able to isolate the cause(s) of problematic behavior. These challenges can be addressed by applying the techniques known collectively as Distributed Tracing.
In this presentation, we’ll examine the theory of distributed tracing put forth in Google’s Dapper paper, and we’ll look at how this theory is put into practice in the design of Zipkin, an OSS distributed tracing platform.
Many of us would love to embrace microservices in our day-to-day work. But most of us don’t have the opportunity to start over with a pure greenfield effort. We have to understand how to refactor our existing monolithic applications toward microservices. Practical steps include building new features as microservices, leveraging anti-corruption layers, strangling the monolith.
In this presentation we’ll go light on the theory and walk through the actual process of turning a strawman monolith into a family of well-factored microservices.
HotSpot provides a variety of garbage collectors with a variety of strengths and weaknesses. To get the most out of our applications, we need to pick the right garbage collector and design to take advantage of its strengths and avoid its
weaknesses.
In this presentation, you'll learn about criteria for picking a garbage collector, how to measure GC performance, and how to write code that works with rather than against the GC.
Early releases of Java performed poorly, but those issues largely disappeared long ago with the introduction of HotSpot. However, much of the performance advice for Java persists through hearsay from those early days.
In this talk, we'll forget the hearsay and take an objective look using benchmarking and profiling tools to find out which optimizations matter today and just as importantly those that don't.
As Tech Leaders, we are presented with problems and work to find a way to solve them, usually through technology. In my opinion this is what makes this industry so much fun. Let's face it - we all love challenges. Sometimes, however, the problems we have to solve are hard - really hard. So how do you go about solving really hard problems? That's what this session is about - Heuristics, the art of problem solving. In this session you will learn how to approach problems and also learn techniques for solving them effectively. So put on your thinking cap and get ready to solve some easy, fun, and hard problems.
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:
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.
“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.
Server-side JavaScript is everywhere these days! This session explores some practical architectural techniques and tools that can make your server-side JS easier to develop, test, manage and deploy.
Server-side JavaScript is part of almost every modern web app's tech stack. It is a powerful, versatile tool you can leverage to solve virtually every problem you can image. Its versatility and popularity guarantees that, once introduced to your organization, you will soon have a plethora of server-side JS applications to manage. This poses a number of problems for an enterprise architect: How do I maximize reuse across projects? How do I even enable reuse in JS? Are there best practices I should follow? How do I manager 3rd party libraries? Are there coding practices, patterns or standards I should adopt and champion across my teams? What about name spacing concerns? What about packaging and deployment? What if I write libraries for use on both client and server? What tools are available to help you address some of these concerns?
Join us as we explore these and other JavaScript server-side architecture conundrums.
There is no doubt that Angular is now mainstream. That made it easier for you to convince the powers-that-be to let you select Angular for your project. You've done a small but successful POC and now your 'big' project has been green lighted to kick off next month. Your team is jazzed but as you start to plan out the real work, you begin to realize that there are many aspects inherrent to large Angular projects that have no 'out of the box' answers.
Stack overflow can only contribute 'it depends' answers that leave you more confused than before you read them. And now the panic starts to seep in, killing your buzz. Never fear! In this session, we will explore a variety of ways to architect your project and structure your code. We will look at the pros and cons of each option and discuss when trigger points for choosing each.
We've got some seriously big problems in our industry. Under constant business pressure, our organization's drive one project after another into the ground. Once the chaos and fire-fighting finally gets out of control, we rewrite our software… again. How long are we going to wait for somebody else to solve this problem?!
It's about time we took responsibility. OpenDX is a strategy to kick this problem's ass. How? By measuring the pain, and putting the ridiculous costs and risks on center stage for everyone to see, then working together to figure it out.
In this talk, we'll get into the weeds of #OpenDX, a specification for data collection in software development for universally measuring the “pain” or “friction” in developer experience.
Visibility changes everything. Once we can measure the pain, explain the costs and risks, and get managers and developers all pulling the same direction, suddenly we can start optimizing our organization's with a data-driven feedback loop.
OpenDX is about making healthy software projects the new norm in our industry. Status quo – You better watch out.
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.
“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.
Our technical world is governed by facts. In this world Excel files and technical diagrams are everywhere, and too often this way of looking at the world makes us forget that the goal of our job is to produce value, not to fulfill specifications.
Feedback is the central source of agile value. The most effective way to obtain feedback from stakeholders is a demo. Good demos engage. They materialize your ideas and put energies in motion. They spark the imagination and uncover hidden assumptions. They make feedback flow.
But, if a demo is the means to value, shouldn’t preparing the demo be a significant concern? Should it not be part of the definition of done?
That is not even all. A good demo tells a story about the system. This means that you have to make the system tell that story. Not a user story full of facts. A story that makes users want to use the system. That tiny concern can change the way you build your system. Many things go well when demos come out right.
Demoing is a skill, and like any skill, it can be trained. Regardless of the subject, there always is an exciting demo lurking underneath. It just takes you to find it. And to do it.
In this session we will get to exercise that skill.
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
How do we define identity in a distributed software system? How do we manage it securely? How do we make identity assertions and verify those claims?
Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Identity and how it cross-cuts the distributed systems we are building.
We will focus on a variety of technologies and standards that help us make, identify, claim and verify identities.
Authenticated Identities are the first step to establish Privilege. Most systems fail to have sufficiently, deeply entrenched notion of how to apply and minimize privilege to avoid data and systems from being abused.
Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Privilege and how it cross-cuts the distributed systems we are building.
This talk will focus on the Valet Key problem and how to avoid it. We will visit various standards and technologies that help us strengthen our security profiles by reducing our dependence on open-ended and unfettered access to our systems and data.
Data integration costs are well beyond what they should be for such a crucial business function. The good news is that they needn't be. By relying on integration-friendly standards and technologies that were designed to support sharing information, we can reduce these costs while increasing our business capabilities.
Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Integration and how it cross-cuts the distributed systems we are building.
We will look at how the REST Architectural style leads us to integration-friendly standards such as RDF, Linked Data, SPARQL and JSON-LD. These technologies are useful both within our firewalls and with third party partners.
Our biological world changes gracefully. Our information world changes much less so. How can we embrace the inevitable technological, procedural and schematic flux that we know is going to visit upon us at some point?
Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Evolution and how it cross-cuts the distributed systems we are building.
We will focus on strategies from the Web standards space to define information systems that embrace change and handle it with relative ease.
This will include strategies for dealing with changing technologies, changing schemas and more.
Information conveys value as it travels around our systems, resting for a time in our data stores. The value we get out of it is sometimes matched by the value others would get from it as well. We need mechanisms to protect sensitive information from prying eyes and control with whom we share it.
Technologies don't magically become solutions. They are used within domain, design and deployment contexts. This talk will focus on the singular notion of Secrecy and how it cross-cuts the distributed systems we are building.
This talk will focus on strategies from the world of encryption to keep secrets secret as we produce, store and transfer information in distributed systems. A successful strategy for doing so will rely on notions of Identity and a strong Privilege model, but we will mostly focus on specific building blocks upon which we maintain Privacy and Confidentiality.
We will also address the forces that undermine our ability to trust encryption such as bugs, design flaws and those who wish to actively undermine our need to maintain Secrecy.
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.
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.
Inspired by success stories from companies such as Amazon and Netflix, many organizations are moving towards microservice architectures at a brisk pace. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.
Microservice architecture is important because it’s the first architecture to fully embrace the Continuous Delivery and DevOps revolutions. In this session, I cover the motivations for building a microservice architecture (including making the distinction between “regular SOA” and microservices), some considerations you must make before starting (such as transactions versus eventual consistency), how to determine service partition boundaries, and ten tips to dowse you towards success. I also discuss the role of polyglot development, enterprise governance, how data and databases fit into this new world, and tooling to help ensure consistency between core services like logging and monitoring. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.
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
Traditional approaches to software architecture are broken. Attempts to define the architectural vision for a system early in the development lifecycle do not work. In today’s volatile technology and business climate, big architecture up front is not sustainable. In this session, we will explore several principles that help us create more flexible and adaptable software systems. But first, we’ll expose the true essence of what’s meant when we say “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.
Microservices are all the rage. But this isn’t a session on microservices. It’s a session on 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’ll refactor a monolith using patterns of modular architecture. In the end, you’ll see how the underlying set of principles used to modularize the monolith are virtually identical to the benefits of a microservice architecture, albeit manifest in a different way. Once modularized, you’ll also be amazed at how much architectural agility we have in our ability to now shift between different approaches to modularity, including microservices.
The surge of interest in the REpresentational State Transfer (REST) architectural style, the Semantic Web, and Linked Data has resulted in the development of innovative, flexible, and powerful systems that embrace one or more of these compatible technologies. However, most developers, architects, Information Technology managers, and platform owners have only been exposed to the basics of resource-oriented architectures.
This talk, based upon Brian Sletten's book of the same name, is an attempt to catalog and elucidate several reusable solutions that have been seen in the wild in the now increasingly familiar “patterns” style. These are not turn key implementations, but rather, useful strategies for solving certain problems in the development of modern, resource-oriented systems, both on the public Web and within an organization's firewalls.
New architectural paradigms are emerging that challenge traditional assumptions about the way that scalable and adaptable software is built. At the heart of these paradigms is a modular approach that breaks apart the monolithic application into microservices. But breaking apart the monolith has implications beyond software architecture and microservices are just one implementation alternative.
In this session, we will explore modularity’s fundamental role in a large scale software architecture. We’ll compare and contrast different implementation technologies for building modular architectures. And we’ll discover the impact that modern architecture has on infrastructure and methodology. Finally, we will examine how modern web and mobile apps fit into this overall architectural story.
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.
We've been building Java applications the same way for the greater part of a decade. But these monolithic applications have shortcomings that prevent us from increasing development agility and architectural flexibility. In this session, we'll build a simple system with a plugin and demonstrate it's advantages across the full software development lifecycle.
Are you familar with the Open Closed Principle (OCP) that states “software should be open for extension but closed to modification.” If so, then you know that OCP is a class design principle. But what happens when we extend the definition of OCP and start applying the idea at an architectural level? The answer is that we realize a positive impact on development team structure, software builds, and runtime flexibility. In this session, we'll build a simple system with a plugin architecture and demonstrate how OCP applied at an architectural level opens a new world of possibilities.
With Java 9, modularity will be built in to the Java platform…Finally! In this session, we explore the default Jigsaw module system and compare it to the alternative module system, OSGi, on the Java platform.
We will demonstrate the impact that Jigsaw will have on our existing applications and identify what we must do to get ready for Jigsaw. You will also see firsthand how to use the Jigsaw module system and the benefits that support for modularity on the Java platform will have on your applications.
This session will focus on the big data skills that are needed by software architects. The area of big data is dealing with a massive expansion of tools and technologies. Finding the right people, tools and technologies can a bit of a challenge.
This presentation will focus on the skills needed for navigating the big data waters from an architectural perspective.
Technology changes, it's a fact of life. And while many developers are attracted to the challenge of change, many organizations do a particularly poor job of adapting. We've all worked on projects with, ahem, less than new technologies even though newer approaches would better serve the business. But how do we convince those holding the purse strings to pony up the cash when things are “working” today? At a personal, how do we keep up with the change in our industry?
This talk will explore ways to stay sharp as a software professional. We'll talk about how a technology radar can help you stay marketable (and enjoying your career) and how we can use the same technique to help our companies keep abreast of important changes in the technology landscape. Of course it isn't enough to just be aware, we have to drive change - but how? This talk will consider ways we can influence others and lead change in our organizations.
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:
As we build distributed systems composed of microservices, we introduce new potential performance problems and failure points. As the number of nodes in our system increases, these problems rapidly amplify. In order to keep our composite systems responsive, we can apply the techniques of reactive programming. In order to keep our composite systems healthy, we can apply fault tolerance patterns like circuit breakers and bulkheads.
In this presentation we’ll examine how to leverage two popular libraries from Netflix, Hystrix and RxJava, to create reactive and fault tolerant systems.
Over the past year I’ve had the pleasure of wearing the hat of “product manager” for the Spring Cloud Services team at Pivotal, operating using a distributed variant of the Pivotal Labs process. Along the way I’ve learned many valuable lessons that I hope you’ll be able to apply to your product development efforts.
In this presentation we’ll examine the relationship of product management to engineering and to your customer, and how you can be an effective broker between the two groups.
Many software developers point their career towards ascending to the gilded rank of Architect…but what does it mean to actually be one? While many of us labor under false pretense of abject technical decision making, the reality is often very different. You'll code less, spending more time on activities that lack an objective green/red bar. But you'll also an opportunity to impact far more than one project.
In this talk, I'll speak to my own journey. We'll touch on influencing coworkers, the importance of communication and the importance of cup of coffee.
Many software developers point their career towards ascending to the gilded rank of Architect…but what does it mean to actually be one? While many of us labor under false pretense of abject technical decision making, the reality is often very different. You'll code less, spending more time on activities that lack an objective green/red bar. But you'll also an opportunity to impact far more than one project.
In this talk, I'll speak to my own journey. We'll touch on influencing coworkers, the importance of communication and the importance of cup of coffee.
Architecture does more than describe the system as it is. It also establishes incentives, cost structures, organizational patterns and a marketplace for ideas upon which various players will innovate. One of the reasons the Web has been so successful is because it does this in a way that encourages a wide participation from varied players due to the nature of the architecture upon which it is built: The Internet.
This talk will walk through the design of the Internet Architecture and how it yields the flexibility to innovate to a wide collection of players including VC-backed internet startups, college students working out their room and companies targeting specific types of customers. The choices that have been (and will be) made have enormous implications on how the Internet and Web can be used and evolve and who controls them.
Come think deeply about one of the most important software architectural designs that has ever been designed and why we must protect it.
When talking about finding security defects we first think of security testing and static analysis of the code. Although, penetration testing and secure code review can uncover many types of security issues in an application, there are gaps that simply cannot be found with these traditional analysis techniques. The interactions between the different systems are beyond the code review level and the complex interconnections are often not reachable from the penetration tester’s point of view. Discovering weaknesses in the design of a system is the specific goal of threat modeling. Organizations benefit from this software design analysis because they can perform it without code to discover potential vulnerabilities early in the development cycle.
This talk will describe one of the popular threat modeling methodologies and follow its process of identifying the assets, security controls, and threat agents for a given system, and then creating a prioritized list of attacks. Security analysts together with system architects can then propose appropriate mitigations to be implemented by the team.
One of the leading application security vulnerabilities, cross-site scripting (XSS), has been consistently found in many corporate applications, regardless of traditional defense techniques, such as input validation and output encoding. Knowing the number of such vulnerabilities in the organization’s applications is only half the issue. To understand the real risk, it is important to know how many of these vulnerable applications actually get attacked on the day to day basis, and which specific instances of vulnerabilities are being exploited. Such information will answer the questions like: is a certain framework being exploited most of the time, because it has not been patched? Or is it an issue in the custom code that has not gone through the security code review process? Content Security Policy (CSP) is a new HTML5 technology that allows organizations not only protect their applications from cross-site scripting, ensure that the content of the site, such as audio, video, images, fonts, is only loaded from approved locations, but also to get reports on every violation of the policy, such as cross-site-scripting attempts.
This talk will discuss how to best implement Content Security Policy on the organization’s web sites and how to obtain data on the policy violations and attacks. We will first cover the basics of Content Security Policy, how the policy is configured, the possible security issues CSP may have, how it can be applied to an existing application or an application written from scratch. Then we will discuss the reporting mechanism, types of data returned in the violation reports, methods of aggregation, and browser support. At the end, existing report aggregation and analysis tools will be described, together with examples of existing CSP policies implemented by major social media companies.
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.
Whether your goals are higher concurrency, lower latency or high availability; there are proven techniques and strategies you can implement. Each requires careful consideration and comes with it's own challenges.
In this session we'll examine several architectures for running MySQL at scale and will be building each of the architectures live and hands-on.
Concourse (http://concourse.ci/) is a CI system composed of simple tools and ideas. Concourse can express entire pipelines, integrating with arbitrary resources, or it can be used to execute one-off tasks, either locally or in another CI system. Concourse attempts to reduce the risk of adoption by encouraging practices that keep your project loosely coupled to the details of your continuous integration infrastructure.
Concourse optimizes around the following principles:
During this session we'll learn the simple key concepts from which Concourse pipelines are constructed. We'll understand how to deploy a local Concourse cluster using Vagrant as well as a scalable Concourse cluster to your cloud of choice using Cloud Foundry BOSH. Finally, we'll look at basic and advanced examples of pipelines for Java projects.
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.
Just as a database creates an execution plan to run your SQL queries, HotSpot analyzes your Java code to determine how to best to run your code. And just as with a database where understanding indexes is important to achieving performance, there are a few core concepts that important to understanding Java performance.
In this talk, we'll explore the way HotSpot examines a piece of code in detail, learning not just about the optimizations that HotSpot performs but the hazards that get in its way. In the end, you'll learn how to work with HotSpot so you can write faster code with less effort.
By the end of this conference you will have learned many new tools and technologies. The easy part is done, now for the hard part: getting the rest of the teamand managementon board with the new ideas. Easier said than done.
Whether you want to effect culture change in your organization, lead the transition toward a new technology, or are simply asking for better tools; you must first understand that having a “good idea” is just the beginning. How can you dramatically increase your odds of success?
You will learn 12 concrete strategies to build consensus within your team as well as 6 technique to dramatically increase the odds that the other person will say “Yes” to your requests.
As a professional mentalist, Michael has been a student of psychology, human behavior and the principles of influence for nearly two decades. There are universal principles of influence that neccessary to both understand and leverage if you want to be more effective leader of change in your organization.
In this session we discuss strategies for getting your team on board as well as when/how to approach management within the department and also higherup in the organization.
Client-side JavaScript can get out of control easily. This session explores practical architectural solutions targeted to make your client-side JS easier more reliable, easier to develop and more performant.
Front-end developers love their JavaScript. It is sleek, powerful and very cool. But how do you architect a strategy for dealing with the (tens of) thousands of lines of code your developers will eventually write not to mention the countless JavaScript libraries your developers want to add to your projects? How do you divvy up the code and organize things in a logical way so that you can find specific code easily? What about namespacing concerns? File management and dynamic loading? Writing libraries for use on both client and server? What tools are available to help you address some of these concerns?
Join us as we explore these and other JavaScript client-side architecture dilemmas.
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
What is fragile? Fragile things are easily broken, damaged, or destroyed. When faced with stressors, they crumble. Then what is the opposite of that? Many of us would answer something like “robust” or “resilient.” Things that maintain their integrity when faced with stressors. But it’s possible that we’re wrong.
In his book Antifragile, Nassim Nicholas Taleb challenges this idea by inventing the word that forms the book’s title. Antifragile is the true opposite of fragile. Whereas fragile things are easily broken, damaged, or destroyed when faced with stressors, antifragile things improve, become stronger, or become more powerful when faced with stressors.
Can we build software systems like this? Dick Gabriel explores the idea of ultra-large scale systems that self-regulate (and in fact thrive) in the face of unexpected changes and stressors in his essay “Design Beyond Human Abilities,” and Russ Miles explicitly calls out the idea of Antifragile Software in his book by the same name. During this session we’ll explore these ideas and what they mean to us as developers and architects.
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
Very few applications stand alone anymore. Rather, they are combined together to form holistic systems that perform complex business functions. One of the big challenges when integrating applications is choosing the right integration styles and usage patterns. In this session we will explore various techniques and patterns for application integration, and look at what purpose and role open source integration hubs such as Camel and Mule play in the overall integration architecture space (and how to properly use them!). Through actual integration scenarios and coding examples using Apache Camel you will learn which integration styles and patterns to use for your system and how open source integration hubs play an part in your overall integration strategy
Agenda:
Too many companies embark on enterprise architecture efforts only to have them fail. One of the biggest reasons for these failed attempts at enterprise architecture is that no one really knows what it is. Ask 10 people what enterprise architecture is, and you are guaranteed to get 10 different answers. Enterprise architecture is more than drawing lots of enterprise-level future-state architecture diagrams – it is about being able to bridge the gap between business needs and IT capabilities. In this session you will learn about the context and goals of enterprise architecture, what skills are necessary to become an enterprise architect, and how to model the enterprise. We'll also take a look at transformation techniques for both data and systems across the enterprise.
Agenda:
Humanity has dramatically increased it’s ability to generate and retain astronomically large amounts of data in the last decade. Sooner or later you probably will be working on a project that will have a significant “Data Science” component to it. This is the first of a two-part introduction using machine learning techniques to solve data science questions using the R programming language.
This hand-on talk will be a crash-course into the fun world of Machine Learning (ML). The tutorial will both be a theoretical survey of common machine learning techniques as well a quick introduction to R and how to use it to solve some practical problems using ML. The talk will not make you an expert on machine learning tools but it will give you a solid feel for what can be done with them and help you understand what your data scientist can realistically do for your organization with off-the-libraries and the challenges she has to deal-with day-to-day.
This is the first of two sessions. In this session we will cover
Humanity has dramatically increased it’s ability to generate and retain astronomically large amounts of data in the last decade. Sooner or later you probably will be working on a project that will have a significant “Data Science” component to it or at least be expected to give input about building such system. This is the second of a two-part introduction using machine learning techniques to solve data science questions using the R programming language.
This hand-on talk will be a crash-course into the fun world of Machine Learning (ML) aimed at absolute beginners. The tutorial will both be a theoretical survey of common machine learning techniques as well a quick introduction to R and how to use it to solve some practical problems using ML. The talk will not make you an expert on machine learning tools but it will give you a solid feel for what can be done with them and help you understand what your data scientist can realistically do for your organization with off-the-libraries and the challenges she has to deal-with day-to-day.
This is the second of two sessions. In this session we will cover
Sooner or later you probably will be working on a projects with words like “Data Science”, “Machine Learning”, “Big Data” attached to them. This talk will help you deliver these projects successfully by reviewing the key items you need to consider when incorporating analytical solutions into shipping products.
This talk will focus on answering these questions at scale:
How do we know if our improvements are actually making things better? If we refactor the code, did we make it better? If we skip the tests, are we making things worse? What does better really mean, anyway?
Once we start tracking metrics on the pain we experience during development, we've got a data-driven feedback loop to learn what actually works! Objective data enables us to do something we've never been able to do before in our industry: science.
The “Continuous Acceleration Toolkit” includes new metrics, new tools, and new science-based learning processes, designed to accelerate you and your team to a whole new level of productivity.
In this talk, we'll discuss the three parts of the Continuous Acceleration Toolkit (OSS Tools and Demo for 2/1/2017 release):
If you want to start learning and improving faster than ever, you won't want to miss this talk.
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
Test Driven Design, we hear is a great way to create lightweight design that is easier to maintain and evolve. Unfortunately, just writing test cases mechanically do not lead to good design. In fact, it may really not lead us anywhere we want to really go!
In this presentation we will discuss some of the challenges with using test driven development, look at practical and pragmatic solutions that will help us make a good use of this wonderful design tool.
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.
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.
Organizations have moved from making their employees available to having their applications available directly to the users. This changes the magnitude of scale
of interactions the applications have to support. Furthermore, with devices and bots accessing the systems, we’re looking at a complete different rate of response than we once had to aim for.
In this presentation we will discuss the fundamentals of reactive systems, the key design goals, and the technologies that facilitate building such systems.