!!! Overview
[{$pagename}] is an [Architecture] [model] used within the [design] and [implementation] of running [applications] that exploits many of the advantages of the [Cloud computing] delivery model to rapidly provide increased [Business value]


[{$pagename}] is an extension of the [DevOps] concept.

[{$pagename}] is the automation and [Orchestration] many modern [Information Technology] components:
* [Agile] [Software design]
* [DevOps]
* [Continuous Delivery]
* [Microservices]
* [Containers]
* [Container Orchestration]
* [Elasticity] 
[{$pagename}] is about how [applications] are created and deployed, not where. While today public [cloud] impacts the thinking about infrastructure investment for virtually every industry, a [cloud]-like delivery model isn’t exclusive to public environments. It's appropriate for both public and private [clouds].

!! [{$pagename}] and [Design]
While the [Functional Requirement] don't change too much, the [cloud] offers, and sometimes requires, very different ways to meet [Functional Requirements], and imposes very different [Architectural|Architecture] [constraints]. If architects fail to adapt their approach to these different [constraints], the systems they architect are often fragile, expensive, and hard to maintain. A well-architected [{$pagename}] system, on the other hand, should be largely self-healing, cost efficient, and easily updated and maintained through [Continuous integration]/[Continuous Delivery] ([CI]/[CD]).

The good news is that [cloud] is made of the same fabric of [servers], [disks] and [networks] that makes up traditional infrastructure. This means that almost all of the principles of good architectural [design] still apply for [{$pagename}] architecture. However, some of the fundamental assumptions about how that fabric performs change when you’re in the [cloud]. For instance, provisioning a replacement [server] can take weeks in traditional environments, whereas in the [cloud], it takes seconds—your [application] architecture needs to take that into account.


!! [{$pagename}] [Design] Principles

! Principle 1: [Design] for automation
** [Continuous Development]
** [Continuous testing]
** [Continuous integration]
** [Continuous Delivery]
** [Continuous Improvement]

! Principle 2: Be smart with [state]
Storing of '[state]', be that 
* user [data] (e.g., the items in the users shopping cart, or their employee number) 
* system [state] (e.g., how many instances of a job are running, what version of code is running in production)
is the hardest aspect of architecting a distributed, [{$pagename}] [architecture]. You should therefore architect your system to be intentional about when, and how, you store [state], and design components to be [stateless] wherever you can.
[Stateless] components make it easier to:
* for [Elasticity]
* Repair: To 'repair' a failed instance of a component, simply terminate it as gracefully as possible and spin up a replacement.
* Roll-back: If you have a bad deployment, stateless components are much easier to roll back, since you can terminate them and launch instances of the old version instead.
* [Load Balancing] is easier for [Stateless] components


! Principle 3: Favor managed services 
** [PaaS]
** [SaaS]
** [IDaaS]
** [Provider of services] ...

! Principle 4: Practice defense in depth
[{$pagename}] [architectures] have their origins in [internet]-facing services, and so have always needed to deal with external [attacks]. [{$pagename}] should use [Zero Trust] [Networks] and require [Mutual Authentication] between [Devices]

[{$pagename}] [architectures] should extend this idea beyond [authentication] to include things like [Server-Side Login throttling schemes] and [data] or [Code injection]. Each component in a design should seek to protect itself from the other components. This not only makes the [architecture] very resilient, it also makes the resulting services easier to deploy in a [cloud] environment, where there may not be a [Trusted network] between the [service] and its [End-User]s.























































































! Principle 5: Always be architecting
Todays businesses are always changing to create [Business value]. [Information Technology] must constantly adapt to these changes.

[{$pagename}] must always seek to refine, simplify and improve the [architecture] of the system, as the needs of the organization change, the landscape of your [IT ]systems change, and the capabilities of your [Cloud Service Provider] itself change. While this undoubtedly requires constant investment, the lessons of the past are clear: to evolve, grow, and respond, IT systems need to live and breath and change. Dead, obsolete [Information Technology] systems rapidly bring the organization to a standstill, unable to respond to new [threats] and [Opportunities].



































































!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [What are Cloud-Native Applications?|https://pivotal.io/cloud-native|target='_blank'] - based on information obtained 2019-06-22 
* [#2] - [Cloud Native Computing Foundation|https://www.cncf.io/|target='_blank'] - based on information obtained 2019-06-22 
* [#3] - [10 KEY ATTRIBUTES OF CLOUD-NATIVE APPLICATIONS|https://thenewstack.io/10-key-attributes-of-cloud-native-applications/|target='_blank'] - based on information obtained 2019-06-22 
* [#4] - [5 principles for cloud-native architecture—what it is and how to master it|https://cloud.google.com/blog/products/application-development/5-principles-for-cloud-native-architecture-what-it-is-and-how-to-master-it|target='_blank'] - based on information obtained 2019-06-22