There is a common misconception that architecture is thrown out the window when a team or organization is developing software in an agile fashion, but where does this myth stem from? Surely, there is some truth behind this thinking.
We’ll talk about some of the underlying assumptions that support this belief in order to build a common understanding of what it really means to be developing in an agile fashion. During the second half of this talk, we’ll move from the conceptual thinking into some practical suggestions from our experiences — what we’ve seen that works and highlight some practices to avoid. In the end, the audience will know how to bring architectural thinking into teams to support the higher level goals of application architecture.
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.
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:
Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business.
In this presentation we will discuss the reasons to evolve the architecture, some of the core principles that can help us develop in such a manner, and the ways to minimize the risk and succeed in creating a practical and useful architecture.
Creating code is easy, creating good code takes a lot of time, effort, discipline, and commitment. The code we create are truly the manifestations of our designs. Creating a lightweight design can help make the code more extensible and reusable.
In this presentation we will take an example oriented approach to look at some core design principles that can help us create better design and more maintainable code.
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.
Platform as a Service (Paas) is all the buzz today…. but why? What's the value proposition? Once you have decided that it is for you… what are your options?
This 2 session presentation is broken down in to 3 parts. The first is understanding why organizations on moving to PaaS and what to expects. The second and third part includes a walk through of PaaS options with part 2 being traditional PaaS and part 3 highlighting container based PaaS solutions.
We will conclude with a short discussion on getting PaaS like experiences without a PaaS and what that might look like.
Platform as a Service (Paas) is all the buzz today…. but why? What's the value proposition? Once you have decided that it is for you… what are your options?
This 2 session presentation is broken down in to 3 parts. The first is understanding why organizations on moving to PaaS and what to expects. The second and third part includes a walk through of PaaS options with part 2 being traditional PaaS and part 3 highlighting container based PaaS solutions.
We will conclude with a short discussion on getting PaaS like experiences without a PaaS and what that might look like.
Microservice architectures place great emphasis on autonomous product teams that develop and deploy equally autonomous services using decentralized release management, testing, and deployment strategies. I don’t have to wait on you to deploy my service, and you don’t have to wait on me. And yet the complexity associated with managing these large, distributed systems seems like it would demand even greater discipline and centralized coordination of testing activities. Fortunately, while greater discipline is in fact required, we don’t require the centralized coordination that would seem to destroy many of the benefits of embracing microservices. In this session will examine principles and practices that will help us develop an effective testing strategy for microservices.
Topics will include:
At the end of the day, an architect's primary job is to communicate. Not only do we need to make sure our teams understand the design of the system well enough to implement it, we must be able to explain our decisions to an audience that isn't impressed with how many TLAs you can rattle off in one sentence. Successful architects need to seamlessly transition from in depth technical conversations to budget meetings to discussions with end users adjusting the message to fit the audience.
While oral communication is key, good architects also spend a good deal of time putting pixel to screen via email, IM and various architectural documents we're expected to create. We need to write clearly and concisely while also knowing when the best course of action is to pick up the phone or walk to someone's desk.
In this talk, we'll explore the various methods that we as architects use to communicate with our stakeholders. We'll talk about knowing our audience, being able to present as well as how to run a good meeting. We'll discuss various patterns (and antipatterns) of presenting along with some concrete advice on how to do it better. At the end of the day, our job is to tell effectively tell a story - this talk will look at ways to do that.
Good architects are, almost by definition, good story tellers. And while good communication skills are vital to success as an architect, so too is an ability to constructively critique an architecture. In this talk, we'll explore why reviews are important and what it takes to perform them well. Additionally, we'll talk about the importance of planning and preparation in conducting a successful review.
Good architects are, almost by definition, good story tellers. And while good communication skills are vital to success as an architect, so too is an ability to constructively critique an architecture. In this talk, we'll explore why reviews are important and what it takes to perform them well. Additionally, we'll talk about the importance of planning and preparation in conducting a successful review.
Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.
In this workshop we will learn about some critical qualities of design and how to measure those. We will learn about these by working through some example code, refactoring it, and evaluating the design again at each stage of refactoring.
-Java 8 JDK or later version
-Your favorite IDE (Preferably IntelliJ IDEA Community Edition)
-git
Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.
In this workshop we will learn about some critical qualities of design and how to measure those. We will learn about these by working through some example code, refactoring it, and evaluating the design again at each stage of refactoring.
-Java 8 JDK or later version
-Your favorite IDE (Preferably IntelliJ IDEA Community Edition)
-git
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:
Just as developers use design patterns in software development, architects use well-defined architecture patterns to get a head start on defining the characteristics and shape of the architecture for a system. In this session we will explore some of the more common architecture patterns and use concrete real-world examples to demonstrate how the patterns work. I will also go over the pros and cons of each pattern and discuss how requirements and operational aspects can drive which patterns to use. Using the right architecture pattern for your system is critical, because as we all know, once in place the architecture is very hard to change.
Agenda:
Many of you may have an architect title, take on the role of an architect, or even aspire to be an architect, but are you thinking like an architect? Architectural thinking is learning to look at a problem or task from an architect's point of view. In this session we will look at many facets of architectural thinking, including how requirements shape the architecture, component-based thinking, how to make architecture decisions, and what feasibility and vitality means to an architect.
Agenda:
HotSpot provides a variety of garbage collectors with a variety of strengths and weaknesses. To get the most out of our applications, we need to pick the right garbage collector and design to take advantage of its strengths and avoid its
weaknesses.
In this presentation, you'll learn about criteria for picking a garbage collector, how to measure GC performance, and how to write code that works with rather than against the GC.
HotSpot provides a variety of garbage collectors with a variety of strengths and weaknesses. To get the most out of our applications, we need to pick the right garbage collector and design to take advantage of its strengths and avoid its
weaknesses.
In this presentation, you'll learn about criteria for picking a garbage collector, how to measure GC performance, and how to write code that works with rather than against the GC.
Today, we all benefit from the sophistication of modern compilers and hardware, but that extra complexity can also make it difficult to reason about performance.
In this talk, we'll examine some surprising performance cases and learn how to
use profiling and benchmarking tools to better understand our modern execution environments.
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.
There was a day when it was common to see the twitter fail whale! This imagine, extinct today, was the sign that scaling at twitter was broken in some way. What did Twitter do in order to increase their ability to scale, be more fault tolerant all while growing significantly. The answer is a move to Apache Mesos and leveraging container technology.
Google in 2009 had a top secret project we now know as the Google Borg project. That technology was reincarnated in an open source project out of UC Berkley known as Apache Mesos. Mesos has grown up significantly while at Twitter providing production tested solution for scaling applications and containers. In addition Solomon himself stated at DockerCon EU in December 2014 that Mesos is the only reliable way to scale docker in a production environment today.
This session is a hands on workshop. It is broken into 3 separate but related parts.
The first part is an 1.5 hour lecture of the challenges of the datacenter today. It will provide an overview of
* containers,
* static vs. elastic partitions
* schedulers.
The second part is a dive into docker with time for hands on labs. You will need access to docker for 1/2 of this session. We will have some discussion on the issues of running Java in a container with a focus on needs of production.
The third part will be on Apache Mesos and several different schedulers. We will discuss:
* different types of containers
* stateful service solution
* service discovery
* typical failures at twitter and how to avoid them
This also has a hands on component. You will need either:
* A Google Compute Engine account
* A AWS account
* Software local on your laptop to run vagrant
The last shorter part will include an overview of technologies on the horizon in this fast paced micro-services space.
There was a day when it was common to see the twitter fail whale! This imagine, extinct today, was the sign that scaling at twitter was broken in some way. What did Twitter do in order to increase their ability to scale, be more fault tolerant all while growing significantly. The answer is a move to Apache Mesos and leveraging container technology.
Google in 2009 had a top secret project we now know as the Google Borg project. That technology was reincarnated in an open source project out of UC Berkley known as Apache Mesos. Mesos has grown up significantly while at Twitter providing production tested solution for scaling applications and containers. In addition Solomon himself stated at DockerCon EU in December 2014 that Mesos is the only reliable way to scale docker in a production environment today.
This session is a hands on workshop. It is broken into 3 separate but related parts.
The first part is an 1.5 hour lecture of the challenges of the datacenter today. It will provide an overview of
* containers,
* static vs. elastic partitions
* schedulers.
The second part is a dive into docker with time for hands on labs. You will need access to docker for 1/2 of this session. We will have some discussion on the issues of running Java in a container with a focus on needs of production.
The third part will be on Apache Mesos and several different schedulers. We will discuss:
* different types of containers
* stateful service solution
* service discovery
* typical failures at twitter and how to avoid them
This also has a hands on component. You will need either:
* A Google Compute Engine account
* A AWS account
* Software local on your laptop to run vagrant
The last shorter part will include an overview of technologies on the horizon in this fast paced micro-services space.
Data integrity, security, recovery, privacy and regulatory compliance are essential attributes for enterprise implementation. Enterprise customers ask for transparency in how the vendors will provide security programs. Many questions need to be asked for any cloud implementation to policy makers, architects, coders, and testers.
In this presentation, we will explore data security and storage, privacy, and data compliance issues. We will explore the security management in the cloud. The presentation is useful for anyone starting from Executives to developers who are going to implement the Enterprise Applications in both private and public cloud.
Data integrity, security, recovery, privacy and regulatory compliance are essential attributes for enterprise implementation. Enterprise customers ask for transparency in how the vendors will provide security programs. Many questions need to be asked for any cloud implementation to policy makers, architects, coders, and testers.
In this presentation, we will explore data security and storage, privacy, and data compliance issues. We will explore the security management in the cloud. The presentation is useful for anyone starting from Executives to developers who are going to implement the Enterprise Applications in both private and public cloud.
Building 3rd party integrations require deep understanding of the business problems. You would not want to reinvent the wheel to solve common issues. In this talk we will explore different case studies with patterns which helps solves real world issues. We will start with exploring SOA patterns like Service host, Active service, Transactional service, Workflodize, Edge component. After that we will look at patterns related to performance, scalability and availability like Decoupled invocation, parallel pipelines, Gridable service, Service instance, Virtual Endpoint, and Service watchdog.
Lastly we will dive into security and manageability patterns like Secured message, Secured Infrastructure, Service firewall, Identify provider, and Service Monitor. Message exchange patterns include Request/Reply, Request/Reaction, Inversion of Communications and Saga. In Service consumer pattern we will explore Reservation, Composite front end and client/Server/Service. In Service integration patterns we will explore Service bus, Orchestration, Aggregated reporting. Lastly we will examine Service anti-patterns like Knot, Nanoservice, Transactional integration.
Building 3rd party integrations require deep understanding of the business problems. You would not want to reinvent the wheel to solve common issues. In this talk we will explore different case studies with patterns which helps solves real world issues. We will start with exploring SOA patterns like Service host, Active service, Transactional service, Workflodize, Edge component. After that we will look at patterns related to performance, scalability and availability like Decoupled invocation, parallel pipelines, Gridable service, Service instance, Virtual Endpoint, and Service watchdog.
Lastly we will dive into security and manageability patterns like Secured message, Secured Infrastructure, Service firewall, Identify provider, and Service Monitor. Message exchange patterns include Request/Reply, Request/Reaction, Inversion of Communications and Saga. In Service consumer pattern we will explore Reservation, Composite front end and client/Server/Service. In Service integration patterns we will explore Service bus, Orchestration, Aggregated reporting. Lastly we will examine Service anti-patterns like Knot, Nanoservice, Transactional integration.
Building 3rd party integrations require deep understanding of the business problems. You would not want to reinvent the wheel to solve common issues. In this talk we will explore different case studies with patterns which helps solves real world issues. We will start with exploring SOA patterns like Service host, Active service, Transactional service, Workflodize, Edge component. After that we will look at patterns related to performance, scalability and availability like Decoupled invocation, parallel pipelines, Gridable service, Service instance, Virtual Endpoint, and Service watchdog.
Lastly we will dive into security and manageability patterns like Secured message, Secured Infrastructure, Service firewall, Identify provider, and Service Monitor. Message exchange patterns include Request/Reply, Request/Reaction, Inversion of Communications and Saga. In Service consumer pattern we will explore Reservation, Composite front end and client/Server/Service. In Service integration patterns we will explore Service bus, Orchestration, Aggregated reporting. Lastly we will examine Service anti-patterns like Knot, Nanoservice, Transactional integration.
Building 3rd party integrations require deep understanding of the business problems. You would not want to reinvent the wheel to solve common issues. In this talk we will explore different case studies with patterns which helps solves real world issues. We will start with exploring SOA patterns like Service host, Active service, Transactional service, Workflodize, Edge component. After that we will look at patterns related to performance, scalability and availability like Decoupled invocation, parallel pipelines, Gridable service, Service instance, Virtual Endpoint, and Service watchdog.
Lastly we will dive into security and manageability patterns like Secured message, Secured Infrastructure, Service firewall, Identify provider, and Service Monitor. Message exchange patterns include Request/Reply, Request/Reaction, Inversion of Communications and Saga. In Service consumer pattern we will explore Reservation, Composite front end and client/Server/Service. In Service integration patterns we will explore Service bus, Orchestration, Aggregated reporting. Lastly we will examine Service anti-patterns like Knot, Nanoservice, Transactional integration.
Ever wonder how to step back and analyze the architecture from a different point of views? In this talk, we will explore architectural principles, concerns, and communication. We will discover a core set of architectural principles, which can be used for evaluating the decisions throughout the project life cycle. Then we will examine concerns for the projects by exploring Availability, Scalability, Extensibility, Repeatability, Compatibility, Sustainability, Security and Third party integrations.
Ever wonder how to step back and analyze the architecture from a different point of views? In this talk, we will explore architectural principles, concerns, and communication. We will discover a core set of architectural principles, which can be used for evaluating the decisions throughout the project life cycle. Then we will examine concerns for the projects by exploring Availability, Scalability, Extensibility, Repeatability, Compatibility, Sustainability, Security and Third party integrations. Lastly, we will explore how the architecture comes to life by understanding the principles and concerns and performing effective communication. We will explore different communication methods like Domain model, process diagram, the context diagram, UI mocks, and Logical Architecture Diagram. We will explore RAID modeling to define Risks, Assumptions, Issues, and Dependencies.
We will explore
1) Project Skills: Partnership, Discovery, Conceptualization, Estimation, Management
2) Technology Skills: Platform Development, Architectural Perspectives, Governance, Know-how
3) Visionary Skills: Technology Innovation, Strategic Road mapping, Entrepreneurial Execution
In this talk, we will explore different cloud computing architecture design patterns blueprints and how you can take advantage of them. We will study cloud patterns for Private and Hybrid cloud deployments, Cloud Services, Common cloud management platforms, Security, Cloud governance, resiliency, Performance, and consumability.
In this talk, we will explore different cloud computing architecture design patterns blueprints and how you can take advantage of them. We will explore cloud patterns for Private and Hybrid cloud deployments, Cloud Services, Common cloud management platforms, Security, Cloud governance, resiliency, Performance, and consumability.
Few patterns we will explore are as follows:
Sharing, Scaling and Elasticity Patterns
Reliability, Resiliency and Recovery Patterns
Data Management and Storage Device Patterns
Cloud Service and Storage Security Patterns
Network Security, Identity & Access Management and Trust Assurance Patterns
A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.
ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.
The first part of the Continuous Delivery workshop covers the differences between continuous integration, continuous deployment, and continuous delivery). It also introduces the deployment pipeline_, along with usage, patterns, and anti-patterns. This part concludes with some applied engineering principles.
Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.
The first part of the workshop describes the technical differences between related topics such as continuous integration, continuous deployment, and continuous delivery. At the heart of the workshop is a pattern called the deployment pipeline, which involves the creation of a living system that models your organization's value stream for delivering software. I discuss the various stages, how triggering works, patterns and anti-patterns, and how to pragmatically determine what “production ready” means. This session also covers some agile principles espoused by the Continuous Delivery book, including new perspectives on things like developer workstations and configuration management.
Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.
Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.
Continuous Delivery relies on a variety of interlocking engineering practices to work efficiently; this session covers three related topics. First, I cover the role of testing and the testing quadrant, including the audience and engineering practices around different types of tests. I also cover some best practices around testing, including testing ratios, code coverage, and other topics. Second, I specifically cover version control usage and offer alternatives to feature branching like toggle and branch by abstraction. Generally, I talk about building synergistic engineering practices that complement rather than conflict one another. In particular, I discuss why feature branching harms three other engineering practices and describe alternatives. Third, I describe some incremental release strategies, along with their impact on other stages of project lifecycle.
Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure. Second, I discuss how to incorporate databases and DBA's into the Continuous Integration and Continuous Delivery process.
Releasing software to actual users is often a painful, risky, and time-consuming process. This workshop sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers and operations, delivery teams can get changes released in a matter of hours—sometimes even minutes—no matter what the size of a project or the complexity of its code base. The workshop materials are derived from the best selling book Continuous Delivery and creating in collaboration with the authors and other of my ThoughtWorks colleagues. Continuous Delivery details how to get fast feedback on the production readiness of your application every time there is a change—to code, infrastructure, or configuration.
Two big stumbling blocks for Continuous Delivery adaptation are interactions with operations and the keepers of data. First in this session, I cover operations, DevOps, and programmatic control of infrastructure using tools like Puppet and Chef. I also discuss the explosion of tool alternatives in this space, and cover some current-day best practices. Second, I discuss how to incorporate databases and DBA's into the Continuous Integration and Continuous Delivery process. This includes database migrations, strategies for enhancing collaboration between application development and data, and database refactoring techniques.
Many software developers point their career towards ascending to the gilded rank of Architect…but what does it mean to actually be one? While many of us labor under false pretense of abject technical decision making, the reality is often very different. You'll code less, spending more time on activities that lack an objective green/red bar. But you'll also an opportunity to impact far more than one project.
In this talk, I'll speak to my own journey. We'll touch on influencing coworkers, the importance of communication and the importance of cup of coffee.
Many software developers point their career towards ascending to the gilded rank of Architect…but what does it mean to actually be one? While many of us labor under false pretense of abject technical decision making, the reality is often very different. You'll code less, spending more time on activities that lack an objective green/red bar. But you'll also an opportunity to impact far more than one project.
In this talk, I'll speak to my own journey. We'll touch on influencing coworkers, the importance of communication and the importance of cup of coffee.
Modularity is coming to the Java platform! Java 9 will introduce the Jigsaw module system. OSGi is here today. But don’t wait to start designing modular software. Contrary to popular belief, you don't need a framework or a new runtime to start building modular software applications. You can start today. Learn how!
In this session, we'll examine what it means to develop modular software on the Java platform. We'll examine the goals and benefits of modular software, and explore the patterns of modular architecture that help us develop modular software systems. With just a few easy steps, we'll see how to transform our software from a huge monolith to an extensible system of collaborating software modules. By examining an existing software system, we'll see first hand how we can increase software modularity with minimal disruption. You'll walk away not just with a much deeper understanding of the benefits of modular software, but also a migration roadmap for refactoring existing applications to increase their modularity. In other words, you'll see how to get ready today for the application platform of tomorrow.
The Web is changing faster than you can imagine and it is going to continue to do so. Rather than starting over from scratch each time, it builds on what has succeeded already. Webs of Documents are giving way to machine-processable Webs of Information. We no longer care about data containers, we only care about data and how it connects to what we already know.
Roughly 25% of the Web is semantically marked up now and the search engines are indexing this information, enriching their knowledge graphs and rewarding you for providing them with this information.
In the past we had to try to convince developers to adopt new data models, storage engines, encoding schemes, etc. Now we no longer have to worry about that. Rich, reusable interface elements like Web Components can be built using Semantic Web technologies in ways that intermediate developers don’t have to understand but end users can still benefit from. Embedded JSON-LD now allows disparate organizations to communicate complex data sets of arbitrary information through documents without collaboration.
Perhaps the concepts of the Semantic Web initiative are new to you. Or perhaps you have been hearing for years how great technologies like RDF, SPARQL, SKOS and OWL are and have yet to see anything real come out of it.
Whether you are jazzed or jaded, this workshop will blow your mind and provide you with the understanding of a technological shift that is already upon us.
In this workshop, we will:
Explain the Web and Web architecture at a deeper level
Apply Web and Semantic Web technologies in the Enterprise and make them work together
Integrate structured and unstructured information
Create good, long-lived logical names (URIs) for information and services
Use the Resource Description Framework (RDF) to integrate documents, services and databases
Use popular RDF vocabularies such as Dublin Core, FOAF
Query RDF and non-RDF datastores with the SPARQL query language
Encode data in documents using RDFa and JSON-LD
Create self-describing, semantic Web Components
Model and use inferencing with the Web Ontology Language (OWL)
The Web is changing faster than you can imagine and it is going to continue to do so. Rather than starting over from scratch each time, it builds on what has succeeded already. Webs of Documents are giving way to machine-processable Webs of Information. We no longer care about data containers, we only care about data and how it connects to what we already know.
Roughly 25% of the Web is semantically marked up now and the search engines are indexing this information, enriching their knowledge graphs and rewarding you for providing them with this information.
In the past we had to try to convince developers to adopt new data models, storage engines, encoding schemes, etc. Now we no longer have to worry about that. Rich, reusable interface elements like Web Components can be built using Semantic Web technologies in ways that intermediate developers don’t have to understand but end users can still benefit from. Embedded JSON-LD now allows disparate organizations to communicate complex data sets of arbitrary information through documents without collaboration.
Perhaps the concepts of the Semantic Web initiative are new to you. Or perhaps you have been hearing for years how great technologies like RDF, SPARQL, SKOS and OWL are and have yet to see anything real come out of it.
Whether you are jazzed or jaded, this workshop will blow your mind and provide you with the understanding of a technological shift that is already upon us.
In this workshop, we will:
Explain the Web and Web architecture at a deeper level
Apply Web and Semantic Web technologies in the Enterprise and make them work together
Integrate structured and unstructured information
Create good, long-lived logical names (URIs) for information and services
Use the Resource Description Framework (RDF) to integrate documents, services and databases
Use popular RDF vocabularies such as Dublin Core, FOAF
Query RDF and non-RDF datastores with the SPARQL query language
Encode data in documents using RDFa and JSON-LD
Create self-describing, semantic Web Components
Model and use inferencing with the Web Ontology Language (OWL)
Encryption is a powerful tool for privacy. At least that is what we're meant to think.
If you consider encryption to be a black box of magic, you should probably attend this talk.
If you think encryption will protect your secrets, you should probably attend this talk.
If you have (or haven't) been following the news, you should probably attend this talk.
The truth is, encryption can be an effective way of making it harder for people to steal your secrets. But it isn't magical, it isn't fool proof and, depending on how you are using it, may be completely useless. It is a hard topic that we'll only touch the surface on, but there are very few topics that are more crucial for our industry and profession to understand better than encryption. You don't have to understand the math (although that will help), but you do have to understand what it will and won't do for you*.
*and how implementations of it may have been intentionally compromised
This session will focus on the soft skills that are needed by software architects and pretty much any technical person. One of the chief things that changes when you go from being a tech lead to an architect is the need for soft skills. For many architects, it’s not the technology related areas that give you problems, but people related areas – at least this was the case for case for me.
Come to this session if you want to learn some tricks and tips for how to better interact others – especially executives.
This session will focus on the technical skills that are needed by software architects. The role of an architect is not always clear – we often get referred to as glue – because we fill in wherever we are needed.
If you are wondering what an architect should be doing – this presentation will give tips and tricks for being an architect from ideation through product delivery.
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
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!
Early releases of Java performed poorly, but those issues largely disappeared long ago with the introduction of HotSpot. However, much of the performance advice for Java persists through hearsay from those early days.
In this talk, we'll forget the hearsay and take an objective look using benchmarking and profiling tools to find out which optimizations matter today and just as importantly those that don't.
With business models and business needs changing so rapidly, an adaptable architecture is critical to allow systems to cope with change. Historically, adaptability has been sought through anticipating the places where a system must be adaptable and through various architectural approaches. However, recent experiences have shown these approaches to be inadequate, at least as currently practiced.
This talk presents some principles of evolutionary architecture that allow systems to respond to change without needing to predict the future. We then describe three approaches that realize these principles and discuss how these approaches support adaptability of systems in an evolutionary way.
While micro-services are all the rage, they need to be approached with caution. Using the techniques of evolutionary architecture, coupled with continuous delivery, allows for the micro-services architecture and its companion data architecture to evolve.
This talk explores the relationship between these three concepts, focusing on how they all support each other in the creation of complex systems.
There is widespread acceptance that software development using Agile methods works well. However, there are still areas of software development organizations that view their roles or mandates as incompatible with Agile methods.
This talk addresses the legitimate role of an Enterprise Architect and provides concrete recommendations on how Architects can work with Agiledevelopment teams to accomplish their objectives. Topics will include concerns about data architecture, addressing the “ilities”, and why evolutionary architecture works.
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:
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.
Inspired by success stories from companies such as Amazon and Netflix, many organizations are moving towards microservice architectures at a brisk pace. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.
Microservice architecture is important because it’s the first architecture to fully embrace the Continuous Delivery and DevOps revolutions. In this session, I cover the motivations for building a microservice architecture (including making the distinction between “regular SOA” and microservices), some considerations you must make before starting (such as transactions versus eventual consistency), how to determine service partition boundaries, and ten tips to dowse you towards success. I also discuss the role of polyglot development, enterprise governance, how data and databases fit into this new world, and tooling to help ensure consistency between core services like logging and monitoring. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.
This session will focus on the big data skills that are needed by software architects. The area of big data is dealing with a massive expansion of tools and technologies. Finding the right people, tools and technologies can a bit of a challenge.
This presentation will focus on the skills needed for navigating the big data waters from an architectural perspective.
As we move toward microservices, we learn to properly decompose not only our behavior model, but also our data model into bounded contexts. This data decomposition is not without consequences. By placing strict boundaries around ownership of domain concepts, we make it more difficult to refer to concepts that naturally want to cross these boundaries. How do we “denormalize” these entities effectively? How do we keep these representations in sync? What do transactions look like? How do we ask BIG questions that span multiple contexts? These are the questions that we’ll dive into in this session.
Topics to include:
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.
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.
Modern applications are changing as we embrace the engineering practices associated with Continuous Delivery and DevOps, migrate our applications to modern cloud platforms, elastically scale applications with the dynamics of customer demand, and embrace microservices architectures. The Twelve-Factor App is a collection of application development patterns developed by Heroku engineers that aim to support these types of architectural and cultural change.
The 12 Factors are:
We’ll examine how to implement these factors using JVM “microframeworks” like Spring Boot and Dropwizard.
As a web application developer, most of the focus is on the user stories and producing business value for your company or clients. Increasingly however the world wide web is more like the wild wild web which is an increasingly hostile environment for web applications. It is absolutely necessary for web application teams to have security knowledge, a security model and to leverage proper security tools.
This training workshop on security will provide an overview of the security landscape starting with the OWASP top ten security concerns with current real world examples of each of these attack vectors. The first session will consist of a demonstration and labs using hacker tools to get an understanding of how a hacker thinks. It will include a walk through of the ESAPI toolkit as an example of how to solve a number of these security concerns including hands-on labs using the OWASP example swingset.
The workshop will include several hands on labs from the webgoat project in order to better understand the threats that are ever so common today.
Attendees will come away with the following skills / capabilities:
Don't be the weakest link on the web!
As a web application developer, most of the focus is on the user stories and producing business value for your company or clients. Increasingly however the world wide web is more like the wild wild web which is an increasingly hostile environment for web applications. It is absolutely necessary for web application teams to have security knowledge, a security model and to leverage proper security tools.
This training workshop on security will provide an overview of the security landscape starting with the OWASP top ten security concerns with current real world examples of each of these attack vectors. The first session will consist of a demonstration and labs using hacker tools to get an understanding of how a hacker thinks. It will include a walk through of the ESAPI toolkit as an example of how to solve a number of these security concerns including hands-on labs using the OWASP example swingset.
The workshop will include several hands on labs from the webgoat project in order to better understand the threats that are ever so common today.
Attendees will come away with the following skills / capabilities:
Don't be the weakest link on the web!
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!
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.
Architecting and developing user interfaces used to be relatively easy, pick a server side framework, define a standard monitor resolution and spend your days dealing with browser quirks. But today, the landscape presents us with a plethora of screen sizes and resolutions covering everything from a phone to a tablet to a TV. How does a team embrace this brave new world knowing that the future will introduce even more volatility to the client space?
This talk will walk you through this brave new world. We'll discuss the deluge of devices the typical application must deal with today as well as looking at the plethora of client side rendering technologies. This isn't strictly a front end problem though, we need to reconsider how we've built our server side solutions as well; modern applications rely on RESTful web services delivering data to a diverse set of clients. The development landscape has changed, this talk will prepare you to face these challenges.
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.
Functional programming is receiving much attention recently. Most mainstream languages, including C++, Java, and C# now support lambda expressions and functional style. Why is there a sudden interest in adapting something that was largely ignored for decades? What are the technical reasons, how do we benefit, in what ways can using these techniques make our applications better and our development efforts easier as well?
In this technical presentation we will learn about the technical underpinnings of functional programming, the fundamental problems they address, and the large impact of those on application development
Technology changes, it's a fact of life. And while many developers are attracted to the challenge of change, many organizations do a particularly poor job of adapting. We've all worked on projects with, ahem, less than new technologies even though newer approaches would better serve the business. But how do we convince those holding the purse strings to pony up the cash when things are “working” today? At a personal, how do we keep up with the change in our industry?
This talk will explore ways to stay sharp as a software professional. We'll talk about how a technology radar can help you stay marketable (and enjoying your career) and how we can use the same technique to help our companies keep abreast of important changes in the technology landscape. Of course it isn't enough to just be aware, we have to drive change - but how? This talk will consider ways we can influence others and lead change in our organizations.
Architecture does more than describe the system as it is. It also establishes incentives, cost structures, organizational patterns and a marketplace for ideas upon which various players will innovate. One of the reasons the Web has been so successful is because it does this in a way that encourages a wide participation from varied players due to the nature of the architecture upon which it is built: The Internet.
This talk will walk through the design of the Internet Architecture and how it yields the flexibility to innovate to a wide collection of players including VC-backed internet startups, college students working out their room and companies targeting specific types of customers. The choices that have been (and will be) made have enormous implications on how the Internet and Web can be used and evolve and who controls them.
Come think deeply about one of the most important software architectural designs that has ever been designed and why we must protect it.
In this 2 part session (each part 1.5 hours), I will deep dive into the deployment architectures of large scale Java platforms. I will first set the context of the discussion around what problems exist in our industry before I proceed to lay out the concept of platform engineering and its renaissance among the developer/deployment community today. It is astonishing to see that majority of new application platforms being rolled out today miss their SLA, and 90% of these systems require 2X more hardware than what they actually need in order to run. This is an industry suffering from a double whammy, where you spend 2X on hardware and still miss your SLA; clearly something is completely broken. Now prior to delving into these new concepts, such as Microservices, Cloud Native, 3rd Platform, & 12Factor App, it is imperative to first understand the problem at hand before we apply these deployment architectural patterns. I will layout the definition of Platform Engineering as the software engineering science needed in order to understand how to precisely deploy application components onto application runtimes and how in-turn one should appropriately map the application runtimes onto the infrastructure that it needs. With this knowledge you should be able to more effectively decide when to scale-out (by how many instances), and when to scale-up.
We will conclude with covering various GC tuning techniques, and how to best build platform engineered systems; in particular, the focus will be on tuning large scale JVM deployments and various sizing techniques. While predominantly most enterprise class Java workloads can fit into a scaled-out set of JVM instances of less than 4GB JVM heap, there are workloads in the in memory database space that require fairly large JVMs. We will look at various Java platform scales, some holding a few large JVMs of 90GB heap space – servicing large multi-terabyte in memory DBs, while other platforms are of thousands of JVM instances of less than 4GB heap space on each, typical of web-app deployments. We will also take a close look at an example XYZCars.com, where a microservices approach was designed and deployed. The discussion will cover how to more correctly deploy microservices, without causing fragmentation of scale, and hence without impeding performance. In this session, we take a deep dive into the issues and the optimal tuning configurations for tuning large JVMs in the range of 4GB to 360GB, using the GC tuning recipes that were gained over the past 15 years of GC tuning engagements. You should be able to walk away with the ability to commence a decent GC tuning exercise on your own, and your way to platform engineer your application runtimes to feasibly meet your SLAs.
In this 2 part session (each part 1.5 hours), I will deep dive into the deployment architectures of large scale Java platforms. I will first set the context of the discussion around what problems exist in our industry before I proceed to lay out the concept of platform engineering and its renaissance among the developer/deployment community today. It is astonishing to see that majority of new application platforms being rolled out today miss their SLA, and 90% of these systems require 2X more hardware than what they actually need in order to run. This is an industry suffering from a double whammy, where you spend 2X on hardware and still miss your SLA; clearly something is completely broken. Now prior to delving into these new concepts, such as Microservices, Cloud Native, 3rd Platform, & 12Factor App, it is imperative to first understand the problem at hand before we apply these deployment architectural patterns. I will layout the definition of Platform Engineering as the software engineering science needed in order to understand how to precisely deploy application components onto application runtimes and how in-turn one should appropriately map the application runtimes onto the infrastructure that it needs. With this knowledge you should be able to more effectively decide when to scale-out (by how many instances), and when to scale-up.
We will conclude with covering various GC tuning techniques, and how to best build platform engineered systems; in particular, the focus will be on tuning large scale JVM deployments and various sizing techniques. While predominantly most enterprise class Java workloads can fit into a scaled-out set of JVM instances of less than 4GB JVM heap, there are workloads in the in memory database space that require fairly large JVMs. We will look at various Java platform scales, some holding a few large JVMs of 90GB heap space – servicing large multi-terabyte in memory DBs, while other platforms are of thousands of JVM instances of less than 4GB heap space on each, typical of web-app deployments. We will also take a close look at an example XYZCars.com, where a microservices approach was designed and deployed. The discussion will cover how to more correctly deploy microservices, without causing fragmentation of scale, and hence without impeding performance. In this session, we take a deep dive into the issues and the optimal tuning configurations for tuning large JVMs in the range of 4GB to 360GB, using the GC tuning recipes that were gained over the past 15 years of GC tuning engagements. You should be able to walk away with the ability to commence a decent GC tuning exercise on your own, and your way to platform engineer your application runtimes to feasibly meet your SLAs.
Sooner or later you probably will be working on a projects with words like “Data Science”, “Machine Learning”, “Big Data” attached to them. This talk will help you deliver these projects successfully by reviewing the key items you need to consider when incorporating analytical solutions into shipping products.
This talk will focus on answering these questions at scale:
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.
The drive to continuous delivery, micro services and PaaS includes the need to auto scale and potentially auto provision services. This session will identify the legacy thinking of a statically partitioned world and drive to the scalable world of Apache Mesos.
This session will look at the failings of the many of today's cloud technology, identify the goals we have and look into the tooling of how to get there. In this session we will look at:
This session will be packed with demonstrations.
We all have an innate sense of what's possible. Not only is this how magicians fool you, but it might also be what's holding you back.
In this session Michael Carducci shares how he applied lessons learned in his career as a professional magician to his “day-job” as a software engineer.
Magicians have a simple process for creating new material; think of the most impossible thing you can imagine, the engineer a way to make it possible. Michael has been engineering solutions to “impossible” problems for nearly 20 years and this has given him a unique perspective on dealing with challenges in all aspects of his life.
This talk combines illusion, anecdotes and real-world examples to help identify and overcome your mental obstacles.
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.
Concourse (http://concourse.ci/) is a CI system composed of simple tools and ideas. Concourse can express entire pipelines, integrating with arbitrary resources, or it can be used to execute one-off tasks, either locally or in another CI system. Concourse attempts to reduce the risk of adoption by encouraging practices that keep your project loosely coupled to the details of your continuous integration infrastructure.
Concourse optimizes around the following principles:
During this session we'll learn the simple key concepts from which Concourse pipelines are constructed. We'll understand how to deploy a local Concourse cluster using Vagrant as well as a scalable Concourse cluster to your cloud of choice using Cloud Foundry BOSH. Finally, we'll look at basic and advanced examples of pipelines for Java projects.
Instant messaging, video conferencing, online audio calls and file sharing have become a crucial part of every day life. Until recently, this required the use of a centralized service. Now, with the WebRTC Standard from the W3C, we have the ability to communicate through our browsers without relying on third parties or plugins.
This talk will introduce you to the WebRTC standards from the World Wide Web Consortium (W3C). This includes:
When talking about finding security defects we first think of security testing and static analysis of the code. Although, penetration testing and secure code review can uncover many types of security issues in an application, there are gaps that simply cannot be found with these traditional analysis techniques. The interactions between the different systems are beyond the code review level and the complex interconnections are often not reachable from the penetration tester’s point of view. Discovering weaknesses in the design of a system is the specific goal of threat modeling. Organizations benefit from this software design analysis because they can perform it without code to discover potential vulnerabilities early in the development cycle.
This talk will describe one of the popular threat modeling methodologies and follow its process of identifying the assets, security controls, and threat agents for a given system, and then creating a prioritized list of attacks. Security analysts together with system architects can then propose appropriate mitigations to be implemented by the team.
One of the leading application security vulnerabilities, cross-site scripting (XSS), has been consistently found in many corporate applications, regardless of traditional defense techniques, such as input validation and output encoding. Knowing the number of such vulnerabilities in the organization’s applications is only half the issue. To understand the real risk, it is important to know how many of these vulnerable applications actually get attacked on the day to day basis, and which specific instances of vulnerabilities are being exploited. Such information will answer the questions like: is a certain framework being exploited most of the time, because it has not been patched? Or is it an issue in the custom code that has not gone through the security code review process? Content Security Policy (CSP) is a new HTML5 technology that allows organizations not only protect their applications from cross-site scripting, ensure that the content of the site, such as audio, video, images, fonts, is only loaded from approved locations, but also to get reports on every violation of the policy, such as cross-site-scripting attempts.
This talk will discuss how to best implement Content Security Policy on the organization’s web sites and how to obtain data on the policy violations and attacks. We will first cover the basics of Content Security Policy, how the policy is configured, the possible security issues CSP may have, how it can be applied to an existing application or an application written from scratch. Then we will discuss the reporting mechanism, types of data returned in the violation reports, methods of aggregation, and browser support. At the end, existing report aggregation and analysis tools will be described, together with examples of existing CSP policies implemented by major social media companies.
Client-side JavaScript can get out of control easily. This session explores practical architectural solutions targeted to make your client-side JS easier more reliable, easier to develop and more performant.
Front-end developers love their JavaScript. It is sleek, powerful and very cool. But how do you architect a strategy for dealing with the (tens of) thousands of lines of code your developers will eventually write not to mention the countless JavaScript libraries your developers want to add to your projects? How do you divvy up the code and organize things in a logical way so that you can find specific code easily? What about namespacing concerns? File management and dynamic loading? Writing libraries for use on both client and server? What tools are available to help you address some of these concerns?
Join us as we explore these and other JavaScript client-side architecture dilemmas.
There is no doubt that Angular is now mainstream. That made it easier for you to convince the powers-that-be to let you select Angular for your project. You've done a small but successful POC and now your 'big' project has been green lighted to kick off next month. Your team is jazzed but as you start to plan out the real work, you begin to realize that there are many aspects inherrent to large Angular projects that have no 'out of the box' answers.
Stack overflow can only contribute 'it depends' answers that leave you more confused than before you read them. And now the panic starts to seep in, killing your buzz. Never fear! In this session, we will explore a variety of ways to architect your project and structure your code. We will look at the pros and cons of each option and discuss when trigger points for choosing each.
Server-side JavaScript is everywhere these days! This session explores some practical architectural techniques and tools that can make your server-side JS easier to develop, test, manage and deploy.
Server-side JavaScript is part of almost every modern web app's tech stack. It is a powerful, versatile tool you can leverage to solve virtually every problem you can image. Its versatility and popularity guarantees that, once introduced to your organization, you will soon have a plethora of server-side JS applications to manage. This poses a number of problems for an enterprise architect: How do I maximize reuse across projects? How do I even enable reuse in JS? Are there best practices I should follow? How do I manager 3rd party libraries? Are there coding practices, patterns or standards I should adopt and champion across my teams? What about name spacing concerns? What about packaging and deployment? What if I write libraries for use on both client and server? What tools are available to help you address some of these concerns?
Join us as we explore these and other JavaScript server-side architecture conundrums.
The single most important tool in any developers toolbox isn't a fancy IDE or some spiffy new language - it's our brain. Despite ever faster processors with multiple cores and expanding amounts of RAM, we haven't yet created a computer to rival the ultra lightweight one we carry around in our skulls - in this session we'll learn how to make the most of it. We'll talk about why multitasking is a myth, the difference between the left and the right side of your brain, the importance of flow and why exercise is good for more than just your waist line.
The single most important tool in any developers toolbox isn't a fancy IDE or some spiffy new language - it's our brain. Despite ever faster processors with multiple cores and expanding amounts of RAM, we haven't yet created a computer to rival the ultra lightweight one we carry around in our skulls - in this session we'll learn how to make the most of it. We'll talk about why multitasking is a myth, the difference between the left and the right side of your brain, the importance of flow and why exercise is good for more than just your waist line.
“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.
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.
Our technical world is governed by facts. In this world Excel files and technical diagrams are everywhere, and too often this way of looking at the world makes us forget that the goal of our job is to produce value, not to fulfill specifications.
Feedback is the central source of agile value. The most effective way to obtain feedback from stakeholders is a demo. Good demos engage. They materialize your ideas and put energies in motion. They spark the imagination and uncover hidden assumptions. They make feedback flow.
But, if a demo is the means to value, shouldn’t preparing the demo be a significant concern? Should it not be part of the definition of done?
That is not even all. A good demo tells a story about the system. This means that you have to make the system tell that story. Not a user story full of facts. A story that makes users want to use the system. That tiny concern can change the way you build your system. Many things go well when demos come out right.
Demoing is a skill, and like any skill, it can be trained. Regardless of the subject, there always is an exciting demo lurking underneath. It just takes you to find it. And to do it.
In this session we will get to exercise that skill.
Software has no shape. Just because we happen to type text when coding, it does not mean that text is the most natural way to represent software.
We are visual beings. As such we can benefit greatly from visual representations. We should embrace that possibility especially given that software systems are likely the most complicated creations that the human kind ever produced. Unfortunately, the current software engineering culture does not promote the use of such visualizations. And no, UML does not really count when we talk about software visualizations. As a joke goes, a picture tells a thousand words, and UML took it literally. There is a whole world of other possibilities out there and as architects we need to be aware of them.
In this talk, we provide a condensed, example-driven overview of various software visualizations starting from the very basics of what visualization is.
Visualization 101:
How to visualize
What to visualize
Interactive software visualizations
Visualization as data transformation
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: