Defining cloud-native

If you skipped right to this point and you didn't read the preceding sections, then I suggest that you go ahead and take the time to read them now. You are going to have to read them anyway to really understand the context of the definition that follows. If what follows surprises you in any way then keep in mind that cloud-native is a different way of thinking and reasoning about software systems. I will support this definition in the pages that follow, but you will have to convince yourself.

Cloud-native embodies the following concepts:

• Powered by disposable infrastructure
• Composed of bounded, isolated components
• Scales globally
• Embraces disposable architecture
• Leverages value-added cloud services
• Welcomes polyglot cloud
• Empowers self-sufficient, full-stack teams
• Drives cultural change

Of course you are asking, "Where are the containers?" and "What about microservices?". They are in there, but those are implementation details. We will get to those implementation details in the next chapter and beyond. But implementation details have a tendency to evolve and change over time. For example, my gut tells me that in a year or so we won't be talking much about container schedulers anymore, because they will have become virtually transparent.

This definition of cloud-native should still stand regardless of the implementation details. It should stand until it has driven cultural and organizational change in our industry to the point where we no longer need the definition because, it too, has become virtually transparent.

Let's discuss each of these concepts with regard to how they each help deliver on the promises of cloud-native: speed, safety, and scale.