The Software Architects' Newsletter
January 2020
View in browser

Our thirtieth issue of the Architects’ Newsletter focuses on the connected topics of architecture styles and governance strategies. First, we aim to provide insight into how organizations are choosing effective architecture styles, whether this is based on functions, (micro)services, or a monolith. This will also include coverage of how organizations are supporting related cross functional requirements, such as security, scalability, and reliability. Second, we intend to explore related governance strategies, and share best practice on how to ensure the integrity and effectiveness of the chosen architecture styles.

We believe these topics are vitally important. They are visible at every stage of adoption in our latest Architecture and Design InfoQ Trends Report, from microservices and event-driven architecture, to the concept of "the architect as a technical leader". Understanding all the emerging architecture styles, patterns, and related approaches to governance and compliance is essential for a modern software architect.


Google Publishes Its BeyondProd Cloud-Native Security Model

In this summary of the recently published Google BeyondProd whitepaper, Sergio De Simone provides an overview of a proposed implementation and governance model for cloud-native security in a containerized world. Google’s model requires moving beyond the traditional perimeter-based security model, and instead leverages code-provenance and service identity as security cornerstones.

The BeyondProd white-paper sets a number of fundamental principles which complement the basic idea of no trust between services. Those include running code of known provenance on trusted machines, creating "choke points" to enforce security policies across services, defining a standard way to roll out changes, and isolating workloads. Google also provided a list of open-source software that can be used to implement its security model.

Managing eBay’s Vast Service Architecture Using Knowledge Graphs

eBay has recently discussed their "intelligent architecture" (INAR), which they are creating to build a sustainable service architecture. There are three major challenges that must be overcome, which stem from blindness, ignorance, and primitiveness. Blindness is the difficulty of observing how an architecture evolves, leading to inadequate dependencies, monoliths, redundant services, and duplicated functions. Ignorance is related to the lack of proper metrics, which are essential to improve operational efficiency. Finally, primitiveness is the absence of a correct approach to diagnostics, engineering, and automation, which should pave the way to the application of AI methods.

Knowledge graphs describe knowledge domains based on expert input, data, and machine learning algorithms. eBay is using an application/infrastructure knowledge graph to manage its vast service architecture and provide a better experience for the roughly 200M buyers visiting the site.

Gunnar Morling on Change Data Capture and Debezium

On this recent edition of the InfoQ Podcast, Wes Reisz talked with Gunnar Morling, software engineer at Red Hat about Debezium, an open-source distributed platform for change data capture (CDC). CDC is a set of software design patterns used to react to changing data in a data store. Used for things like internal changelogs, integrations, replication, and event streaming, CDC can be implemented leveraging queries or against the DB transaction log.

On the show, the two discussed the project and many of its use cases. Additionally, topics covered on the podcast include bootstrapping, configuration, challenges, debugging, and operational modes. The show wraps with long term strategic goals for the project.

Enterprise API Management: Q&A with Book Author Luis Weir

In this Q&A with Luis Weir, author of "Enterprise API Management", several topics related to the governance of API strategies are discussed:

  • Successful API programs focus on business outcomes first, before technology adoptions.
  • Poor quality data can negatively impact an API program, regardless of business and technology implementation.
  • Following an API Lifecycle that includes Planning, Design, Implementation, Publication, Operation, Consumption, Maintenance, and Retirement can improve the likelihood of success and provides prescriptive guidance to implementation and operational teams.

One of the conclusions is that defining API Architecture Patterns allows for consistency and expedites design decisions during project implementations.

QCon San Francisco Architectures Panel

Led by Randy Shoup, this QCon SF panel discussed the impact of software architecture on an organization’s success, and explored how big organizations differ from smaller disruptors. The panelists included a range of industry luminaries: Justin Ryan, playback edge engineer at Netflix, Anvita Pandit, software engineer at Google, Ben Sigelman, CEO at LightStep, Rob Zuber, a 20-year veteran of software startups, and Thierry Cruanes co-founder of Snowflake.

A recent InfoQ article by Ben Linders also provides additional context and recommendations for organizations that are in the process of scaling up: "Scaling Tech to Keep Building the Right Product During Hyper-Growth".

Architectures That Scale Deep—Regaining Control in Deep Systems

In this QCon SF video, Ben Sigelman talks about "Deep Systems" and their common properties. He re-introduced the fundamentals of control theory from the 1960s, and explored the original conceptualizations of observability and controllability. Sigelman used examples from Google and other organizations to illustrate how microservices and other deep systems have damaged engineers’ ability to observe software, and provides a series of strategies that can be used to regain control.

This topic was also explored by Michelle Krejci in a recent InfoQ podcast, "Moving to Microservices: Visualising Technical Debt, Kubernetes, and GraphQL".

Failure Modes and Building Resilient Systems: Adrian Cockcroft at QCon SF

Adrian Cockcroft, VP of cloud architecture strategy at AWS, recently shared his thoughts at QCon SF on how to produce resilient systems that operate successfully in spite of the presence of failures. He covers five techniques: concentrating on rapid detection and response, System Theoretic Process Analysis (STPA), lineage driven fault detection, no Single Point of Failure (SPOF) principle, and risk prioritization. In the presentation, he also shared what he considers are good cloud resilience patterns for building with a continuous resilience mindset.


Case Study

Decision Strategies for a Micro Frontends Architecture

Micro frontends is an architectural style for front end applications based on the concepts of microservices. Luca Mezzalira believes this is a style that will change the future of these applications, but there are associated challenges and architectural decisions that must be made. To help in mitigating these challenges and defining a suitable architecture for an application, he has created a decisions process for embracing a micro frontends architecture.

Mezzalira, VP of architecture at DAZN and author of the book Front-End Reactive Architectures, emphasized that every time an engineer uses a JavaScript framework, they have to adapt to the architectural decisions made in that framework. But they must also create an architecture that is a solid base for your application. During his work on creating a mental model for a micro frontends architecture, he has concluded that there are four pillars that must be decided upfront when starting to work on the architecture: Definition, Composition, Route, and Communication. He emphasized that each of these pillars plays a fundamental role in the outcome of the project. With these cornerstones set he believes that most decisions that emerge as the project progresses will be straightforward. He notes though that these basic decisions may have to be changed later in the project, and this may require a considerable effort in order to keep a coherent architecture.

Mezzalira noted that making these four decisions upfront in a project will provide a foundation and guidelines for future challenges in the project, and will simplify dealing with these challenges by limiting options. He introduced his decisions framework at JS-Poland, and the slides can be found in his blog post.

This is an excerpt from the InfoQ article "Decision Strategies for a Micro Frontends Architecture"

To get notifications when InfoQ publishes content on these topics follow "architecture," "microservices," "governance," and "compliance" on InfoQ.

Missed a newsletter? You can find all of the previous issues on InfoQ.

InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below.


Forwarded email? Subscribe and get your own copy.