Cornelia Davis

+ Follow
since Jul 15, 2019
Cornelia Davis is Vice President of Technology at Pivotal, where she works on the technology strategy for both Pivotal and for Pivotal customers. Through engagement across Pivotal’s broad customer base, Cornelia develops core cloud platform strategies that drive significant change in enterprise organizations, and influence the Pivotal Cloud Foundry evolution. Currently she is working on ways to bring the various cloud-computing models of Infrastructure as a Service, Application as a Service, Container as a Service and Function as a Service together into a comprehensive offering that allows IT organizations to function at the highest levels. She is the author of the book “Cloud Native: Designing Change-tolerant Software” by Manning Publications (

An industry veteran with almost three decades of experience in image processing, scientific visualization, distributed systems and web application architectures, and cloud-native platforms, Cornelia holds the B.S. and M.S. in Computer Science from California State University, Northridge and further studied theory of computing and programming languages at Indiana University.

When not doing those things you can find her on the yoga mat or in the kitchen.
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Cornelia Davis

Tim Holloway wrote: Actually, property configuration files compiled into an application (web or otherwise) is a horrible practice.

100% agree, but as you can see from the dialog above, it is still quite common to do just that. That is precisely why I cover external configuration in the book. JNDI is a possible implementation of the pattern that I describe - which we might call external configuration. Love your practices Tim.
11 months ago
What an interesting question and resulting dialog!!! Thanks for getting this kicked off Carl and for all those participating.

I see a few different threads going on here and I'll see if I can sort them out a bit.

I'll first note that I assume that there is still software being developed by said company. If a company has stopped building software and instead is using only SaaS services, then sure, they'll probably need very few "IT" people. I will say, though, that in the era where software is a differentiator, sometime THE differentiator, I see it going the other direction - companies are building MORE software themselves rather than less.

Okay, so with that assumption established, here are a few scenarios:

1. Company moving out of their own data centers into cloud data centers. Now, this does not mean they are going “cloud-native.” I make the distinction in the book between “cloud” which is more about the where of computing and “cloud-native” which is how.

1a. A company moving to the cloud can take all of what they have today and simply run it in someone else’s data center. Here I totally agree with Tim that your IT load is not likely to decrease very much. Sure, you’re not racking and stacking hardware anymore, but you are still provisioning and managing the compute, storage and network needed for your software.

1b. If, as a part of the move, the company begins to change their software, leveraging some SaaS services for things like databases and messaging systems, then it is possible that they can move some of the responsibility from their own IT to that of the SaaS (cloud) provider. Take a database, for example, the database provider is going to take care of things like upgrading the DB servers, patching vulnerabilities, etc. but your apps that are leveraging that DB, well, all of the lifecycle events around that won’t be managed by the SaaS provider - that’s still on the company building the software itself. Now, without getting into all of the details, I would point out that:
  • it might be the “application team” (some might call them the DevOps team) rather than some traditional ops team that is doing that management. And
  • 2) that the trickiest thing is that with responsibility for management distributed across the SaaS provider and the company building software that depends on that service (i.e. the database), there is a non-technical problem to solve here; have to figure out what these new operational practices are. How coordinated must the folks managing the DB be with those managing the software that uses it?

  • 2. Company is going “cloud-native.” That is, they are building software that is far more tolerant to change (I almost like the subtitle of my book better than the title “Designing change-tolerant software”). Now, whether that lands in the public cloud or some private cloud, there are implications on the staffing in IT. If private cloud then you still need folks to manage things like the compute capacity (served up by something like Kubernetes, Cloud Foundry, Google App Engine, etc.) and services (like databases, messaging, etc.). If you are in the cloud, you could use some of the same services I talked about in 1b above. What is most interesting in this case, though, is that when your software is more tolerant to change, then that allows you to more loosely couple the management of the services from the management of the compute. It get’s back to the question I posed above:

    How coordinated must the folks managing the DB be with those managing the software that uses it?

    Really, only once they are more loosely coupled can IT resources be shifted.

    So in broad summary:
    * If you are going to the cloud but not cloud-native: probably little reduction in IT staff
    * If you are going cloud-native in a private cloud: probably little reduction in IT staff, but roles change and efficiencies can be achieved.
    * If you are going cloud-native and to a public cloud: you could offload some of the IT responsibilities to the cloud provider. (Even here it’s not a given - need to be deliberate to achieve such things).

    Thanks again for the question and dialog. Super fun!
    11 months ago
    Hi Paul.

    There are many - I'll name but a few here.
  • Using sticky sessions: Sticky sessions encourage the load balancer to route multiple requests to the same application instance and it's a pattern we used for a long time in web applications. And it worked okay when we had application instances that stayed alive for extended periods of time. But these days, app instances (most often running in containers) live much shorter lives and the chances of an instance being there from one user request to their next goes down significantly. I cover sticky sessions in some depth in section 5.3.
  • Putting application configurations into property files. "What?!?!" you say? "Aren't property files a best practice? It's better than hard coding in the code!" - Yes, property files ARE a best practice, but because they are often compiled into the binary, that means a config change requires a new build. This causes all sorts of downstream production deploy problems. Instead of putting the values in the property file, I suggest using it (the prop file) to list the variables that need to be bound and using a configuration server to manage the values. I cover this in a great deal of depth in chapter 6.
  • Assuming because they have multiple instances of an app and have deployed to a platform like Kubernetes that their app will work through a rolling upgrade. Have a look at the example on credential rotation in sections 7.2 and 7.3 (the chapter on application lifecycle - I cover rolling upgrades and blue/green upgrades in there).

  • There are many more covered in the book.

    11 months ago
    Another great question Jorge! You are pointing out that it's quite important to be able to have a cloud-native environment in even the most local settings. By cloud native environment, I mean one that allows the developer to test out things like whether their multiple instances of an app actually act as a single logical unit, whether you are using the service discovery protocol correctly, and so on. If you were just running a single instance of some web service you created and testing via unit tests, for example, you aren't going to exercise that path.

    Part of the reason that I ended up using Kubernetes as the vehicle for demonstrating the patterns is precisely because it is easy to get running locally. Most of the examples do, in fact, run locally (except when I do a simulation of some cascading failures in chapters 9, 10 and 11) and I step you through using Minikube. This requires something like Virtualbox) and runs K8s in a VM. Since starting the book, another local option for Kubernetes has gained traction - Kind which stands for Kubernetes in docker. Either option will work well.
    11 months ago
    Hi Jorge,

    The patterns are very intentionally agnostic of any particular platform. In fact, I go over the patterns whether the developer is responsible for implementing them or should be looking to a platform to find an implementation thereof. It's super important for the developer to understand the patterns whether they have to implement them or not, because an understanding is critical to know how they should be leveraged.

    Chapter 3 is all about platforms though, and how they provide a huge leg up on realizing some of the patterns I teach. But because the book is not about platforms in particular, I do not have any type of a formal listing showing what platforms provide implementation of what patterns.

    All of that said, I do have my readers deploy to a platform and while it's a good guess that I would do Cloud Foundry, and initially I planned to do that, you'll see that I use Kubernetes. :-)

    Thanks for the great question - you honed right in on one of the points I really hope my readers will get.

    11 months ago
    Thank you all and very happy to spend the week here.

    No question is too simple. And I will do my very best on the hard ones!! Send 'em all on!!!

    11 months ago

    Ganesh Patekar wrote:Welcome to CodeRanch and congratulations for new book.

    Thank you Ganesh. So glad to be here!
    11 months ago