SATURN 2018

Since 2015, Michael and George have facilitated a workshop on the Monday before the SATURN Conference to bring together a group of interested and enthusiastic participants to focus on a topic that is emerging as important for software architects. The topic for 2018 is Growing Great Software Designers and provides an opportunity to share what we have learned and are applying in our day jobs. Invited participants will hear and share stories of valiant attempts, grand strategies, energizing wins, and humbling defeats in this area. At the end of the workshop, the group will work to generalize and distill their discussions so that others can benefit from them. A debrief of the workshop will be presented on Thursday at 3:45 p.m.

Seems like all that’s heard about these days are Single Page Applications. Angular, React, Vue, Ember—they are transforming the way we think about the frontend. But what about securing these applications? This often tends to take a back seat to speed, animations, and other cool features of these frameworks. Between cookies, tokens, keeping users authenticated, and handling resource access, securing these apps can be tricky. It may even feel like a second page is needed (gasp!) for the authentication setup! But there is technology to create truly secure single-page applications. This tutorial walks through securing a Vue application, but the approach will apply to nearly any single-page application framework.

See the slides.
Watch the video.

Have you ever...

• been confused by an arrow in a box-and-line design diagram?
• read code for hours and yearned for a clear "big picture" explanation?
• found a debatable design decision and wished someone could explain the rationale behind it?

 

If your answer is yes to any of these questions, this talk has practical and valuable information for you. The goal is to discuss what information about a software architecture should be captured, so that others can successfully use it, maintain it, and build a system from it. Important takeaways from this talk include: how to document the architecture in multiple views; how to complement structural diagrams with sequence diagrams, statecharts and other behavior diagrams; how to record design decision in a simple and effective way.

Architecture is critical for business success. A solid architecture helps prevent defects and system failures. It helps a development effort save money and get quality products to the market faster. Most software-reliant systems are required to be modifiable and reliable. They may also need to be secure, interoperable, and portable. Data demonstrates that the most costly technical debt that organizations are struggling with results from making poor architectural choices and inadequately managing architectural decisions. How do you know whether your software architecture is suitable or at risk relative to its target system qualities? How do you assess whether it has technical debt? This Architecture Boot Camp session covers practical and proven architecture analysis and evaluation principles that should be incorporated into any software architecture evaluation process.  We will demonstrate these principles that identify risks early in the development lifecycle, using scenario-driven peer reviews in the context of the Architecture Tradeoff Analysis Method (ATAM), a tested process that has been used in many evaluations over the past 15 years. 

Espresso is LinkedIn's strategic distributed, fault-tolerant NoSQL database that powers many LinkedIn services. Espresso has a large production footprint at LinkedIn, with close to a hundred clusters in use, storing about 420 terabytes of source-of-truth (SoT) data and handling more than two million queries per second at peak load.

This talk discusses our strategy for migrating one of our internal services (Babylonia) from using Oracle to using Espresso. We will present an overview of the Espresso platform and its quality attributes that motivated the migration, as well as the particulars of how we accomplished the migration. Our core requirement was to keep Babylonia running uninterrupted throughout the migration process. These same concerns are common to many database migrations, not only at LinkedIn. The talk covers the steps we took to keep the service running through the transition without affecting our clients.

See the slides.
Watch the video.

FamilySearch is a large website that provides family history and genealogy features to users throughout the world for free. The Family Tree is one of its web applications that represents a giant, common pedigree that users can view and edit. Since all users can manage its public data, the Family Tree minimizes and eliminates the need for users to duplicate research and entry of common ancestors. It currently contains information about one billion persons, their relationships, and sources, and other memories that document each person’s genealogically meaningful data.

Family Tree’s expansive data—contrasted with the need for a high-performance user experience and its private project funding model—justifies swapping out its proprietary commercial relational database for open-source relational and NoSQL databases. In addition, the accessibility of cloud computing environments makes running Family Tree’s microservice-based architecture appealing. Therefore, FamilySearch undertook and recently completed a project to migrate Family Tree’s databases to open-source and NoSQL databases and transition them to a cloud-hosted computing environment.

This talk presents a detailed technical view of FamilySearch’s approach with its associated challenges and accomplishments of the Family Tree’s database transition and cloud-computing migration project.

See the slides.
Watch the video.

What if you have to replace an application processing hundreds of millions of documents per day for a government agency or health-care provider? Is it possible to choose microservices and still achieve the same stability as software that has been optimized continually over a 25-year life span? What are the factors to consider in defining the architecture to meet this challenge?

Join us as we discuss our experiences in the government and health-care industries, successfully using microservices to replace mainframe capabilities. How did we find our answers to these questions?

• What is the domain and problem to solve? When is it best to apply a microservice pattern, and when is it best to use other architecture patterns?

• What can we learn from how the mainframe application solved the problem?

• Where are the seams in the system? How did we use those? What application modernization patterns did we apply where, and why?

• What quality attributes were required? Could microservices using commodity or cloud platforms really do the job as fast and reliably as the mainframe, while introducing network communications overhead?

• What DevOps methods and tools did we apply to be confident that the microservices would really do the job and not risk the agency or enterprise mission?

See the slides.

Watch the slides.

Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, it can be all too easy to primarily focus on features and overlook software qualities, specifically those related to the architecture. Some believe that by simply following Agile practices—starting as fast as possible, keeping code clean, and having lots of tests—a good architecture will magically emerge. While an architecture will emerge, if there is not enough attention paid to it and the code, technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably.
It is essential to have a sustainable architecture that can evolve through the project lifecycle. Sustainable architecture requires ongoing attention, especially when there are evolving priorities, a lot of technical risk, and many dependencies. This talk presents a set of patterns that focus on practices for creating and evolving a software architecture while being Agile. These practices include a set of tools that allow teams to define “enough” architecture in the beginning of the project and to manage the state and the evolution of the architecture as the project evolves.
Watch the video.