jspωiki
Cloud Native

Overview#

Cloud Native 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

Cloud Native is the automation and Orchestration many modern Information Technology components:

Cloud Native 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.

Cloud Native 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 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 Cloud Native 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 Cloud Native 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.

Cloud Native Design Principles#

Principle 1: Design for automation#

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, Cloud Native 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 #

Principle 4: Practice defense in depth#

Cloud Native architectures have their origins in internet-facing services, and so have always needed to deal with external attacks. Cloud Native should use Zero Trust Networks and require Mutual Authentication between Devices

Cloud Native 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-Users.

Principle 5: Always be architecting#

Todays businesses are always changing to create Business value. Information Technology must constantly adapt to these changes.

Cloud Native 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: