Life is Weird Right Now. As the COVID-19 pandemic in the United States and around the world has progressed our society has been strained and our methods of interaction have been tested.

What does it mean to take ownership? There are a lot of different ways the term owner is used in our society and within our organization.

When deciding how and when to reuse code, there are many tradeoffs to consider, each with varying degrees of consistency and indirection.

Modern applications increasingly interface with lots of external systems — third-party APIs, databases, message queues, etc. In some cases, we may have control over the shape of the data being transmitted, but in other cases we may be at the mercy of something else. If we're not careful, implementation details like the shape of the data and the naming of the fields can permeate throughout our code.

At Pluralsight we value responsible, autonomous teams and we architect our systems to that end. Here are the practices that we have chosen to make that possible.

If half or more of your code is handling edge cases, can you restructure your logic such that you don't have so many edge cases?

Before we get too technical in our look at migrating to .NET Core, however, let's take a moment to review the architectural choices we made before we tried to switch frameworks. A large part of the reason that we were able to migrate from .NET Framework so quickly was because we separated our application logic from the decisions made by the framework.

What sort of software architecture should you be implementing? When looking at industry trends, blogs, conference talks, and the like, it is easy to think that other companies have everything figured out. You'd be forgiven for wanting to copy the success that others are having. But there is no perfect architecture. Everything is a set of tradeoffs; there are only good and bad fits for a context.

When designing the architecture for an application or system of interrelated applications, it is essential to identify which quality attributes of the system are most important to the users, developers, and owners. Often this is done implicitly based on the experience and preferences of the various people participating in the project. When quality attributes are selected with intention and purpose, they help guide the design of the system. At Pluralsight, the quality attributes we focus on have evolved as the company has evolved.

Distributed systems are hard. They have a lot of moving parts with complex interactions and are inherently multi-threaded. To make them work, there is often some form of eventual consistency at play. Embracing this can make software development easier.

Coupling is an important concept in software development because it limits the ability of software to change. Temporal coupling is a kind of coupling where code is dependent on time in some way. It is particularly insidious because it is hard to detect unless you know what you are looking for.

When working in a distributed system, your overall system is comprised of discrete components which I will call "bounded contexts." Sometimes these bounded contexts have the need to be eventually consistent. In this article we will cover Out of Band Healing, a pattern that can be used to reduce temporal coupling when healing your server-side caches.

The software industry has always held a basic assumption that architecture is important. By association, the role of architect has always been esteemed important. But unfortunately, it isn't always clear what architecture is or what an architect's job should be.

In order for a technology organization to deliver products in support of a company's mission, decisions about which technology to use and how to use it must be made regularly. Creating a strategy for making these decisions is a problem for many organizations.

A crumbling code base will eventually prevent you from delivering value to your customers. What are some steps you can take to mitigate this risk?

APIs are an integral part of our distributed system here at Pluralsight. We use them to communicate between and within bounded contexts. One of our engineering team mottoes is "Be Explicit." To that end, we have a categorization system for the APIs we build and publish. This helps us know what the API is for and who should (and who shouldn't) be using it.

When we started on our journey towards bounded contexts, we wanted to maintain the small-team, focused, feel that we had enjoyed with as a single team supporting a monolith. One strategy we adopted was to limit our dependencies between the teams and, by extension, the different bounded contexts. We did not want to introduce temporal runtime coupling between components developed by different teams because that would reduce the autonomy of these teams and limit our ability to develop the products that we wanted to develop in the ways we wanted to develop them.

Microservices architectures are currently highly fashionable. The question of how small a microservice can be is asked regularly. Is micro even small enough? Can we build pico-services? At Pluralsight, we have chosen to go a different direction. We are focusing on team size...