Continuous Change – InApps 2022

Embracing cloud-native applications means changing how we think about, develop, and deploy applications. This shift is not just technological. It impacts the structure of organizations, as teams align to common business outcomes.

Analyst Steve O’Grady at Redmonk has a great explanation of cloud-native apps:

There is a rough consensus on many cloud-native traits. Containers as an atomic unit, for example. Micro-services as a means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to deployment. High uptime. Ephemeral infrastructure (cattle not pets). And so on.

In general, when you’re designing an application, you’re concerned with the following: how the code is written, how you are testing the code, how you are releasing the code, and how you will manage the code in your production environment. Each of these “hows” is a necessary part of the application’s lifecycle, whether you are designing a monolithic app or a cloud-native app.

With cloud-native apps, the process for designing, coding, deploying, managing the app is pretty different in the cloud. But the biggest difference between the old and new ways of creating an app is the notion of continuous change. Cloud-native apps are continuously delivered and continuously evolving. Cloud-native patterns, combined with agile techniques for development and DevOps philosophies around managing apps in production, are really about decreasing the size of the change and increasing the frequency of the iteration.

Continuously Delivered and Continuously Evolving

Cloud-native apps usually incorporate containers and microservices, as well as the notions of automation, platform independence, multiple language support, high uptime, and ephemeral infrastructure. Your app could be a single microservice or a collection of interdependent microservices.

When an app is built with a monolithic architecture, or even if it’s broken up in a service oriented architecture, it’s usually a large, really chunky revision of the software itself. In the historical model, so much goes into the completion of a release, from up-front planning and design to reviews and approvals, and more. By the time the software gets released, it may not be what customers want anymore.

Cloud-native app development lets you be more responsive to users because updates to applications are released more rapidly. There’s another benefit to the decreased size of changes or iterations: They also decrease the risk of changes.

Decreasing Risk

In the cloud-native model, apps are broken down into smaller chunks of code, called microservices. These microservices can be independently provisioned. In such an architecture, microservices can fail or break, but if the app has been designed and deployed well, it can recover around failure of services.

Well-designed and well-operated cloud-native apps would have actually just evolved to that state — more quickly and safely — by bringing new features in incrementally, performing testing to small subsets of users before rolling them out globally. Teams can test new features and capabilities on a subset of the population before enabling them to the entire population.

To evolve to the cloud-native model, developers and software architects need to change the development process to take into account continuous evolution. Think about how you can build and deploy your apps in a more continuous way. Figuring out how to release features to a subset of the population and rolling them out to a larger set once they’re tested and ready is a really powerful way to improve your app’s quality.

And because each individual change comes at a lower risk, and because you are iterating faster, why not get feedback on how users are reacting to the changes? For example, this model increases your ability to get feedback from end users. Having apps delivered over the web enables you to build in ways to get qualitative data about how users are interacting with the app. User experience designers should be asking for things like web analytics and tooling like heat maps that give them insight into what users are looking at and clicking on. Though that’s not necessarily a cloud-native function, when you’re building an app in a cloud-native way, it can be instrumented to give continuous feedback.

New Testing Patterns to Decrease Risk

Before the cloud-native way, you’d have an app server with one version of an app on it. To move to the new version, you’d take the server offline and install the new version. In cloud-native development, whether we are using containers, or instances, or VMs, we can programmatically ask for more. It’s easy, and new patterns emerge for how we can manage change.

To evolve to the cloud-native model, developers and software architects need to change the deployment process to take into account continuous evolution. Think about how you can build and deploy your apps in a more continuous way. Figuring out how to release features to a subset of the population and rolling them out to a larger set once they’re tested and ready is a really powerful way to improve your app’s quality.

Let’s look at two patterns used in cloud-native apps to illustrate this point.

In Canary Node deployment, you can test changes by rolling them out to a small subset of the population. You’re sending a small percentage of your traffic to the version being tested. whereas in Blue-Green deployment, you are deploying multiple iterations of the same application concurrently to test the new version before sending production traffic to the new version.

Of course, before the cloud-native way, you could use these testing techniques. You’d just have to run a lot of extra servers to do so.

The cloud-native model also increases your ability to get feedback from end users. Having apps delivered over the web enables you to build in ways to get qualitative data about how users are interacting with the app. User experience designers should be asking for things web analytics and tooling like heat maps that give them insight into what users are looking at and clicking on.

Smaller, Faster, Less Risky

Cloud-native application development lets you make smaller changes more frequently, and quickly evolve the apps to incorporate the features that your customers or users actually want. What’s more, cloud-native apps have changed the notion of software versions. The version doesn’t really matter anymore. You’re not using version 3.x — you are using the live version, and that live version is going to continuously evolve.

Editor’s note: Listen to our interview with Chip Childers for his insights on PaaS vs. CaaS:

PaaS vs CaaS: What it Actually Means for Application Developers

Also available on Apple Podcasts, Google Podcasts, Overcast, PlayerFM, Pocket Casts, Spotify, Stitcher, TuneIn

The Cloud Foundry Foundation is a sponsor of InApps.

Feature image courtesy of Cloud Foundry.