Cloud Native Applications

Seven principles for Cloud Native architecture in Kubernetes

Nowadays it is possible to containerize almost any application and running it. However, building Cloud Native applications requires an extra effort.

“Cloud Native” applications anticipate failure. They run and scale even under infrastructure failures, but to offer these capabilities, platforms like Kubernetes impose some restrictions to ensure the best utilization and success of the application.

Good practices in software design are of paramount importance for its success, choose yours, but be quick :D

• KISS — Keep it simple, stupid

• DRY — Don’t repeat yourself

• YAGNI — You aren’t gonna need it

• SoC — Separation of concerns

These principles are not rules, but they represent the common wisdom of many developers and can save you a long walk.

Inspired by this article by @bibryam and by Red Hat, we present the 7 principles for “Cloud Native” architecture in Kubernetes.1-Single Responsibility

This principle is heavily inspired by the Unix motto that says “Do one thing, and do it well.” With this in mind, each container should have a specific responsibility, especially due to Kubernetes' "POD" approach, where several containers can be together in a "POD", each performing a function, for example Prometheus and auth-proxy, where each container does only one task: the proxy authenticates the user and then redirects the request to prometheus, the application itself.2-High Observability

Containers provide a very simple way to package and run applications, but knowing exactly what is happening with the “health” of your container and being able to act on each event is a fundamental prerequisite to achieve maximum automation, efficiency, and resilience.

In a practical way, your container must export logs, tracing of requests and also have ways of checking health with the famous “probes”, which must be thought about during the development of the application, allowing you to know how your application is behaving at every check.

With the advancement of DevOps, responsibilities have been increasingly shared within teams, but if the person who develops the application also thinks about how it will be monitored, they will leave this test ready for the orchestrator.

3-Lifecycle

Very simple, as the name suggests. Your application must be prepared to receive signals from the platform to terminate, and especially must obey them, otherwise it may be followed by a “KILL” signal, which can cause unexpected behaviors.

Confused? Here is an example: a database application should not be terminated "by force" but in a "graceful" way — the difference of “SIGKILL" x "SIGTERM” — the kill will interrupt the activity and risk causing irreparable damage to your data.

4-Immutability

This property is often ignored or has its importance underestimated, but ensuring application integrity across different environments is not a simple task, although important, especially with a large team or with various levels of knowledge.

Immutability will allow you to “promote” the image of your application between different environments, ensuring its behavior is maintained. This property is closely linked to the principles of externalizing dependencies and configurations, such as environment variables, treated in 12Factor, which I highly recommend reading!5-Disposable Processes

One of the reasons to move to containers lies in their volatile nature and the possibility of being quickly replaced by another container, at any time or for any reason. This can happen for several reasons, such as lack of resources, application failure, scale-up / scale-down behavior.

For this, the application needs to keep its state externally, making it fast to start and receive connections.

Another good practice is to build small containers, because a large image takes longer to be transferred, even within a cluster, which can also interfere with the resilience process of your application, not to mention network throughput :D

6-Self-contained

This principle indicates that the container must have, after the build process, everything necessary for the application to run, leaving out only configurations, which can vary between environments as mentioned above. Example: adding the download of some library or other external dependency to the application start-up. Not only are we adding time to the process, but we also run the risk of it not working, impacting mainly at the moment of autoscale, which is expected to be almost instantaneous.

7-Start Confinement

The application must have well-demarcated boundaries, because a container is not just a process, it depends mainly on CPU, memory, and its disk space.

Thus, it must declare this to the platform and the application must obey these declarations in order not to cause failures when trying to exceed its resources. If the language used allows it, declare the resources that will be used so that it does not have incorrect behaviors when trying to use resources it will not receive.

Conclusion:“Cloud Native is not a destination, but a journey!”Final Tips:

• Always strive to create smaller container images. Learn more.

• Do not grant unnecessary privileges or permissions. Learn more.

• Expose the specific ports of your application.

• Stateless is ideal, but if you have no choice, use volumes for data persistence; object storage can be a great option.

• Use tags and metadata in your images and wherever else you can!

• Join a group and discuss ideas, if you are in SP -> https://www.meetup.com/Cloud-Native-Sao-Paulo/

Sources:Slideshare, Docker, ProjectAtomic, Openshift, UseNix, LeanPub, 12Factor and RedHat

[embed]https://upscri.be/375ca4/[/embed]