I’m certainly not the only one to say that “cloud” is more about how you compute than where you compute. Generally, if you're taking your existing production apps and simply rehosting them elsewhere, you won't achieve any new stability. Why? Those five or fifteen-year-old apps running in your data center today are probably layered, client/server-style apps built well before cloud patterns took hold. Taking those existing apps and deploying them into the cloud as is may, in fact, result in a less stable system, because things are likely to be a lot more dynamic in those new cloud data centers than they are in your own.
That last statement gets to the heart of the matter: it’s all in that “change” word.
For the past three decades, heck, probably longer than that, the stability of our applications depended on the stability of the systems they ran on. If the host our app was running on went belly-up, we threw our hands in the air and declared “not our fault,” and most everyone would have agreed. But that is no longer a valid excuse. Your applications must remain functional even as the systems they run on are failing—or otherwise changing.
What? How is that even possible? It's possible because you can write change-tolerant software.
How you design and build applications is the single biggest determining factor of their stability when deployed into the cloud. For example, you’ve probably heard it said that the new app must be stateless—the output generated by the app is never influenced by any state left behind from previous invocations of that app. In other words, the output should be the same whether that app has served 1 or 1,000 or 0 prior requests.
Forgive me for being a bit nerdy here, but if we take that as an axiom, then we can deduce that each invocation could be dispatched to a brand new instance—that is, one that has served 0 prior requests. The next step in the “proof” then allows us to reach the conclusion that if something goes wrong with my app—say the infrastructure fails and that app instance disappears—no problem, we can stand up a new one on a part of the infrastructure that is still up and running, send traffic to that new instance (which has served 0 prior requests but, by design, will give back the same answer as one that has handled 1000) and voila, my app is more stable than the infrastructure it is running on.
Apps can be more stable than the infrastructure they run on.
Of course, a beautifully designed application still needs good DevOps practices and tooling wrapped around it to achieve things like that part about “stand up a new one”, and that is exactly what we are doing with Pivotal Cloud Foundry. But the application platform alone is not enough—it is necessary, but not sufficient to achieve the very highest levels of stability. You also need a properly designed application.
That properly designed application is what we call a cloud-native application, or one that is tolerant to change.
The stateless application pattern, however, is just scratching the surface. Apps also need to properly abstract configuration so it can be applied at just the right time and in the right context. Dependencies between application components, or services, must also be carefully engineered and treated as part of the app configuration. Apps/services need to be properly versioned so that the risks previously associated with one of the most frequent causes of change in your infrastructure, deploys, can be minimized.
Further, changes don’t just affect the stateless apps that make up your digital solutions, they also impact the state that is stored in databases and other backend systems. When the substrate that connects all of these pieces is the problem (and it’s always the network, right? 😉), the application as a whole still needs to perform at some capacity, even if it is a somewhat diminished capacity.
The sum of all these pieces—the cloud-native apps, cloud-native services, cloud-native data, and the cloud-native collective—is your cloud-native digital solution.
Cloud-native is new software for a new era.
A deep understanding of the design approaches and patterns that I hint at above is essential for the application developer and architect building today’s solutions. And that is why I’m working with Manning Publications on a new book: Cloud Native: Designing Change-Tolerant Software. I often say that here at Pivotal we are feedback-obsessed, so I'm delighted to be working with a publisher that applies the same principles of feedback-driven, agile development that we employ for building software, to publishing books. We’ve just released the first three chapters of my new book as a part of the Manning Early Access Program (MEAP).
The first chapter, where I define the four main concepts in cloud-native: apps, services, data and connections, is available for free. I’m also delighted to offer Pivotal blog readers, yep, that means you, a discount code that offers the book at 40% off. Use the code cnpivot40.
Enjoy the book—I'd be delighted to have you on this journey with me and to hear how it's going for you.
