What Are Cloud-Native Applications?
Cloud-native applications are defined by having the characteristics that allows them to take full advantage of cloud-native computing.
Join the DZone community and get the full member experience.Join For Free
To understand the cloud-native, we should first understand the definition of the cloud.
NIST defines cloud computing characteristics as follows:
Broad network access
Cloud-native applications should be the applications which are designed and implemented to use and take advantage of the above cloud computing characteristics.
Cloud-native applications should have the following characteristics:
Immutable Packaging & Execution
Machine images (For eg: AMI) and container images (For eg: Docker Image) allows us to bake the library dependencies along with the application. This allows the development to take advantage of rapid elasticity. Containers can be much more efficient than VMs as multiple containers can be executed on a single VM, hence further optimizing resource pooling characteristics.
Functions-as-a-Service like Amazon Lambda can further optimize resource pooling.
Decoupled Configurations and Secrets
Immutability and elasticity make it difficult to add configuration as part of code, hence centralized key-value stores like Hashicorp Consul and secrets engine like Hashicorp Vault and AWS KMS should be implemented.
The application should fetch the secrets and key-values providing on-demand flexibility to append and update secrets and the key-value.
Statelessness and Statefulness
Rapid elasticity makes it somewhat difficult to couple data with the applications. The stateful landscape is still a work-in-progress and unstable. Until it becomes stable, applications should use external storage, queuing and search engine systems (For eg: Redis, RabbitMQ, Kafka, MySQL, Cassandra, Elasticsearch, etc).
The problem with monoliths was that even if we need to scale only one module for example, payment, we need to replicate/scale the whole monolith which defeats the purpose of resource pooling.
Microservices and micro-frontends can provide better resource pooling by running containers/functions on the same VMs. Also, scaling microservices becomes easy as it is independent/loosely coupled and performs single functionality of the domain. For example, in the eCommerce domain, a single functionality can be payment, checkout, carts, orders, shipping, etc. Most of the modern-day storage systems are multi-tenant, so multiple applications can take advantage of this multi-tenancy characteristics.
Polyglot is probably the best thing about using this paradigm. As dependencies are packaged along with the application and are isolated from the underlying execution environment, the development team can use their language of choice to write their modules and achieve their use case.
Due to rapid elasticity, it can be difficult for the development team to track down the problematic machine and view its logs, as it wouldn't be secure as well as convenient to hand out production machine access (For eg: SSH) to different development teams. Almost all major cloud providers provide a service which can ingest log or log-like data. Cloudwatch logs, ELK) Applications should forward their logs to centralized logging service. On-demand self-service centralized logging solution can be used by development teams to securely and conveniently access the production logs.
Managed via DevOps and SRE processes
Apps should use Continuous Integration, Continuous Delivery, and Continuous Deployment via declarative Infrastructure-as-Code, configuration management.
Important metrics should be measured for monitoring and observing application.Deployment patterns such as Rolling, Blue/Green, Canary should be practiced. Blameless postmortems should be promoted during application outage to make the application more resilient and robust.
All the processes and tools which are used for development, deployment, and maintenance of the apps should be automated or have API(s) for automation via custom scripts.
Applications use well defined lightweight API on top of common protocols like REST and gRPC for exchanging the data. The protocols used are intentionally language independent to support polyglot paradigm.
API-centric approach also promotes broad network access, hence same API(s) can be consumed by Mobiles, IoT devices, Servers and Development teams which then can use it for their scenarios.
Published at DZone with permission of Anshul Patel. See the original article here.
Opinions expressed by DZone contributors are their own.