Cloud Native, some key ideas

Cloud native is a target model for most firms. Cloud native refers to using the native services and API integrations, along with the platform’s native PaaS offerings (SDKs, databases, code build and deployment, IaC, CI-CD), to build an application and related infrastructure which takes advantage of cloud native attributes including HA, scalability, reliability and integrated testing and monitoring.

The better your cloud-native development process, the more efficient and reliable your application is likely to be.

1 Avoid vendor lock-in with cloud services

Rather difficult in reality, even if you are using Terraform or IaC that is supposedly cloud agnostic. To achieve this cloud-native benefit of portability, avoid services that are tied to a specific vendor. Ensure that the app doesn’t depend on a specific vendor’s service or feature in its environment to operate. Likewise, steer clear of PaaS products that let developers build and deploy an app only to a particular cloud or type of host environment.

For example, if you choose to run a cloud-native app using Kubernetes container orchestration, design it so that it can run in any Kubernetes environment. Don’t limit yourself to a specific vendor’s Kubernetes distribution.

Microservices, containerization, continuous delivery and DevOps are key principles of cloud-native development.

2 Choose the right design pattern

Developers have many options when it comes to the design of a cloud-native application. For instance, Microsoft’s list includes no fewer than 39 distinct patterns. The most popular cloud design patterns include:

• Sidecar. The main application operates as one set of services. Auxiliary functionality, such as that for monitoring tools, runs alongside it as sidecars.
• Event-driven. A design pattern where the application performs functions in response to specific events, instead of operating continuously.
• CQRS. Command and query responsibility segregation separates application write operations from application read operations.
• Gatekeeper. A single public-facing application instance serves as a gateway that forwards requests to other, privately hosted instances.

Many design patterns can be used concurrently; they are not mutually exclusive. The design pattern or patterns you use should reflect the app’s use goals and company priorities.

If security is a top priority, a gatekeeper design pattern could work; it reduces the exposure of the application to the internet. For another use case, CQRS is beneficial for apps that require high data availability. Because the CQRS pattern allows only specific parts of an application to modify data, it reduces the risk of accidental data overwrites or corruption caused by a buggy application.

3-Use serverless strategically

There are many good reasons to use serverless computing to deploy cloud-native apps.

• Serverless can reduce your overall cloud spending.
• It allows applications to scale up and down rapidly.
• It reduces the effort required by engineers to deploy and manage applications. They don’t have to provision a complete server to host the application.

Even so, serverless has clear drawbacks.

• There’s less portability. In general, it’s hard to migrate an app from one cloud-based serverless compute engine to another.
• Serverless compute platforms only support applications written in certain languages or frameworks, at least natively. Developers sometimes use wrappers, enabling them to run serverless functions that aren’t natively supported on a given platform. That requires extra effort, however, and it may reduce performance.

Cloud-native developers should research when to — and when not to — design applications as serverless functions. Serverless makes sense if factors like ease of deployment and scalability are priorities. It doesn’t make sense if you prioritize portability. It also might not be a fit for applications written in less common languages.

4-Bake in security from the start

Security cannot be an afterthought when developing cloud-native applications.

In practice, organizations need policies to ensure secure development. These can include guidance to plan and implement secure application authentication, authorization within the application development process, and ways to prevent developers from building any business functionality and tacking on authentication later.

Developers should also plan to maximize the security of application data. This includes data stored inside the application as well as data housed externally, such as in an object storage service. Implement data encryption and access control features across all storage locations.

There is no one right or wrong way to develop a cloud-native application. Getting the most from cloud-native applications requires a well-planned development process that is tailored to an application’s use cases and priorities.

Source