“Cloud native” is an overused and ill-defined term. My take is that “cloud-native applications” adhere to these properties:
- They are not monolithic. Instead they are discrete, logically separable portions that are packaged and deployed on their own. Usually these are done as containers, and in some cases just as regular Linux packages.
- The entire application stack should not be required to be run on the same machine. They can be scheduled anywhere, in any server, or any zone. They should also be able to discover each other in a distributed deployment.
- The application should be able to scale with demand quickly, by spinning up parallel instances of a particular compute logic.
- Services that applications depend on for coordination of communication or for state preservation should be discoverable and CRUD-able on demand, programmatically and dynamically regardless of any underlying physical infrastructure.
By operating with a clear definition of what cloud native means, we can have a better and well-defined separation of responsibilities from the various cloud-native technology components involved. Examples of these components that enable cloud native applications are scheduling software, networking and discovery software, and storage software.