Cloud-native is a complete assembly of infrastructure and methodology – it brings together architecture, operations, and technology in one easily deployable, low cost, high-performance infrastructure. The term has just recently enjoyed its “15 minutes of fame” and may be a bit overused by aspiring vendor participants.
In general, cloud-native infrastructures have several key characteristics: first, they use software containers as the unit of application deployment; second, they are dynamically managed by a central orchestrating process; and third, they are microservices oriented. They may also include health reporting, key performance indicator (KPI), and service level indicators (SLI), which constantly report on application input, output, latency, error conditions, and more. They are also designed with resiliency in mind, so a view towards recovery and careful data integrity under these conditions should be part of the design. All of this lowers cost for design, deployment, and life-cycle maintenance; enables scale with much less design trauma; and potentially shortens the design and deployment cycle.
Cloud-native infrastructure is the prerequisite to run cloud-native applications. Unless the infrastructure is set up with best practices, the overlaid cloud-native applications will perform poorly or even fail.
Existing infrastructure can be used with cloud-native infrastructure. This can include API integration and service-oriented architectures. Cloud-native is more wrapped around microservices, containerization, and the distributed management via orchestration. Both of these can work together.
The decision to move to cloud-native infrastructure is supported by a strong return on investment. First, cloud-native applications enable you to automatically provision resources. This facilitates on-demand self-service use and lowers costs to the developing organization. Second, the ease of scalability is now designed in and brings a very big advantage – this lowers your costs and can save many dollars for development and deployment. Finally, given that all applications will fail (crash!) at some point, cloud applications benefit from the resilient underlying infrastructure that automates recovery and, in almost all cases, mitigates completely the impact of the failure.
Deployment requires careful planning. You will need to define the business services for the applications you plan to develop. This requires you think through the application composition, the framework for events and policy, and the application delivery and then define the common control and related operations.
Securing cloud-native infrastructure is critical. It is important to confront the realization that these containerized applications, while robust and easily configurable, can provide some new opportunities for the sophisticated cyberattacker to find and exploit even the best-designed applications. This can happen at almost any level within your design and at any point in the architecture. The solution is to align cloud-native infrastructure and application development with other new concepts such as Zero Trust end-to-end encryption. Using a cloud access broker (otherwise known as a cloud access security broker) to ensure that the data is encrypted before it goes into the cloud, and remains that way during any processing in the cloud, locks down the data in such a way that the myriad of new cloud exploits, both known and to be found, find no leverage for prospective attackers. This scenario using cloud access brokers also works well to meet the rather difficult challenges for data security and threat protection driven by many global compliance requirements.