Cloud Native Non-Functional Requirements: Building Scalable, Resilient and Secure... Jakub Krzywda

This talk focuses on designing applications with a strong emphasis on non-functional requirements such as scalability, resilience, and security. The speaker, Jakub Chrzanowski, a cloud-native architect at Elastisys, explains the importance of integrating these qualities into the architectural design of applications. He outlines how cloud-native technologies support the fulfillment of these requirements, operating within modern dynamic cloud environments. The session covers principles of loose coupling, observability, and automation as they relate to building resilient systems. Additionally, it explores specific security principles, including the need for security to be integrated throughout the development lifecycle. By providing practical insights and a framework based on these concepts, developers can better prepare applications for real-world challenges.

I would like all of you to imagine that you have recently been asked to design an architecture of an application. You are now standing in a meeting room in front of a clean white board. Uh you pull out a marker and you know that little moment, the cap comes off and there is a click. Then you start when everyone starts. You draw boxes. User interacts with the

front end box. That talks to the API box. That writes to the database. Another box. This is the comforting path. The functional story. What the application does, how data moves. The happy path. But then you hesitate for a brief moment. If you keep going like this, you will build something that walk works beautifully the first time with 10 users on your laptop. So you switch the marker

color because that's the sign that we are about to switch the perspective. And you write three words on top of the board. Scale, resilience, security. You ask yourself, what happens when marketing campaign is successful and application traffic increases 20 times on day one. What if one failed component takes the whole system down? Are we at risk of leaking user data due to vulnerabilities in our software stack?

Now the boxes on the board don't change much. But the design changes completely. Because functional requirements tell you what the system should do. And non-functional requirements decide whether you can keep going under load, under failure, and under attack. That's what this talk is about. We are leaving the comforting boxes behind and focus on making sure that we design the guarantees. What a platform can give you and

what the application still has to earn. I'm Jakub Chrzanowski, cloud-native architect at Elastisys, and I will share with you today lessons learned over many years of fulfilling non-functional requirements while building scalable, resilient, and secure systems on top of application platforms. The goals of this talk are to explore the relationship among guiding principles, architecture approaches, requirements, and implementation details within the realm of cloud-native technologies. And to provide

you, application developers, with practical insights on how to build applications which are not only functional, but built to last. This talk consists of three parts. First, I will provide a context defining cloud-native, non-functional requirements, and application platforms. Second, I will discuss various approaches and principles that help us to build a system which is scalable, resilient, observable, and secure. And third, I will present selected requirements and their

implementation, elaborating on which aspects are covered by an underlying application platform, and which are left to be implemented by the application developers. So, let's begin with the three concepts defining the context of this talk. Since these are definitions from others, I will display them in text and read out loud. First, according to the Cloud Native Computing Foundation, cloud native technologies empower organizations to build and run scalable

applications in modern dynamic cloud environments. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. Scaled Agile defines non-functional requirements as system qualities that guide the design of the solution and often serve as constraints. NFRs specify various system qualities and attributes, such as performance, scalability, security, usability, and maintainability.

Third, according to Red Hat, application platform is a comprehensive set of tools and services that streamline the entire application life cycle, from development to delivery to management of app workloads. You see that uh three concepts are closely related. NFRs define the qualities. Cloud native offers technologies to fulfill those qualities. And application platform combine uh these technologies into a coherent which streamlines the application life cycle management. Now,

uh when we have defined the context uh of this talk, let's move on and discuss various approaches and uh which were mentioned in the definitions I have just presented. This will help us to understand why uh we need to employ these qualities within our system, including both application and underlying platform. This will prepare us to discuss how exactly to achieve these qualities in the third part of

my talk. The first quality, uh loose coupling, is an architectural style where the individual components of an application are built in the independently from one another. The opposite uh paradigm of tightly coupled architectures. Each component, uh also referred to as a microservice, is built uh to perform a specific function in a way that can be used by other microservices. This pattern is uh generally slower uh to

implement that uh tightly coupled architecture, but has a number of benefits, um particularly as application uh scales. Loosely coupled applications allow teams to develop features, deploy, and scale independently, which enables organizations to iterate quickly uh on individual components and move forward the system as the whole. The second quality, observability, is a system property that defines the degree to which system can generate actionable insights. It allows users

to understand the system state and take corrective actions. Computer systems are measured by observing low-level signals such as CPU time, memory, disk space, and high-level or business signals, including API response times, errors, transactions per second, etc. Observable systems provide meaningful actionable data to their operators, allowing them to achieve favorable outcomes, faster incident response, increased developer productivity, and less downtime. The third quality is automation, and let's discuss

here three common practices it involves. Continuous integration is the practice of integrating code changes as regularly as possible. CI software automatically checks that code changes merge cleanly whenever a developer commits a change. CI allows software teams to turn every code into either a concrete failure or a viable release candidate. Continuous delivery is a set of in which code changes are automatically deployed into an acceptance environment. CD

crucially includes procedures to ensure that software is adequately tested before deployment and provides a way to roll back changes, if deemed necessary. This allows developers to deliver code frequently, giving them peace of mind that the new revision has been tested. Continuous deployment takes it even further and creates a fully automated path to production, which uh tests and and deploys the software using various uh deployment strategies, such

uh canary or blue/green releases. By automating uh the release cycle and forcing organizations to release to production more frequently, uh continuous deployment uh does to uh operation teams what CI uh did for development teams. Specifically, it forces operation teams to automate the painful and error-prone portions of uh production deployments, reducing overall risk. The fourth quality, uh cloud-native security, uh is an approach that builds security uh into

cloud-native applications. It ensures that uh security is part of development to production. Cloud-native security uh seeks to ensure the same standards as traditional security models, um while adapting to the particulars of cloud-native environments, namely rap- rapid code changes and highly ephemeral infrastructure. Uh cloud-native security introduces a new way of working that uh protects applications by migrating from to one uh where security is involved in every step

of the release cycle. Uh manual audits and uh checks are largely replaced with automated scans. Rapid code um release pipelines are integrated uh with tools that scan the code for vulnerabilities before they are compiled. Instead of slowing change, a cloud-native security model embraces it by um quickly updating vulnerable components or ensuring uh infrastructure is regularly replaced. Cloud-native uh security uh is highly related to the practice called

DevSecOps. Let's now take a closer look at uh four uh security principles. Security by design means that the system and its components are designed from ground up uh with security as the core priority. It proactively accounts for intentional attacks and unauthorized actions while its architecture minimizes the impact of potential security incident. With uh minimal need-to-know principle, each component uh and uh user receives only the permissions necessary

uh to perform their tasks. For example, application and network operate with minimum required system rights rather than administration uh administrator privileges. Defense in depth indicates that uh security risks are not mitigated by isolated protective measures but uh by a layered, multi-level approach with complementary safeguards. For example, at the network level, firewall and Kubernetes network policies allow only necessary communication and deny all other connections. At the application

level, each request is validated protecting against SQL injections and DDoS attacks. And at the data level, all user data is encrypted both addressed and in transit. Redundancy principle means that the system is designed to ensure that the failure of an individual components does not compromise security critical functions of the whole system. The last quality we should ensure in our system is don't repeat yourself, also known as

duplication is evil. It is a principle of software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change. Don't repeat yourself principle states that duplication in logic shall be eliminated via abstraction while duplication in process shall be eliminated via automation. It means that we need to control technical diversity, therefore applications must reuse functionality offered by

the platform for automated deployment, observability, and the data Finally, let's move to the promised you can immediately apply um to your cloud native projects. Now when we know which qualities we want to achieve and why. We will explore selected non-functional requirements and their cloud-native implementations. When presenting selected categories of non-functional requirements, I will indicate which aspects should be covered by the an underlying platform on the and

which ones should be implemented by application on the right. Let's start with the application state management using a database. Platforms should provide a replicated with backups and disaster capability disaster recovery capabilities. As any other platform components, the database systems should receive frequent updates including security patches. Application developers must use the database systems provided by the platform instead of reinventing the wheel and embedding database capabilities within their

microservices. They obviously still need to manage the databases users, correctly expose database credentials to applications, and implement database migrations which ideally are backwards compatible and allow automated rollbacks which is usually implemented in Kubernetes via init containers. Here we can see an architecture diagram of several microservices highlighted in yellow interacting with a database system highlighted in orange via Kubernetes service highlighted in blue. The implementation details of highly

available database system provided by the platform are abstracted and hidden from the application developers who only need to know the name of Kubernetes service, port number and details of the Kubernetes secret with database credentials. The next category of NFRs is observability and I want to focus here on the logging stack in particular. Platforms need to provide a logging stack which not only automates the process of collecting

and indexing logs from all microservices, but also supports log retention, searching, visualization, as well as alerting and protection of logs ideally in a tamper-proof environment. Application developers are obviously responsible for logging exceptions and in their applications utilizing appropriate log levels. In the cloud-native world, we write those messages to the standard output and ideally use structured logs in a multi-line JSON format. And moreover, application developers can implement

application-specific dashboards and log-based alerts to support troubleshooting and operation in Here we can see an example architecture diagram of a logging stack. Fluentd agents are highlighted in yellow running on each Kubernetes node normalize, filter and process and ship logs from all microservices to a central indexing system. In our case, OpenSearch highlighted in blue. Which ideally runs in a separate Kubernetes cluster highlighted in orange to provide protection

of log requirements. When it comes to the automation, platforms should provide a built-in or at least an integrate integrate with an external continuous integration solution for building container images. They should offer a container registry with vulnerability scanning, so you can store your images securely and ensure vulnerable and ensure that vulnerabilities are discovered before you deploy your application to production. Continuous delivery or deployment solution should enable you

to deploy new versions of your application into the environment in an automated way. Ideally, all these steps should be packaged together into a golden path showcasing a standardized approach to application deployment, which can be followed by all the application teams. should implement specific automated testing which will be utilized during the continuous integration phase to ensure that the new application version is correct. They should also use the

golden paths provided by the platform team to make sure that their application is deployed in a way following the best of your platform. Here we visualize two common approaches to continuous delivery or deployment, the push style on the top highlighted in where GitHub actions push changes from outside into the Kubernetes cluster and a pull style on the bottom highlighted in orange uh, where Argo CD pulls changes

from the Git repository and applies them inside the Kubernetes cluster. Moving on to the security aspects, let's discuss, uh, security by design principle first. Platforms, uh, should be based on the security hardened Kubernetes cluster, which, uh, with relevant security configurations enabled by default and enforced automatically. Application developers uh, must adhere to the security best practices both at the application level itself, as well as when it comes

to utilizing the Kubernetes objects. And for example, separate sensitive data from non-sensitive and store them in secrets and config maps respectively. Uh, this allows, uh, tighter access control around service configuration via Kubernetes role-based access control. Following the second, uh, security principle, minimal need to know, platforms must, uh, prevent applications from running, uh, as privileged users. For example, by configuring relevant Kubernetes namespaces to enforce restricted pod security

standard. Application developers uh, have to implement, uh, their applications in such a way that they can execute correctly without elevated uh, privileges and ensure that, uh, non-root user uh, is, uh, set in container image. To implement the third, uh, principle, uh, defense in depth, platforms must, uh, provide a set of, uh, guardrails which, uh, ensure that all container images are scanned for vulnerabilities and those with uh,

high severity levels are not allowed to run in production Uh require specification of resource quotas to support scheduling and smooth execution of applications. And require configuring network policies, the internal Kubernetes firewall rules, to minimize the blast radius in case an application component is compromised. Application developers need to implement those guardrails by keeping their application dependencies up-to-date with all newest security patches. Understand the resource needs of their

applications. Uh and specify the resource quotas accordingly for all the components. And adhere to the principle of the least privilege in terms of network communication. And implement fine-grained Kubernetes network policies for all uh application To ensure resilience of our applications, platforms themselves should be highly available, which in case of Kubernetes is achieved by, for multiple control plane nodes. Moreover, application probes to automate the process of identifying

unhealthy components and self-healing needs to be supported. Application developers must understand the difference between various probes and implement them correctly so the platform can take corrective actions such as directing traffic uh to a different replica or restarting a container when a component fails. Another example of best practices include failing the startup probe during database migration to specify a different timeout for that phase. A failing a readiness

probe in if a downstream service is unavailable and the application cannot deliver a useful service. And handling SIGTERM by failing the readiness probe, draining connections, and exiting gracefully to allow hitless rolling updates. Due to time limitations, I have discussed only selected non-functional requirements which needs to be fulfilled by a combination of platform capabilities and application level For a more exhaustive list of 47 NFRs, I would like

to refer you to the website of the Velkin project. Just visit elasticis.io website and search for prepare your application or non-functional Let's wrap up with a couple of key takeaways which will help you when you find yourself standing in front of that whiteboard next time and designing an architecture of your future First, cloud-native platforms will help you with fulfilling non-functional requirements when selected and utilized correctly. Second,

there is still a lot of work to be done by application developers in order to fully benefit from the platform So, it's important that while making the decisions about the in front of that whiteboard, you frequently ask yourself how the platform can help me to achieve these NFRs. Thank you all. Um