Letting Change and Uncertainty Advance Your Software Architecture – InApps Technology 2022

CircleCI sponsored this post, in anticipation of Chaos Conf, Oct. 6-8, 2020.

The first lines of CircleCI’s codebase were written nearly nine years ago. Throughout those years, three themes emerged that have helped us become resilient in the face of the unknown: deferring the need to handle change, thinking like a product manager, and keeping your head up.

It’s Hard to Predict the Future

While the technical landscape is changing, your business and your organization are evolving as well, which both have a significant impact on your architectural decisions. But there are a lot of approaches you can use to design software and systems to be more resilient to change.

In the early days, the CircleCI application was a monolith that took a customer’s build with its associated data and pushed it into one of several LXC containers. Every container that we spun up was instantiated from the same image that contained everything we thought anyone would ever want in their test environment. In hindsight, this sounds like a terrible idea, but at the time, it was simple to maintain and it supported the needs of our early customers.

As time passed and our customer base grew, so did the diversity of their needs in terms of test environments. As we retooled the system to adapt to the changing market, we were in a position to ask, “How do we do this in a way that better positions us for incremental change?”

It sounds weird and grossly unfair to say this, but most of the time we don’t even know that we’re making a monumental design decision because the alternate path hasn’t shown up yet. How do you guard against this?

Defer, Defer, Defer

The correct solutions have a habit of revealing themselves if you can find a way to wait long enough. Technology gains traction or dies. If you chose a container orchestration engine in 2016, there’s a roughly 20% chance that you would have chosen Kubernetes. But by the beginning of 2018, almost 80% of companies were switching to Kubernetes.

So, deferring can be good. Although deferring to the point of creating a crisis is not.

Think Like a Product Manager

Your architecture is a leaky abstraction. While CircleCI is probably an extreme example of this case, due to the access our customers have to systems in our platform, there is always some implication for customers in the decisions you make in defining your architecture. Recognizing this impact and being able to coherently discuss approaches and alternatives is a huge asset that an engineer can bring to their project manager and team.

While we were witnessing all of this change in how our customers were building software, one thing we ignored for too long was the rise of Docker. In 2014, Docker launched something called libcontainer. They pulled apart access to the underlying system and created execution drivers, which soon led to the deprecation of the LXC driver. Disappointing, but it still worked. Then, Docker deleted all LXC support. That was bad.

Always Think About Users

As engineers and architects, we saw this coming. But frankly, it was under the radar of our product team. Our non-technical product folks didn’t necessarily understand the implications, but our engineers were talking about it every day. So, as an engineer, an architect, or a leader in technology, you need to be thinking about the direction of the product and working with your product managers to ensure that everyone understands the implications of technical choices.

Building a better understanding of the relationship between your architecture and the value achieved by your customers will put you in a position to make more informed decisions, about what and how to build as your business evolves. Then, you can focus on getting ahead of that evolution.

Keep Your Head Up

I’m Canadian and, unsurprisingly, I grew up playing ice hockey. Throughout my childhood, I spent an endless amount of time at practice just skating: forward, backward, turning, stopping, figure eights around cones. The idea was to make the fundamentals almost effortless, so that you can put your energy into the novel stuff.

In software, we have a bad tendency to make the fundamentals a lot harder than they should be, by adopting new technology that we think is going to be game-changing but ends up having only a modest upside — if any. While we’re putting this effort into our novel tech, we’re not focusing on how our systems need to evolve to meet the needs of our customers.

Change as a Driver

No company has ever won because of an amazingly novel or esoteric technology choice. There is an endless list, however, of companies that have won because they can move quickly and with agility, adapting to change as it happens. As my colleague Bear says, “If a tool isn’t helping, it’s not a tool, it’s a chore. Drop it.”

Unforeseen change is top-of-mind for so many of us right now, and it’s more obvious than ever that in business nobody can predict the future. It’s a safe bet that folks at GM didn’t start the year thinking about how to use their factories to make ventilators.

Being prepared to adapt in the face of change requires thinking about change as a driver in everything you do. Watch how your market is changing and reflect on how that impacts your architecture, so that you can make targeted, incremental improvements in its adaptability.

Feature image via Pixabay.

At this time, InApps Technology does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.