Agility Vs. Complexity in Cloud-Native Applications

One of the main motivations for using cloud-native application methodologies is to simplify our applications and their infrastructures. Cloud-native methodologies are designed around creating larger and more sophisticated applications without unnecessarily increasing application complexity.

And central to everything is agility. Our companies must be agile to meet and exceed the expectations of our customers, our shareholders and the abilities of our competitors. Companies without agility are doomed competitively.

Simplicity … and agility. We need them both. Yet, there is a vicious cycle that works against this philosophy.

In a previous article, I discussed the tradeoffs between choice and complexity in building cloud-native applications. As a result, we tend to give our cloud-native service teams the ability to make their own decisions. By giving teams the ability to design, develop and operate their services in ways that make sense to them, you increase their power. After all, teams that make their own decisions are innovative teams.

However, that increased choice came with a cost—complexity. As you enable teams to make independent decisions, they begin to make independent decisions—independently. The result is more complexity in your IT infrastructure. Complexity leads to a reduction in the ability to innovate rapidly. Complexity leads to stagnation. It’s the opposite of agility.

For a company to be agile, we must allow teams to make the necessary choices to accomplish their goals. Yet agility requires choice, which leads to complexity. As a result, complexity leads to reduced agility.

It’s a vicious cycle.

How can we keep agility in our company culture without sacrificing simplicity and heading toward IT complexity?

In the previous article, we talked about sandboxing as a strategy. Check out that article to learn more details about sandboxing. Sandboxing is a tool that allows choice while managing complexity. But can we increase and encourage agility while closely managing choice? Yes!

The way we do that is with knowledge.

Knowledge and Empowerment

It turns out that what we want is not agile teams, nor is it self-directed (self-choice-driven) teams.

It turns out that what we want is empowered teams. So what’s the difference between an agile and choice-driven team and an empowered team?

The difference is knowledge. The more knowledge our teams have, the better suited they are to make decisions that are not only consistent with their individual teams’ needs—the needs of their individual microservices. But they are better suited to make decisions that are better suited to the overall company’s requirements and the general needs of the application as a whole.

The empowered team makes their own decisions, but they make those decisions incorporating both their individual needs and those of the microservices they manage. They also include the needs of the overall application and business needs.

The more knowledge, the more information and the more data a team has, the more they switch from simple choice-based teams striving for agility and independence to an empowered team that understands the system-level tradeoffs their decisions involve.

The result? A force vector drives all teams towards decisions that tend to move the teams in the same direction rather than in unique directions. This means the teams and their decisions tend to have a less negative impact on complexity.

The result, quite simply, is less complex applications, systems and the overall business.

And we know that agility and choice lead to innovation.

Driving Innovation With Information

Essentially, the best way to keep your teams innovative is to keep them informed.

Information drives innovation as much as choice drives innovation. And while choice can negatively drive complexity, information positively drives simplicity.

Knowledge and information-empowered teams are one of the best weapons against complexity.

Lee Atchison

Lee Atchison is an author and recognized thought leader in cloud computing and application modernization with more than three decades of experience, working at modern application organizations such as Amazon, AWS, and New Relic. Lee is widely quoted in many publications and has been a featured speaker across the globe. Lee’s most recent book is Architecting for Scale (O’Reilly Media). https://leeatchison.com

Lee Atchison has 59 posts and counting. See all posts by Lee Atchison