The four factors of cloud-native growth

The baseline expectations for an emerging software application are higher than ever.

Even as thousands of tech startups form (and founder!) each day, there is no conventional path to reach even the most basic unit of software: an available, accessible, secure application. Instead, an innovator with an idea must face a tangled mess of decisions.

If you find it intimidating, you are not alone. The path from an idea to a minimum viable business is complex and disorienting, endlessly folding over itself.

But this path is not a maze. It’s a labyrinth.

labyrinth: a winding spiral path of twists and turns. Even as you follow it toward your destination, over and over again it will take you back to a place that is almost where you started.

There are no wrong turns in a labyrinth. Likewise, there are no wrong turns when developing an idea. Every turn of the path provides more information and a more complete map of the problem space. The only wrong move is to stop moving forward.

We may not find the path of growth easy to follow. We may not find it meditative and serene, like the labyrinth of a Victorian garden. There are nevertheless two key ways that the path of growth is like one of those labyrinths:

1. Within the labyrinth, we see the immediate twists and turns only, not the ones far behind or up ahead. Likewise with growing an idea: whatever problem we face now, that problem dominates our awareness. It takes great foresight and forethought to catch a glimpse of the big picture.
2. The spirals of the labyrinth take us over and over again to the same places. In the first loop of the spiral we are north, south, east, west of the center; before we are out we will, many times, be in each of them again. Likewise with growing an idea: the problems of growth will require us to think about our idea from a certain angle, not just once, but many times over, each time with new context and goals.

The labyrinth of software development. The path of growth in today’s world leads into software. Either your idea is an app, or it will require an app, possibly many apps, to facilitate its growth. Thus sooner or later—most likely sooner—we all find ourselves in the labyrinth of software development.

The labyrinth of cloud-native software development. When an idea grows into software, more often than not it grows into the space of cloud-native software. In order to be as fault-tolerant as modern users expect, apps need to be split up into services that communicate over networks and run redundantly (so one hardware failure cannot break the whole system), and they need to be built in a way that makes them fast to deploy onto a fresh machine (so the system can quickly recover from failures and scale up during surges in demand). These requirements make cloud-native software development the natural choice for most businesses.

Even so, software will not live up to these expectations solely because it is built in the cloud. Cloud-native software does not automatically become redundantly scalable, secure, and fault-tolerant. To ensure these qualities, a founder must walk a long path of architecture and process decisions.

Ioka’s mission is to light up the labyrinth of cloud-native software development.

In a labyrinth, we find ourselves over and over again in the same “region” of the space we are navigating. To glimpse the labyrinth of cloud-native software development, we have to consider the factors of cloud-native growth.

factor: one constraint imposed by a problem; one need that a solution must address.

Each idea walks its own labyrinth, with a unique set of factors deriving from its particular vision and problem space. Nevertheless, there are certain problems that all ideas must face as they grow into thriving cloud-native business systems. In this post we will introduce just four of these: The Four Factors of Cloud-Native Growth.

The Four Factors of Cloud-Native Growth concern the problem of developing an infrastructure system in the cloud. This is the labyrinth of infrastructure.

The four factors are:

1. Encapsulation. Growth requires migration: between vendors, between techs, between architecture patterns. The system must not be prevented from effective reorganization by tangles of interconnection. Therefore the system must be divided into parts with clear input and output paths running between them.
2. Reliability. The system must keep running even when parts fail, even when demand surges, and even when parts are down for replacement. Therefore the system must deploy infrastructure redundantly, preempt failure cascades, and be able to revert to its last working state in case of failures.
3. Visibility. The cost of system failures grows every minute that the team is not working to fix them. Therefore, stakeholders must have access to the state of all parts of the system as it is running. Stakeholders must be alerted to impactful failures. There must be a well-known process for tracing impactful failures and identifying the best stakeholder to address them.
4. Security. Data leakers and ransomware attackers will not wait until you are ready. Cloud-native infrastructure, being internet-based from inception, must expose some attack surface to potential bad actors. Therefore the system must have zero-trust policies built in at the foundation: each part must verify the trustworthiness of communications from each other part. Policies should be correctly configured to ensure that each part has access only to what it needs from the other parts. Similarly, human stakeholders should be limited to only the access they need in order to carry out their role.

The idea sits on top of infrastructure. The implementation of the idea, all the live code running on that infrastructure, is what we call product. Building product is a labyrinth in itself, one that is bound together with the labyrinth of infrastructure in crucial ways. Having distinguished these conceptually, we focus on infrastructure first for two reasons:

1. Every infrastructure decision impacts the product, sometimes in ways that are not apparent at first.
2. There are many ways to build an effective product, but comparatively few to build effective infrastructure. Ioka takes a special interest in setting businesses on the path of least surprise for infrastructure, from the moment they start building in the cloud.

Ioka’s practices are aimed at building cloud-native infrastructure that is encapsulated, reliable, visible, and secure from the very beginning. We work with these principles always in mind, whether we are building cloud-native infrastructure from the ground up, developing existing cloud-native infrastructure, or moving machine-bound infrastructure onto the cloud.

Future posts will show how Ioka’s practices serve these four factors at every turn of the labyrinth. In the meantime, we invite you to contact us to see how our knowledge can support and enable your growth as your ideas grow into the cloud.