Back to Resources

Cloud Native: Runtime Considerations for Scalable Applications

Discover key runtime considerations for building scalable Cloud Native applications. Learn how to optimize your cloud hosting strategy.

Cloud Native: Runtime Considerations

After the introduction of the technical concepts in post one of this series, the next step is to understand the hosting capabilities in the cloud. Most of the following points are in general available in the commonly known hyperscaler platforms (AWS, Azure, GCP, …).

Dynamic Orchestration

With tools like Kubernetes, you can automate the deployment, scaling, and management of containerized applications. The very difference to previous execution environments lies in the declarative approach to define the desired state with resource objects describing storage, network, and workload related components. While Kubernetes tries to fulfill the desired state, it works in an endless loop inherently also providing a self-healing feature. Systems can automatically recover from failures, such as restarting containers or rerouting traffic.

This whole concept works hand in hand with the Gitops approach. Its core idea is to apply changes to the resource definition files via commits to SCM repositories. These data sources are monitored by Gitops operators like ArgoCD or flux, which in turn apply the changes as new desired state definitions into the Kubernetes cluster.

Elasticity

Elasticity is the ability to dynamically scale resources up or down based on demand. This fulfills availability requirements (uptime ratio) for a service but also optimizes for cost and performance. This concept requires considerations in many levels of the software development and the execution environment’s architecture as well. For instance:

  • What states does a service have, and can it also function well in multiple instances distributed across different regions?
  • Do distributed applications access the same resources, such as databases, and can they handle transactions and locks?
  • Can frequently used data be stored in a central location with high availability in order to reduce the load on databases?

Additionally, there are also ways to fully automate the scaling of application instances or even the hardware resources (VMs) used based on system utilization metrics.

Resilience and Observability

Due to the distributed way of microservices being deployed, the applications must be fault tolerant about several concerns. For instance, a calling party might retry failing requests whereas a serving component should protect itself from unwanted DDoS issues in turn. Independent of the Cloud Native scope, it is a generally good practice (even in pre-Cloud Native times) to handle exceptions/failures gracefully. This ensures the stability of a running service.

Reading about all the aspects from the above one may find the architecture becoming increasingly complex. This emphasizes the need to structure your system in a straightforward way from the ground up and to make wise decisions before starting to split up a service into smaller services. The combination of elasticity and the dynamic hosting model using Kubernetes requires comprehensive metrics, logging, and tracing mechanics in your application and infrastructure. The monitoring aspect provides insight into application performance and health. A system with real-time feedback enables the operators to rapidly detect issues and find resolutions to fix them.

Security

Checking the frequent news about compromised systems and cyber-attacks, security considerations are becoming more important. In addition to resiliency and observability aspects, particular practices also need to be integrated early in the development lifecycle. Existing tools help with automated testing and vulnerability scanning in the phase of Continuous Integration & Deployment (CI/CD). But also, the runtime environment requires a good concept, a proper network setup and continuous monitoring to protect sensitive data and infrastructure.

Important paradigms are the Zero Trust Model, and the Principle of least privilege. It is about avoiding trust in any user or device and the reduction of granting permissions to the essential set needed. In addition, potential considerations should always be made at all security-relevant levels (network, the implementation itself, external resources, etc.). A good starting point to cross-check your current software stack with general recommendations is the OWASP Top Ten list.

In part three of this post series, we will focus on organizational aspects such as DevOps and continuous improvement and deployment. Stay tuned. Read on.



Author © 2024: Marcel Hoyer – www.linkedin.com/in/marcel-hoyer-0a21a12b2/

Any questions?

Get in touch
cta-ready-to-start
Keep up with what we’re doing on LinkedIn.