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.
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!
Apache Cassandra is one of the best solutions for storing and
retrieving data. We will explore data analytics cluster computing
framework with real-world examples. It is 100x faster than Hadoop!
We will start with an introduction to Apache Cassandra. We will explore challenges encountered when attempting to scale
with relational databases, and how NoSQL databases like Cassandra address those problems. It reviews the Cassandra architecture, benefits, and how to use the Cassandra read and write paths.
Later, you will learn how to effectively and efficiently solve analytical problems using Apache Spark, Apache Cassandra, and DataStax. You will learn about Spark API, Spark-Cassandra Connector, Spark SQL, Spark Streaming, and fundamental performance optimization techniques.
Big Data applications nowadays require a faster speed of data
processing and analysis.
Apache Cassandra is one of the best solutions for storing and
retrieving data. We will explore data analytics cluster computing
framework with real-world examples. It is 100x faster than Hadoop!
We will start with an introduction to Apache Cassandra. We will explore challenges encountered when attempting to scale
with relational databases, and how NoSQL databases like Cassandra address those problems. It reviews the Cassandra architecture, benefits, and how to use the Cassandra read and write paths.
Later, you will learn how to effectively and efficiently solve analytical problems using Apache Spark, Apache Cassandra, and DataStax. You will learn about Spark API, Spark-Cassandra Connector, Spark SQL, Spark Streaming, and fundamental performance optimization techniques.
Big Data applications nowadays require a faster speed of data
processing and analysis.
For this session, you will need a Mac or Windows laptop
1) Download Cassandra:
http://cassandra.apache.org/
2) To setup your environment (on Mac & Windows) for Docker exercises
(1) Download VirtualBox from https://www.virtualbox.org/
(2) Download Docker https://docs.docker.com/kitematic/
(on Linux it should work if you just have the docker package installed)
3) Download Spark
http://spark.apache.org/downloads.html
4) Download Datastax sandbox environment: either virtual box or VMware image
https://academy.datastax.com/downloads/welcome
From:
https://academy.datastax.com/resources/getting-started-apache-spark
Download: DS320 Virtual Machine Download (Includes Exercises) https://s3.amazonaws.com/datastaxtraining/VM/DS320-vm-dsa.zip
5) Download exercises from the workshop site.
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.
In this workshop you'll get an in-depth overview of Galera Cluster; an open source, true Multimaster Cluster based on synchronous replication. We'll combine it with MariaDB MaxScale and you'll learn how to easily implement a high-performance, highly available distributed MySQL cluster.
This workshop assumes basic familiarity with Linux, command line MySQL and a laptop. You'll be provided with VMs and ssh access.
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.
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 give some love to your architecture by carefully managing and controlling 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 using automated quality gates in combination with a domain-specific language that can be used to enforce an architectural blueprint over the lifetime of a software system.
In the workshop part participants will use Sonargraph to assess and analyze a software system of their choice (Java, C/C++ or C#) and design an architectural model using the domain specific language introduced in the session. The tool and a free 30 day license will be provided during 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 give some love to your architecture by carefully managing and controlling 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 using automated quality gates in combination with a domain-specific language that can be used to enforce an architectural blueprint over the lifetime of a software system.
In the workshop part participants will use Sonargraph to assess and analyze a software system of their choice (Java, C/C++ or C#) and design an architectural model using the domain specific language introduced in the session. The tool and a free 30 day license will be provided during the workshop.
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.
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.
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.
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.
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
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
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:
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:
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.
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.
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.
I.flow() AI is an emotional intelligence AI that learns to respond in real-time to the pain of humans, for example, developers that are having a hard time. The I.flow() AI Platform is still in the early stages of mapping theory to concrete implementation, so in this talk we'll breakdown architecture strategy, pain metrics, pair programming buddy, supply chain flows, and the underpinning of Flow theory.
Flow is an old concept, adopted into the software world by mapping Flow from Lean manufacturing. When we map a metaphor between two different domains, our brain locks onto the isomorphisms between contexts, and “Flow” becomes stickies flowing on a whiteboard, or features flowing out to customers. It becomes difficult to see Flow any other way.
What if our object-oriented blinders led to an object-oriented notion of Flow, and there's a totally different way to look at the system? Flow, at it's core, is a paradigm shift, a metaphorical lens, that helps us see, understand, and predict the behavior of any Flow System. Better predictive models, enables AI automation like we've never had before. It's about time we started applying AI to our own problems.
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.
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.
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.
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.
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.
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.
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:
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.
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!
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.
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.
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.
“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.
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.
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.
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.
“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.
“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.
It's common knowledge: software must be extensible, easier to change, less expensive to maintain. But, how? That's what we often struggle with. Thankfully there are some really nice design principles and practices that can help us a great deal in this area.
In this workshop, we will start with a few practical examples, problems that will demand extensibility and ease of change. We will approach their design, and along the way learn about the principles we apply, why we apply them, and the benefits we get out of using these principles. Instead of talking theory, we will design, refactor, create prototypes, and evaluate the design we create.
-Java 8 JDK or later version
-Your favorite IDE (Preferably IntelliJ IDEA Community Edition)
-git
It's common knowledge: software must be extensible, easier to change, less expensive to maintain. But, how? That's what we often struggle with. Thankfully there are some really nice design principles and practices that can help us a great deal in this area.
In this workshop, we will start with a few practical examples, problems that will demand extensibility and ease of change. We will approach their design, and along the way learn about the principles we apply, why we apply them, and the benefits we get out of using these principles. Instead of talking theory, we will design, refactor, create prototypes, and evaluate the design we create.
-Java 8 JDK or later version
-Your favorite IDE (Preferably IntelliJ IDEA Community Edition)
-git
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.
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.
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.
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.
A 2007 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 2015 Gartner survey showed that 70% of all businesses were looking to start or restart their enterprise architecture programs. That’s where this workshop comes in.
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, integrate systems across the enterprise, consolidate information from various systems, and knowing when and how to use enterprise architecture models. In this workshop you'll learn what enterprise architecture is, the modern role of an enterprise architect, and the steps involved in creating en effective enterprise architecture.
This is a workshop to explore top 5 cloud architectural challenges. Come prepared with open mind and zeal to solve customer requirements. Workshop is divided into first the real world problems. Later we will discuss possible solutions for each of these problems.
Cloud computing is adopted in all major Enterprises. In this talk we will explore top challenges in Cloud design and deployments. Firstly, we will explore cloud challenges with Service Quality and what design principles need to be adopted to be able to support SLAs in Cloud. Next, Cloud security is a must to be incorporated throughout application development. We will explore Threat Modeling, SOC2 compliance, disaster recovery, and different ways to identify and fix vulnerabilities. Next, we will explore design principles to build support for availability, failover strategies, and downtimes. We will explore ways to design applications, which support <500 ms response time. Next, we will discover how modern cloud enabled applications need to be built using 12 factor application model. Lastly, we will look at how Dockers, Kubernetes, and Mesos DC/OS are helping build scalable Cloud applications.
You can now directly apply your knowledge of architecture principles through this workshop. This will be helpful in enhancing your architect skills with constructive feedback from attendees. You can also come with your organization’s architectural challenges.
This is a workshop to explore top 5 cloud architectural problems. Come prepared with open mind and zeal to solve customer requirements. Workshop is divided into first the real world problems. Later we will discuss possible solutions for each of these problems.
Cloud computing is adopted in all major Enterprises. In this talk we will explore top challenges in Cloud design and deployments. Firstly, we will explore cloud challenges with Service Quality and what design principles need to be adopted to be able to support SLAs in Cloud. Next, Cloud security is a must to be incorporated throughout application development. We will explore Threat Modeling, SOC2 compliance, disaster recovery, and different ways to identify and fix vulnerabilities. Next, we will explore design principles to build support for availability, failover strategies, and downtimes. We will explore ways to design applications, which support <500 ms response time. Next, we will discover how modern cloud enabled applications need to be built using 12 factor application model. Lastly, we will look at how Dockers, Kubernetes, and Mesos DC/OS are helping build scalable Cloud applications.
You can now directly apply your knowledge of architecture principles through this workshop. This will be helpful in enhancing your architect skills with constructive feedback from attendees. You can also come with your organization’s architectural challenges.
This is a workshop to explore top 5 cloud architectural challenges. Come prepared with open mind and zeal to solve customer requirements. Workshop is divided into first the real world problems. Later we will discuss possible solutions for each of these problems.
Cloud computing is adopted in all major Enterprises. In this talk we will explore top challenges in Cloud design and deployments. Firstly, we will explore cloud challenges with Service Quality and what design principles need to be adopted to be able to support SLAs in Cloud. Next, Cloud security is a must to be incorporated throughout application development. We will explore Threat Modeling, SOC2 compliance, disaster recovery, and different ways to identify and fix vulnerabilities. Next, we will explore design principles to build support for availability, failover strategies, and downtimes. We will explore ways to design applications, which support <500 ms response time. Next, we will discover how modern cloud enabled applications need to be built using 12 factor application model. Lastly, we will look at how Dockers, Kubernetes, and Mesos DC/OS are helping build scalable Cloud applications.
You can now directly apply your knowledge of architecture principles through this workshop. This will be helpful in enhancing your architect skills with constructive feedback from attendees. You can also come with your organization’s architectural challenges.
This is a workshop to explore top 5 cloud architectural problems. Come prepared with open mind and zeal to solve customer requirements. Workshop is divided into first the real world problems. Later we will discuss possible solutions for each of these problems.
Cloud computing is adopted in all major Enterprises. In this talk we will explore top challenges in Cloud design and deployments. Firstly, we will explore cloud challenges with Service Quality and what design principles need to be adopted to be able to support SLAs in Cloud. Next, Cloud security is a must to be incorporated throughout application development. We will explore Threat Modeling, SOC2 compliance, disaster recovery, and different ways to identify and fix vulnerabilities. Next, we will explore design principles to build support for availability, failover strategies, and downtimes. We will explore ways to design applications, which support <500 ms response time. Next, we will discover how modern cloud enabled applications need to be built using 12 factor application model. Lastly, we will look at how Dockers, Kubernetes, and Mesos DC/OS are helping build scalable Cloud applications.
You can now directly apply your knowledge of architecture principles through this workshop. This will be helpful in enhancing your architect skills with constructive feedback from attendees. You can also come with your organization’s architectural challenges.
This talk is designed to catapult your productivity, enhance your emotional intelligence, and refine your problem-solving skills. This talk is not just a series of presentations; it's a transformative experience tailored for the ambitious software developer and architect seeking to leave a mark in the fast-paced world of technology.
Dive into the essence of developer and architect productivity, where we unravel the secrets to optimizing your workflow and leveraging your skills for maximum impact. Discover the “24 Hours Instant Happiness” principle, a proven strategy to inject a dose of joy into your daily routine, fostering a positive work environment and personal life.
“Maximizing Your Impact” takes you deeper into the realm of influence, equipping you with the tools to excel in your projects and inspire those around you. Through “Effective Communication” and the intriguing “Mirror Technique,” learn how to build rapport, foster collaboration, and lead with empathy, amplifying your charisma in all professional interactions.
As we delve into the core of success, “Emotional Intelligence is 85% of Success” highlights the paramount importance of self-awareness, self-regulation, motivation, empathy, and social skills in achieving your goals. The “6 Phase Meditation Approach” and “Day Launcher” sessions are designed to refine your focus, creativity, and emotional stability, setting a solid foundation for a productive day ahead.
The inclusion of “Empathy Maps” and “IDEO Case Studies” offers a practical lens through which to view user-centric design and innovation. At the same time, the “SCAMPER Technique” provides a creative framework for problem-solving, ensuring you're equipped to tackle challenges with agility and inventiveness.
Elevate your productivity to new heights with “5 Choices for Super Productivity,” a comprehensive guide to prioritizing effectively, embracing extraordinary outcomes, and mastering your technology. Learn the art of “Managing Energy, Not Time,” a paradigm shift that promises to enhance your efficiency and job satisfaction.
As the talk culminates, “The Paradox of Choice” and the latest “Technology Trends to Focus On” prepare you to navigate the complexities of the modern tech landscape with confidence and curiosity.
This masterclass is more than just a talk; it's an invitation to transform how you work, lead, and innovate. Join us to unlock your full potential and reshape your future in software development and architecture. Whether you're looking to boost your productivity, enhance your emotional intelligence, or simply find more joy in your work, this talk is your gateway to a more fulfilling career and life.
Developers and Architects are designers, problem solvers, and innovative, creative artists. Software design is an art that requires both left and right brains to be active so you can understand what customers need. Next, we will explore habits and tools to plan, learn, research, organize, teach, develop, mentor, and architect.
Agenda
Enhancing Productivity and Personal Growth
– Developer and Architect Productivity
Strategies for improving daily workflow and efficiency in software development and architecture.
– 24 Hours Instant Happiness
Quick wins for boosting morale and happiness within the team and personal life.
– Maximizing Your Impact
Techniques to increase your influence and contributions in projects and teams.
– Effective Communication
Importance of clear communication and the Mirror Technique to improve understanding and rapport.
– Increasing Charisma
Tips for becoming more charismatic and influential in professional settings.
Building Emotional Intelligence and Mindfulness
– Emotional Intelligence is 85% of Success
Discussing the critical role of emotional intelligence in achieving professional success.
– 6-Phase Meditation Approach
Introducing a meditation technique to enhance focus, creativity, and emotional stability.
– Day Launcher
A strategy to start your day with intention and focus, setting the tone for productivity and success.
– Empathy Map
Utilizing empathy maps to better understand user needs and enhance team collaboration.
– IDEO Case Studies
Examining case studies from IDEO to illustrate successful applications of empathy in design.
– Understanding a Problem with SCAMPER Technique
Exploring the SCAMPER technique to creatively solve problems and innovate solutions.
Strategies for Super Productivity
– 5 Choices for Super Productivity
Detailed strategies for enhancing productivity by prioritizing important tasks, aiming for extraordinary outcomes, scheduling priorities (“big rocks”), mastering technology use, and maintaining energy levels.
– Managing Energy, Not Time
Shifting focus from time management to energy management to maximize productivity and well-being.
– Increasing Frequency to Do What You Want
Techniques to align daily actions with personal and professional goals more effectively.
– The Paradox of Choice
Understanding how reducing options can lead to increased satisfaction and productivity.
– Technology Trends to Focus On
Highlighting current technology trends that developers and architects should be aware of to stay ahead in their field.
What's in Java 9 and, more important, how does that impact us?
In this presentation we will take a look at the major features that are likely to make in to Java 9, discuss the benefits of each one of them using practical hands on examples.
On 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.
API Gateway is a way to connect Enterprise application in cloud-ready applications. New applications need to design the data model and create public APIs to be consumed by mobile apps, third party apps, and different devices. We will explore best practices, which you must adopt to be cloud ready. Firstly, we will examine how contract first API development is helping enable more extensible and reliable APIs. Next, we will look at
We will ask tough questions during this design session. How to provide security? What are best practices to authenticate? When should we version APIs? Should we use HATEOS for developing APIs? How to support internationalization? How to publish and maintain APIs?
We will take deep dive into following areas:
• RESTful APIs design patterns:
Principles for designing APIs, Hypermedia, Entity tags caching, filtering, Partial items, HAL
• API versioning techniques:
URI path, URI parameter, Content Negotiation, Request header
• API Security:
Threats, Protecting APIs, Authentication, API Keys: How they work? SAML, OAuth and JSON Web Tokens
• API Gateway:
Customer Driven contract development
• API testing:
SoapUI, REST-assured
This talk is ideal for the following roles:
Architects
Technical Leads
Programers
Integration Architects
Solution Architects
API Gateway is a way to connect Enterprise application in cloud-ready applications. New applications need to design the data model and create public APIs to be consumed by mobile apps, third party apps, and different devices. We will explore best practices, which you must adopt to be cloud ready. Firstly, we will examine how contract first API development is helping enable more extensible and reliable APIs. Next, we will look at
We will ask tough questions during this design session. How to provide security? What are best practices to authenticate? When should we version APIs? Should we use HATEOS for developing APIs? How to support internationalization? How to publish and maintain APIs?
We will take deep dive into following areas:
• RESTful APIs design patterns:
Principles for designing APIs, Hypermedia, Entity tags caching, filtering, Partial items, HAL
• API versioning techniques:
URI path, URI parameter, Content Negotiation, Request header
• API Security:
Threats, Protecting APIs, Authentication, API Keys: How they work? SAML, OAuth and JSON Web Tokens
• API Gateway:
Customer Driven contract development
• API testing:
SoapUI, REST-assured
This talk is ideal for the following roles:
Architects
Technical Leads
Programers
Integration Architects
Solution Architects
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:
Securing of the web application is an enormous task. In this talk, we will explore how to protect enterprise applications. We will explore different kinds of vulnerabilities and hot to secure your applications properly. Security patterns need to be understood by first wearing the hat of a hacker and then putting the hat as a defender. In this workshop, we will explore different security patterns and determine how to prevent attacks.
We will be using Kali Linux to understand Ethical hacking techniques using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
In this workshop we will explore following:
Install Microsoft
Microsoft threat modeling tool
https://www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx
https://www.microsoft.com/en-us/download/details.aspx?id=49168
Install Kali Linux
http://docs.kali.org/general-use/kali-linux-virtual-box-guest
To reset install from terminal:
apt-get update
apt-get upgrade -y
apt-get dis-upgrade -y
reboot
Install Metasploitable
https://sourceforge.net/projects/metasploitable/
Installing on virtual box:
http://www.hacking-tutorial.com/tips-and-trick/install-metasploitable-on-virtual-box/#sthash.Tdh0WG8j.dpbs
Install openvas vulnerability scanning tool
https://www.kali.org/penetration-testing/openvas-vulnerability-scanning/
Useful apts to download from terminal:apt-get install preload
apt-get install bleachbit
apt-get install bum
apt-get install gnome-do
apt-get install apt-file
apt-get install scrub
apt-get install shutter
apt-get install figlet
apt-get install metagoofil
apt-get install whois
apt-get install dmitry
apt-get install recon-ng
apt-get install theharvester
apt-get install httrack
Get the exercises from here:
http://tinyurl.com/huusd4d
Securing of web applications is a gigantic task. In this talk, we will explore how to protect enterprise applications. We will explore different kinds of vulnerabilities and hot to secure your applications properly. Security patterns need to be understood by first wearing the hat of a hacker and then putting the hat of a defender. In this workshop, we will explore different security patterns and determine how to prevent attacks.
We will be using Kali Linux to understand Ethical hacking techniques using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
Securing of web applications is a gigantic task. In this talk, we will explore how to protect enterprise applications. We will explore different kinds of vulnerabilities and hot to secure your applications properly. Security patterns need to be understood by first wearing the hat of a hacker and then putting the hat of a defender. In this workshop, we will explore different security patterns and determine how to prevent attacks.
We will be using Kali Linux to understand Ethical hacking techniques using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
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:
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.
Continuous delivery is not a pipe-dream technology, reserved only for the “cool kids” at hip tech startups. Although it's not easy, many concepts are within reach of most teams. That being said, it require more than simple technology changes. Attend this session to learn the fundamental concepts of CD, how to build your CD pipeline with Gradle and Jenkins, and recommendations on tools and best practices.
No prior knowledge is assumed and this talk will start from first principles.
Part one begins with a detailed overview of what CD is (and isn't) and how to build a business case for CD. Making both the technical case and business case for CD is vital as it's necessary to get the entire organization on board with the changes required.
Part two is a deeper dive into building a continuous delivery pipeline with Gradle and Jenkins (although the broader concepts can be applied to the tooling of your choice) You'll see how easily Gradle integrates with Java and how to leverage configuration management and gradle plugins to build all of your quality gates.
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.
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
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.
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 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.
In this session you'll learn how to build a truly scalable, truly robust database cluster using Galera and MaxScale.
Galera Cluster for MySQL is a true Multimaster Cluster based on synchronous replication. Galera Cluster is an easy-to-use, high-availability solution, which provides high system uptime, no data loss and scalability for future growth.
MaxScale as an Application-to-Database dynamic data routing platform insulates client applications from complexities of backend database cluster to improve database availability, security and scalability. MaxScale as a Database-to-Database dynamic data routing platform simplifies interoperability across databases.
When you hear the term “Internet of Things (IoT)” what do you think of? From a customer perspective it is a bunch of cool gadgets. From the datacenter perspective IoT == the onslaught of data and previously unprecedented scale.
This presentation is provide a walk through of the technologies necessary to dynamically create in data pipelines and process them for near real-time access to analytics.
This presentation will provide an overview of the Lambda architecture along with a brief walk through of each of the components of a common IoT datacenter infrastructure. Topics to include:
Brief mentions of Hive, Storm and InfluxDB included.
When you hear the term “Internet of Things (IoT)” what do you think of? From a customer perspective it is a bunch of cool gadgets. From the datacenter perspective IoT == the onslaught of data and previously unprecedented scale.
This presentation is provide a walk through of the technologies necessary to dynamically create in data pipelines and process them for near real-time access to analytics.
This presentation will provide an overview of the Lambda architecture along with a brief walk through of each of the components of a common IoT datacenter infrastructure. Topics to include:
Brief mentions of Hive, Storm and InfluxDB included.
An introduction to Apache Myriad on Mesos which provides the flexibility to increase or decrease Hadoop resources on the fly.
The current demands on the datacenter require a dynamic environment to succeed. The legacy approach of static clusters limits overall cluster utilization and does not allow for the growth demands of different versions of the analytic clusters. There is an increasing need to integrate big data and related Apache Hadoop applications with other datacenter services, ideally, by co-locating the data in HDFS/HBase with the services that need it.
In this talk, Ken (one of the committers on project) will show off Apache Myriad, which integrates Apache YARN with Apache Mesos. Mesos enables efficient resource sharing and isolation across a variety of distributed applications. This allows Apache Hadoop workloads to run alongside other datacenter applications, while sharing the same cluster, and hence breaking silos. This multi-tenancy strategy improves overall cluster utilization and operational efficiency.
Spark Streaming
Kafka
Cassandra
Mesos
Spark Streaming
Kafka
Cassandra
Cluster design
app classifications
security boundries
mix workloads
multi tenancy
Cluster design
app classifications
security boundries
mix workloads
multi tenancy
Zookeeper and ETCD basics
Zookeeper and ETCD basics
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:
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
In this session you will learn to strategically introduce technology innovations by applying specific change patterns to groups of individuals. Using these patterns and related techniques will not only benefit your organization but will ultimately benefit your career as a technologist by making you a better influencer, writer, and speaker.
The rapid pace of technological innovation has enabled many organizations to dramatically increase productivity while at the same time decrease their overall headcount. However, the vacillating global economy combined with “change fatigue” within organizations has resulted in a risk averse culture. In such an environment how can one possibly introduce and inculcate the latest technology or process within an organization? The answer is to have a solid understanding of Diffusion Theory and to leverage Patterns of Change.
Prezi Location: http://prezi.com/b85wwmw7hccn
Using the Microservices Architectural Style to incrementally adopt an Event-driven Architecture (EDA) lowers up-front costs while decreasing time-to-market. EDA extracts value from existing occurrences, limiting invasive refactoring or disrupting existing application development efforts. Implementing Event-driven Microservices yields intelligence, scalable, extensible, reactive endpoints.
This session will cover the fundamentals, patterns, techniques and pitfalls of Event-driven Microservices with several demos leveraging Spring-Boot, Camel, ActiveMQ and Docker.
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 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 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.
Becoming a software architect is a longed-for career upgrade for many software developers. While the job title suggests a work day focused on technical decision-making, the reality is quite different. In this workshop, software architect Nathaniel Schutta constructs a real world job description in which communication trumps coding.
Through lecture and small group exercises, Nathaniel will help you understand what it means to be a successful architect. Working through various problems, attendees will have opportunities to think through architectural decisions and patterns, discuss the importance of non functional requirements and why architects cannot afford to practice resume driven design.
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! We will work in pairs or teams. A laptop will be helpful for presenting exercises in class and taking notes but is not required. That's it! Well, and a willingness to participate!
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 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
There is no doubt that much debate and opinion exists in our industry as to what really is a cloud native app platform! Regardless of what your definition is, it is certain that we simply don't have time to re-write all of the second generation monolithic apps, but yet we must modernize at the same time. With this reality in mind, I begin the discussion of how to build platforms that are both 3rd generation and 2nd generation capable while delivering feasible enterprise application platforms.
As for the cloud native movement, it is important to understand the elements of this rapidly moving phenomenon through our industry, a phenomenon of building platforms, not just business logic software but infrastructure as software. I humbly believe that the drive towards these platform solutions is due to the following fact: approximately half of new applications fail to meet their performance objectives, and almost all of these have 2.x more cloud capacity provisioned than what is actually needed. As developers we live with this fact every day, always chasing performance and feasible scalability, but never actually cementing it into a scientific equation where it is predictable, but rather it has always been trial based, and heavily prone to error. As a result we find ourselves delving with some interesting platforming patterns of this decade, and unfortunately we are lead to believe that such patterns as Microservices, 3rd platforms, cloud native, and 12factor are mainly a change in coding patterns, to the contrary – these patterns reveal a much more deep shift in the way developers view and consume infrastructure. In fact these patterns represent a major change in “deployment” approach, a change in how we deploy and structure code artifacts within applications runtimes, and how those application runtimes can leverage the underlying cloud capacity. These patterns are not code design patterns, but rather platform engineering patterns, with a drive to using APIs/Software to define application platform policies to manage scalability, availability and performance in a predictable manner. In this session I will briefly inspect platform patterns that we built over the last decade, and the ones we are building for the next decade. The main objective of the session will be to 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 both manually and dynamically as needed within your software defined platform. Which are key ingredients for knowing how to run 2nd and 3rd gen application platforms at the same time under one platform.
There is no doubt that much debate and opinion exists in our industry as to what really is a cloud native app platform! Regardless of what your definition is, it is certain that we simply don't have time to re-write all of the second generation monolithic apps, but yet we must modernize at the same time. With this reality in mind, I begin the discussion of how to build platforms that are both 3rd generation and 2nd generation capable while delivering feasible enterprise application platforms.
As for the cloud native movement, it is important to understand the elements of this rapidly moving phenomenon through our industry, a phenomenon of building platforms, not just business logic software but infrastructure as software. I humbly believe that the drive towards these platform solutions is due to the following fact: approximately half of new applications fail to meet their performance objectives, and almost all of these have 2.x more cloud capacity provisioned than what is actually needed. As developers we live with this fact every day, always chasing performance and feasible scalability, but never actually cementing it into a scientific equation where it is predictable, but rather it has always been trial based, and heavily prone to error. As a result we find ourselves delving with some interesting platforming patterns of this decade, and unfortunately we are lead to believe that such patterns as Microservices, 3rd platforms, cloud native, and 12factor are mainly a change in coding patterns, to the contrary – these patterns reveal a much more deep shift in the way developers view and consume infrastructure. In fact these patterns represent a major change in “deployment” approach, a change in how we deploy and structure code artifacts within applications runtimes, and how those application runtimes can leverage the underlying cloud capacity. These patterns are not code design patterns, but rather platform engineering patterns, with a drive to using APIs/Software to define application platform policies to manage scalability, availability and performance in a predictable manner. In this session I will briefly inspect platform patterns that we built over the last decade, and the ones we are building for the next decade. The main objective of the session will be to 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 both manually and dynamically as needed within your software defined platform. Which are key ingredients for knowing how to run 2nd and 3rd gen application platforms at the same time under one platform.
Programming is an act of continuous discoveries. Auto-Completion in IDEs are great, but they're more of a speculation than experimentation. Read-Evaluate-Print-Loop or REPL gives an instant feedback and the ability to quickly try out your ideas. Fast feedbacks are the rage today in development.
Come to this all live coding, no slides session to learn how to leverage the Java 9 REPL to accelerate your Java Development.
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.
Understand a modern, flexible and decentralized way to provide authorization controls on resources and microservices
Google Research has given us Macaroons (no, not the fancy, delicious cookies). Google’s Macaroons are an authorization model with support for contextually controlled caveats and the simplicity of a regular cookie. This allows a fine-grained and flexible approach to delegating privilege to principals in a decentralized way, allowing you to protect resources.
Brian Sletten introduces the underlying principles of Macaroons as he walks you through applying them in practice with nontrivial delegation scenarios, demonstrating how to build systems with strong controls as well as the freedom to transfer privileges to others with more narrow constraints.
The combination of simplicity, flexibility, and sophistication is a rare and desirable goal for modern security controls. Even if you aren’t interested in putting Macaroons in practice in your own work, it is worth diving deeper just to gain exposure to a technology with these properties.
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:
Which marriages in the village will last? Which chicken is queen of the coop? How many crayons do you need to color a county map of Tennessee? What do all of these questions have in common? They're all graph problems.
Graphs are simultaneously the most intuitive data structure and host to some of the most esoteric algorithms and properties most developers are likely to encounter. Come to this talk for a friendly and approachable introduction to graph theory, application, and implementation.
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.
Apache Cassandra is a leading open-source distributed database capable of amazing feats of scale, but its data model requires a bit of planning for it to perform well. Of course, the nature of ad-hoc data exploration and analysis requires that we be able to ask questions we hadn’t planned on asking—and get an answer fast. Enter Apache Spark.
Spark is a distributed computation framework optimized to work in-memory, and heavily influenced by concepts from functional programming languages. In this workshop, we’ll explore Spark and Cassandra together and see how they deliver a powerful open-source big data analytics solution.
Apache Cassandra is a leading open-source distributed database capable of amazing feats of scale, but its data model requires a bit of planning for it to perform well. Of course, the nature of ad-hoc data exploration and analysis requires that we be able to ask questions we hadn’t planned on asking—and get an answer fast. Enter Apache Spark.
Spark is a distributed computation framework optimized to work in-memory, and heavily influenced by concepts from functional programming languages. In this workshop, we’ll explore Spark and Cassandra together and see how they deliver a powerful open-source big data analytics solution.
Turning a stream into a parallel stream is extremely easy, but is that the prudent thing to do? While flipping that switch is almost effortless there are some significant ramifications. In this presentation we will learn the power of parallel streams but also why, when, and where it makes sense to use parallel streams. Through a series of example we will learn about cases where it makes sense and some there it does not.
Streams
Parallel Streams
Controlling Threads
Deciding Threads
Performance Implications
Recommendations on prudent use
Efficiency is achieved not just by running things faster, but by avoiding things that shouldn't be done in the first place. Lazy evaluations are a core feature of many functional programming languages. Your code can benefit from lazy evaluations with lambda expressions and, more so, with the power of Streams.
In this presentation, we'll start with a discussion of lazy evaluations, with short examples from Haskell and Scala. Then we'll dive into Java to see how we can achieve similar benefits using lambdas and the Stream API.
Functional Programming has been around for a while, but it is gaining popularity, especially due to direct support in languages on the JVM. Writing code in functional style is not about syntax, it is a paradigm shift. In this presentation, using examples from Java, Groovy, and Scala, you will learn how to write code in functional style. We will start out discussing the elements of functional programming and then look at examples of some common operations and how you can implement those in functional style.
.
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
We are all familiar with the 3rd Normal form. Does that scale? What are the best practices for designing resilient, multi-tenant, performant databases? In this talk, we will explore the database evaluation process, where we will make choices on technology stacks based on requirements and analyzing the CAP theorem. We will discover different Consistency, Availability, and Partition Tolerance techniques, investigate No-SQL databases, and help new cloud deployments using the 3rd Platform.
Big data has characteristics in the new Cloud domain, which requires storing various data for different use-cases. We will explore the Document data store, Key-value, Columnar NoSQL, and Graph NoSQL databases.
Next, we will look at how to do data modeling for NoSQL columnar databases to support highly available partition tolerant use-cases. We will discover different strategies to help multi-tenant requirements. In the end, we will look at how to choose the right database? We will also see the future of Databases compared to Consistency Models, Schema Models, Database Languages, and Database storage.
A few of the technologies we will explore are
This talk is ideal for the following roles:
Kubernetes and Docker Swarm are universally used tools to deploy containers inside a cluster. Both are created as helper tools that can be used to manage a cluster of containers and treat all servers as a single unit.
Docker is an open platform for developing, shipping, and running applications. In this talk, we will discover how Docker help separates your applications from your infrastructure and treat your infrastructure like a managed application. Docker helps you ship code faster, test faster, deploy faster and shorten the cycle between writing code and running code. We will explore Docker architecture. We will investigate how you can create your image and compose and deploy in Docker hub so others can start using the same environment. Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual Docker host. Because Docker Swarm serves the standard Docker API, any tool that already communicates with a Docker daemon can use Swarm to scale to multiple hosts transparently.
Kubernetes is Google’s answer to an open-source system for automating deployment, scaling, and management of containerized applications. In this talk we will discover how to use Kubernetes which is portable: public, private, hybrid, multi-cloud; extensible: modular, pluggable, hookable, composable; self-healing: auto-placement, auto-restart, auto-replication, auto-scaling.
Kubernetes and Docker Swarm are universally used tools to deploy containers inside a cluster. Both are created as helper tools that can be used to manage a cluster of containers and treat all servers as a single unit.
Docker is an open platform for developing, shipping, and running applications. In this talk, we will discover how Docker help separates your applications from your infrastructure and treat your infrastructure like a managed application. Docker helps you ship code faster, test faster, deploy faster and shorten the cycle between writing code and running code. We will explore Docker architecture. We will investigate how you can create your image and compose and deploy in Docker hub so others can start using the same environment. Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual Docker host. Because Docker Swarm serves the standard Docker API, any tool that already communicates with a Docker daemon can use Swarm to scale to multiple hosts transparently.
Kubernetes is Google’s answer to an open-source system for automating deployment, scaling, and management of containerized applications. In this talk we will discover how to use Kubernetes which is portable: public, private, hybrid, multi-cloud; extensible: modular, pluggable, hookable, composable; self-healing: auto-placement, auto-restart, auto-replication, auto-scaling.
Kubernetes and Docker Swarm are universally used tools to deploy containers inside a cluster. Both are created as helper tools that can be used to manage a cluster of containers and treat all servers as a single unit.
Docker is an open platform for developing, shipping, and running applications. In this talk, we will discover how Docker help separates your applications from your infrastructure and treat your infrastructure like a managed application. Docker helps you ship code faster, test faster, deploy faster and shorten the cycle between writing code and running code. We will explore Docker architecture. We will investigate how you can create your image and compose and deploy in Docker hub so others can start using the same environment. Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual Docker host. Because Docker Swarm serves the standard Docker API, any tool that already communicates with a Docker daemon can use Swarm to scale to multiple hosts transparently.
Kubernetes is Google’s answer to an open-source system for automating deployment, scaling, and management of containerized applications. In this talk we will discover how to use Kubernetes which is portable: public, private, hybrid, multi-cloud; extensible: modular, pluggable, hookable, composable; self-healing: auto-placement, auto-restart, auto-replication, auto-scaling.
Kubernetes and Docker Swarm are universally used tools to deploy containers inside a cluster. Both are created as helper tools that can be used to manage a cluster of containers and treat all servers as a single unit.
Docker is an open platform for developing, shipping, and running applications. In this talk, we will discover how Docker help separates your applications from your infrastructure and treat your infrastructure like a managed application. Docker helps you ship code faster, test faster, deploy faster and shorten the cycle between writing code and running code. We will explore Docker architecture. We will investigate how you can create your image and compose and deploy in Docker hub so others can start using the same environment. Docker Swarm is native clustering for Docker. It turns a pool of Docker hosts into a single, virtual Docker host. Because Docker Swarm serves the standard Docker API, any tool that already communicates with a Docker daemon can use Swarm to scale to multiple hosts transparently.
Kubernetes is Google’s answer to an open-source system for automating deployment, scaling, and management of containerized applications. In this talk we will discover how to use Kubernetes which is portable: public, private, hybrid, multi-cloud; extensible: modular, pluggable, hookable, composable; self-healing: auto-placement, auto-restart, auto-replication, auto-scaling.
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.
Understanding OWASP top ten will give your application development team a clear vision on how to find the security flaws. We will focus on identifying the weaknesses and provide the ability to the architect or developer in coming up with a robust design.
We will explore the Top Ten vulnerabilities including:
• SQL injection
• Session management
• Cross-Site Scripting (XSS)
• Cross-Sift Request Forgery (CSRF)
• Security misconfigurations
We will be using Kali Linux to understand Top 10 vulnerabilities using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
Understanding OWASP top ten will give your application development team a clear vision on how to find the security flaws. We will focus on identifying the weaknesses and provide the ability to the architect or developer in coming up with a robust design.
We will explore the Top Ten vulnerabilities including:
• SQL injection
• Session management
• Cross-Site Scripting (XSS)
• Cross-Sift Request Forgery (CSRF)
• Security misconfigurations
We will be using Kali Linux to understand Top 10 vulnerabilities using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
Install Kali Linux
http://docs.kali.org/general-use/kali-linux-virtual-box-guest
To reset install from terminal:
apt-get update
apt-get upgrade -y
apt-get dis-upgrade -y
reboot
Install Metasploitable
https://sourceforge.net/projects/metasploitable/
Installing on virtual box:
http://www.hacking-tutorial.com/tips-and-trick/install-metasploitable-on-virtual-box/#sthash.Tdh0WG8j.dpbs
Install openvas vulnerability scanning tool
https://www.kali.org/penetration-testing/openvas-vulnerability-scanning/
Useful apts to download from terminal:apt-get install preload
apt-get install bleachbit
apt-get install bum
apt-get install gnome-do
apt-get install apt-file
apt-get install scrub
apt-get install shutter
apt-get install figlet
apt-get install metagoofil
apt-get install whois
apt-get install dmitry
apt-get install recon-ng
apt-get install theharvester
apt-get install httrack
Understanding OWASP top ten will give your application development team a clear vision on how to find the security flaws. We will focus on identifying the weaknesses and provide the ability to the architect or developer in coming up with a robust design.
We will explore the Top Ten vulnerabilities including:
• SQL injection
• Session management
• Cross-Site Scripting (XSS)
• Cross-Sift Request Forgery (CSRF)
• Security misconfigurations
We will be using Kali Linux to understand Top 10 vulnerabilities using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
Understanding OWASP top ten will give your application development team a clear vision on how to find the security flaws. We will focus on identifying the weaknesses and provide the ability to the architect or developer in coming up with a robust design.
We will explore the Top Ten vulnerabilities including:
• SQL injection
• Session management
• Cross-Site Scripting (XSS)
• Cross-Sift Request Forgery (CSRF)
• Security misconfigurations
We will be using Kali Linux to understand Top 10 vulnerabilities using Metasploitable applications. In the end, we will see how OpenVas can help in scanning the vulnerabilities in the application.
Install Kali Linux
http://docs.kali.org/general-use/kali-linux-virtual-box-guest
To reset install from terminal:
apt-get update
apt-get upgrade -y
apt-get dis-upgrade -y
reboot
Install Metasploitable
https://sourceforge.net/projects/metasploitable/
Installing on virtual box:
http://www.hacking-tutorial.com/tips-and-trick/install-metasploitable-on-virtual-box/#sthash.Tdh0WG8j.dpbs
Install openvas vulnerability scanning tool
https://www.kali.org/penetration-testing/openvas-vulnerability-scanning/
Useful apts to download from terminal:apt-get install preload
apt-get install bleachbit
apt-get install bum
apt-get install gnome-do
apt-get install apt-file
apt-get install scrub
apt-get install shutter
apt-get install figlet
apt-get install metagoofil
apt-get install whois
apt-get install dmitry
apt-get install recon-ng
apt-get install theharvester
apt-get install httrack