Six Questions for Cornelia Davis, author of Cloud Native Patterns

Cornelia Davis is Vice President of Technology at Pivotal Software. A teacher at heart, she’s spent the last 25 years making good software and great software developers.

Read more interviews from our Six Questions series.

All of the major cloud providers, as well as other service providers, offer traditional infrastructure services for compute, storage and networks. That is, you can rent a virtual machine and some block storage, wire everything together using networking services, and host whatever application you want on that infrastructure. In fact, it’s not that hard to simply “lift and shift” an application that might be running in an on-prem data center to that cloud. So the where is now in the cloud—but just because it’s deployed into the cloud, the application is no more resilient to constant changes than before, in part because it’s likely not as highly distributed as it needs to be.

On the other hand, cloud-native software is designed to remain totally functional as the infrastructure it’s running on changes—and some of the secrets to making that happen are redundancy and distribution. Now, that software isn’t necessarily running in the cloud; it could be deployed in an on-prem data center or even on a set of servers sitting under desks. But how it works yields far better resiliency and manageability than that traditional application we lifted and shifted into the cloud.

The most immediately visible difference is in the level of coupling between components that make up the application, and most importantly WHEN those components are connected to one another to form a complete application. Let’s take a shopping web site as an example. Written in a traditional style, we might have a single application deployed that includes the product catalog and search as well as shopping cart and checkout capabilities. Even if under the covers there are different software packages for these different functions, the fact that they are bundled together before deployment allows them to communicate with one another in a fairly predictable manner.

A cloud-native e-commerce application is made up of independently deployed and managed components: there is a deployment of the catalog, separate from the deployment of a search service, separate from a deployment of a shopping cart service, separate from the deployment of the service that processes payments. Of course, those services still need to interact, but some of the predictability you had before is gone and therefore your software has to do things it didn’t before. Yes, it’s more work, but in return you get the highly resilient, scalable and agile systems that are giving users far superior experiences today.

Let’s carry on with the case of the e-commerce site deployed as a set of separate services. As I said, these components must communicate with one another. For example, the search service needs to present results from the product catalog, so those two components will need to connect on occasion. These components are independently deployed and managed, and the coordinates (say the IP addresses) of each can change, so when the search service needs to contact the catalog service it needs to go through a protocol to find its latest coordinates: this is the service discovery pattern.

Then having found where to make the call, if the search service does not get a response to a request to the catalog service, what does it do? It may want to employ a retry pattern to make the overall system more resilient to the inevitable network blips. But then the catalog service may want to protect itself from being overwhelmed with load by standing up a circuit-breaker in front of its service.

These are three of the more than two dozen patterns I cover in the book. I spend as much time, if not more, covering the context in which these patterns will be applied, and explaining why they are valuable, as I do on the patterns themselves. My aim is to not only to teach the patterns but to teach my readers when and how best to use them.

Simply put, I work on emerging technology and how it can be used to generate business value. What that means is that I look at emerging trends—cloud-native software has been one of those for the last five or so years—and I work with customers, partners and our own research and development teams to apply them in a way that it yields positive outcomes for the users of that tech.

I am passionate about one simple thing: I just want everyone–women, men, non-binary, people of color, caucasians, everyone–to have a chance to have as much fun as I do! This is a great field that offers tremendous financial stability and flexibility, and it’s just a total blast to boot. Plus, there are volumes of data showing that greater diversity in the workforce yields better business outcomes, larger profits, higher return on investment, and greater shareholder value.

Organizations such as Girls Who Code (GWC) and GapJumpers (I’m on their board) are addressing some of the many obstacles that keep a great many people from engaging in this space. GWC is one that I am most drawn to because it engages young women who are juniors and seniors in high school, teaching them to code in an intensive and very fun seven-week summer program. I discovered computing in the first week of my junior year in high school, and it changed my life.

My first preference when I arrive in a new city is public transportation. When I do need to take a car, I prefer sharing rides because if two or three of us are transported in one car, that generates fewer greenhouse gasses than three cars driving next to each other on the same freeway. Imagine my delight when I shared a ride with someone who works full time as an environmentalist. He worked for an organization that, among other things, “greened buildings,” that is, they did things to reduce the environmental impact of these complexes. He’s worked on buildings all over the world, including the White House and the Pentagon–imagine the impact of going to LED bulbs throughout the Pentagon–I’ve been there, and it is massive!