This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 396 lines
!!! 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