Brief History

2006

• 13th March: Amazon S3 was launched
  
  New Terms:
   
• Public/Private/Hybrid Cloud Computing
• IaaS (Infrastructure as Code)
• PaaS (Platform as a Service)
• SaaS (Software as a Service)

2011

• "NIST Definiton of Cloud Computing" by Peter Mell and Timothy Grace - Glossary with recommendations of the National Institute of Standards and Technology
  
  > no mentioning of Cloud Native and Cloud Native Applications (CNA) yet even though the terms were already present

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

2012

• popularity of CNA was growing steadily and the usage of term got spread especially in academia
   
• first draft to Cloud-Native Engineering was presented at a research/computer science conference:
  
  contains pattern-based methodology for Cloud Native Application Designs, with systematic identification of consistencies, availability and outage tolerances (CAP-theorem)

2015

• sudden growth in popularity of the term "cloud native" and big traction in the industry which search trends of Google show..
• at that time Cloud Native Applications were recognized as the logical evolution of Microservies Architectures which took Containerization into acount
   
• now let's focus on research a bit more in detail

Cloud Native in Research

General Observation

• Over the course of many different scientific publications over all the years attributes were defined that applications need to comply to be calling/claiming themselves as cloud native
  
   – in contrast to classical  distributed systems

2017

A cumulative paper in the academic sector was published in 2016 and 2017:​

Understanding Cloud-native Applications after 10 years of Cloud Computing: A systematic mapping study

by Nane Katz and Peter-Christian-Quintus

of the Cloud Computing Research Group

at the University of Lübeck

https://www.researchgate.net/publication/312045183_Understanding_Cloud-native_Applications_after_10_Years_of_Cloud_Computing_-_A_Systematic_Mapping_Study

Definition after Analysis

A cloud-native application (CNA) is a distributed, elastic

and horizontal scalable system composed of (micro)services

which isolates state in a minimum of stateful components.

The application and each self-contained deployment unit of

that application is designed according to cloud-focused de-

sign patterns and operated on a self-service elastic platform.

considers the IDEAL attributes (2014)

• I = isolated state
• D = distributed in its nature
• E = elastic (horizontale scaling)
• A = automated management
• L = loosely coupled

considers assumptions for motivation of CNA architecture application (Kratz, Quintis 2014)

• speed
• safety
• scale
• client diversity

Balalie converted these motivational assumptions in applications- and infrastructure  approaches (2016)

• Microservices ("doing one thing well")
• Published and Versioned APIs (HTTP, REST, JSON)
• Collection of Cloud-Focused Patterns (The Twelve Factor App of Heroku, Circuit Breaker Pattern by Fowler, Cloud Computing Patterns by Fehling and Erlet)
• Self-Service Agile Infrastructure Platforms (delivery and operations tools as enclosed, container-based units; additional functionality via IaaS, request-based scaling of individual CNAs, monitoring, dynamic routing, load balancing, aggreation of logs and metrics)

Katz and Quintus also include other popular definitions

• Elasticity: workload based (de-)provisioning of systems and resources to every moment to align to the required payload of the business requirements/usage immediately
• Scalability: structual (align to specific desired dimension) and load-based scaling (steadily changing dimension)
• Microservices: to be developed architecture style by Fowler, should be based on Business Requirements, Use Domain-Driven Design instead of  technical-driven modelling approaches
  
  1/2

Katz and Quintus also include other popular definitions

• Self-contained Deployment Unit: technical implementation of units in the application delivery topography. standardized containers play an important role as defined by the  Open Container Initiative (OCI) in "5 Principles for Containers"
• Stateful Components: will be used to sync different instances  of application components to deliver a uniform behaviour
• Elastic Platform: is an integreated distribution plattform to run specific applications incl. their communication, data storage and other services (e.g. K8s, Swarm, OpenShift)

2/2

• DevOps: Das Bauen, Testen und Veröffentlichen von Software soll durch Automatisierung schneller, häufiger und zuverlässiger erfolgen. Entwickler und Operations sollen hierbei enger zusammenarbeiten. Stichwort: Cross-funktionale Teams.
• Softwareization Shift: beschreibt die voranschreitende Automatisierung im Infrastruktur- und Netzwerkbereich durch Softwarelösungen.
• Stateisolation: Stateless Komponenten sind leichter zu skalieren, daher sollten Stateful Komponenten auf ein Miniumum reduziert werden. Diese sollen bevorzugt mit Hilfe von skalierbaren Datenspeichern wie (No)SQL-Datenbanken abgebildet werden.
• Loose Coupling: Diese Art der Servicekomposition kann durch Events oder Daten möglich. Event Coupling wird hierbei durch Messaging-Lösungen wie den AMQP-Standard realisiert. Data Coupling hingegen wird häufig durch skalierbare und hochperformante Speicherlösungen realisiert, welche häufig (nur) dem Konzept der Eventual Consistency folgen. Beispiele sind NoSQL-Datenbanken.

Cloud Native in the Industry

The traditional IT “best practices” are counterproductive because they solve
 a completely different problem

What are the new drivers?

What are the new goals?

How should organizations look like?

What are the implications?

Cloud Native Architecture

General Recommendation

• Why is software eating the world? (Marc Andreessen)
  > Not true! Not every company needs to become a software company
   
• CNA should still be always observed to not be hit by digital, disruptive business models and go bankrupt like Uber, AirBnB, Netflix
   
• market leaders provide open source solution for going into the cloud -> use them (e.g. NetflixxOSS released in 2012 to the public)

Cloud Native Foundation

Im Jahr 2015 hat sich dann erstmal ein Konsortium bestehend aus weiteren Vorreitern in der IT für Cloud-Anwendungen unter dem Dach der Linux Foundation als neu gegründete Cloud Native Computing Foundation (CNCF, www.cncf.io) zusammengetan, welches mittlerweile aus über 100.000 Mitgliedern besteht. Unter den Gründungsmitgliedern sind u.a. Firmen wie Cloud Foundry, Core OS, Docker, Google, Mesosphere, Red Hat, Twitter, VMWare oder Weaveworks anzutreffen, welche sich als gemeinsames Ziel gesetzt haben, bestehende Technologien zu standardisieren und Projekte als Open Source zu kultivieren um so den Einstieg in die Cloud Native Welt für Entwickler und auch andere Unternehmen zu erleichtern

 Modern Definitions

by Tool Companies

• https://netflix.github.io/

• https://pivotal.io/de/cloud-nativ

• https://www.redhat.com/de/solutions/cloud-native-development

Agreed Definition by CNCF Members

• https://github.com/cncf/toc/blob/master/DEFINITION.md

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

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.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

3 Core Topics for Companies

• Speed: Firmen sollen schnell an Apps arbeiten können, ohne sich lange mit der Infrastruktur, Integration oder einhergehenden Experimenten und Bugs aufhalten müssen.
• Freedom: Jede App soll basierend auf Open Source Packaging überall laufen können, um einen Cloud Service Vendor Lock-In zu vermeiden
• Trust: Firmen müssen auf eine Uptime von 24/7 mit hoher Wiederherstellungsrate (Recovery Time) vertrauen können, wobei jede Komponente unabhängig skalierbar ist.

Project Types

• Graduated Projects: Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd
• Incubating Projects: u.a. OpenTracing, gRPC, Linkerd, Helm, etcd
• Sandbox Projects: Aktuell sind dies über 20 Projekte.

Cloud Native Landscape

https://landscape.cncf.io

Cloud Native Trailmap

https://github.com/cncf/trailmap

Other Initatives

• 12 Factor App Manifest [10]: https://12factor.net
• Open Container Initiative [11]:
  https://www.opencontainers.org
• Resilient Software Design Patterns
• SOLID Principles for Cloud Native Applications [12]:
  https://www.redhat.com/files/summit/session-assets/2018/M1135-SOLID-principles-for-cloud-native-applications-Distribution.pdf
• Cloud Native Container Design Principles [13]:
  https://dzone.com/articles/cloud-native-container-design-principles

Future & Wrap-Up

• Markets have changed

• IT has changed

• The role of IT has changed

• New drivers

• New goals

• New building blocks

• DevOps results in a re-org of IT

• DevOps drives implementation of a new IT

https://www.doag.org/de/home/news/die-red-stack-052019-ist-online-cloud-native/detail/

Sources