Cloud I - Introduction

Chesapeake Node.js User Group (CNUG)

https://www.meetup.com/Chesapeake-Region-nodeJS-Developers-Group

3

START BUILDING: CALLFORCODE.ORG

Agenda

➢ Cloud Offerings (“Cloud 1.0”)❑ Infrastructure as a Service (IaaS)

❑ Platform as a Service (PaaS)

❑ Software as a Service (SaaS)

➢ Cloud (Linux) Runtime Stack (“Cloud 2.0”)❑ Docker (Containers)

❑ Kubernetes (Container Management)

❑ Helm (Kubernetes Packaging)

❑ Istio (Services Mesh)

➢ Core Cloud Concepts✓ Location Independence

✓ Dynamic Scaling

Cloud Offerings➢ Remote

✓ Facilities

➢ Bare Metal✓ + Network

✓ + Storage

✓ + Compute

➢ IaaS✓ + OS

➢ PaaS✓ + DB & Mgmt

✓ + Middleware

✓ + App Hosting

➢ SaaS✓ + Application

Bare Metal, IaaS, and PaaS Offerings

➢ Remote Computing is NOT new!

❑ First Generation Computing (1950s – 1960s)✓ Timesharing (now called IaaS or PaaS)

❑ Second & Third Generation Computing (1970s – 2000s)✓ Remote Sites (typical Disaster Recovery solution)

✓ Passive PaaS

➢ Global Cloud Market

❑ Market size could reach $100 Billion by 2020

❑ Market Share✓ Amazon (32%), Microsoft (13%), IBM (7%), Google (6%)

✓ IBM Offering is IBM Cloud (fka SoftLayer)

➢ Market evolving towards SaaS model

Hybrid Offerings

➢ Public Cloud

❑ Service Providers✓ Amazon, Microsoft, IBM, Google

✓ Provider provisions and manages Service provided

❑ Services✓ Bare Metal, IaaS, PaaS, SaaS

✓ Increasing number of PaaS, and SaaS options

❑ Provisioning✓ Public (Shared infrastructure)

✓ Dedicated (Isolated & Dedicated infrastructure)

➢ Private Cloud

❑ Run Cloud Software Stack (“2.0”) On-premises✓ IBM Private Cloud (IPC)

Cloud “2.0” Software Stack - Docker

➢ Developed by

Solomon Hykes

➢ Released in 2013

➢ Uses Linux features❑ cgroups

❑ Namespaces

❑ “Union” file system

➢ Union file system

➢ Open Source❑ Open Container

Initiative

❑ Cloud Native

Computing Foundation

Docker Overview (1)

➢ Conceptual Framework❑ Software executes in “Containers”

❑ Containers are based upon native Linux capabilities

❑ A Container is a single isolated & encapsulated thread

✓ Everything necessary to execute (i.e. libraries)

❑ A Container is a run-time instance of an “Image”

✓ Images stored in Docker registries

➢ Containers are managed by a daemon❑ dockerd (Docker container daemon)

❑ containerd (Open Source container daemon)

❑ Container isolated from all other non-kernel processes

❑ Scope of daemon is only server wide

Docker Overview (2)

➢ Virtual Machines versus Containers

❑ Virtual Machines

✓ Implement a “virtual” Operating System

✓ General purpose

✓ Multi-threaded

✓ Shared resources for multiple processes

✓ Slow to start up and shut down

❑ Containers

✓ Implement a “virtual” Thread

✓ Execute a single program

✓ Single-threaded (Single Linux thread)

✓ Resources dedicated to the software image

✓ Extremely fast to start up and shut down

Cloud “2.0” Software Stack - Kubernetes

➢ Developed by Google

➢ Released in 2015

➢ Turned over to the

Cloud Native

Computing

Foundation (CNCF)

➢ ”Clustering for

Containers”

➢ Docker Swarm and

Apache Mesos are

competing products

Kubernetes Overview

➢ Container Orchestration❑ Cluster Management

❑ Container Scheduling

❑ Service Discovery

❑ Dynamic Scaling (Managing Container instances)

❑ Health Maintenance (Health Checking & Repair)

➢ Single Docker instance only spans one server

➢ Kubernetes deploys “Pods” of Containers

❑ Pods contain one or more containers

❑ Pod instances deployed across multiple servers

❑ Number of Pod instances monitored and managed

Kubernetes Architecture

➢ Kubernetes Cluster

defined by Master

node.

➢ Pods distributed

across Worker

nodes.

➢ Client control

interface.

➢ Defined Pods and

Services.

Cloud “2.0” Software Stack - Helm

➢ Developed at Deis

➢ Released in 2015

➢ ”Packaging for

Kubernetes”

➢ Turned over to the

Cloud Native

Computing

Foundation (CNCF)

➢ Initial development

started with a short

Deis hackathon

Helm Overview

➢ Package Manager for Kubernetes

❑ Provides “Helm” Charts✓ A Helm Chart is a zipped directory (chart name = directory)

✓ Package multiple Kubernetes components into one charto Pods

o Services

o Ingress

o Volumes

✓ Separate Manifest data from Environment data

✓ Charts can be stored and versioned in a repository

✓ A “Release” is an instance of a Chart

❑ Simplifies managing deployments✓ Combines multiple Kubernetes actions into a single chart

✓ Creates a single reusable set of deployed objects (manifest)

✓ Isolates Environment settings for simplified deployment

migration (e.g. from Development to Production)

Helm Chart – Directory Structure

➢ Helm Chart Directory ❑ Chart.yaml (Chart metadata; YAML format)

❑ LICENSE (L) - optional

❑ README.md (Text file formatted using Markdown) - optional

❑ templates (Resource manifests; Directory)

o NOTES.txt (Text file)

o _helpers.tpl (Text file)

o configmap.yaml (YAML file)

o deployment.yaml (YAML file)

o pvc.yaml (YAML file)

o secrets.yaml (YAML file)

o svc.yaml (YAML file)

❑ values.yaml (Release Keys and Values; YAML format)

Helm Architecture

Helm Hooks➢ Custom processing during life cycle events.

➢ Hooks are standard manifest YAML files.

➢ Declared as annotations in manifest metadata.annotations:

“helm.sh/hook”: pre-install

“helm.sh/hook-weight”: “-5”

“helm.sh/hook-delete-policy”: hook-succeeded

Cloud “2.0” Software Stack - Istio

➢ Developed by IBM,

Google, & Lyft

➢ Released in 2017

➢ Service Discovery

(“Dynamic DNS”) for

the Cloud

➢ Consolidation of the

Amalgam8 (IBM),

Service Control

(Google), and Envoy

Proxy (Lyft) projects

Istio Overview

➢ The Problem:

❑ How can the location of a Service be determined?

➢ The Answer:

❑ A Service Mesh✓ Envoy Proxies are added as “sidecars” to Docker containers

✓ These sidecars are deployed as part of the Kubernetes Pod

✓ TCP requests routed through the Proxies.

✓ Proxies announce their existence to the “Control Plane”

o This allows them to receive inbound traffic

✓ Proxies route their requests through the “Control Plane”

o This allows them to receive inbound traffic

✓ Control Plane may also enforce Policies (Security, Traffic, etc.)

Istio Architecture

Cloud “2.0” Software Stack – NoSQL DB

➢ Term introduced 2009

➢ Refer to the newest

generation of

databases natively

designed for Cloud

➢ Cloud requirements❑ Horizontal scaling

✓ Dynamic

✓ Massive in scope

➢ Trade-Offs❑ Not transactional (XA)

❑ Lack ACID properties

NoSQL Database Overview

➢ Many products, many different features

❑ Document Databases✓ Cloudant (logo on right), CouchDB, MongoDB

✓ Store structured data (typically in JSON format)

❑ Key/Value Databases✓ Memcached, Redis

✓ Store individual “Values” referenced by “Keys”

✓ “State of the Art” in the 1960s

❑ CAP Theorem✓ Distributed Databases can only have two of three properties:

o Consistency (Each read retrieves the most current data)

o Availability (Each CRUD request is honored)

o Partition Tolerance (No effect from delay or loss of data)

Cloud “2.0” Software Stack - Microservices

➢ Term defined in 2011

➢ A reaction to the

general

misunderstanding of

SOA principles

➢ No new concepts

(Loose coupling,

High cohesion,

KISS)

➢ Concepts applied to

new environment

(containers).

Microservices Overview

➢ Software designed to run in containers

❑ Designed for dynamic scaling (horizontally)

❑ Designed for dynamic deployment (servers)

➢ Cloud based Languages and Run-times

❑ Cloud Native Computing Foundation (CNCF)

❑ Design Methodologies✓ 12 Factor

✓ Reactive

❑ Programming Languages✓ Liberty (Java)

✓ Node.js (JavaScript)

✓ Go Runtime (Go)

What’s Really Different in the Cloud? (1)

➢ Software as a Service (SaaS)❑ The world really IS heading in this direction

❑ Major examples:✓ Salesforce

✓ Amazon Web Services (AWS)

❑ IBM Products:✓ All major IBM products will run in multiple cloud environments

✓ IBM Cloud, ICP, AWS, Azure, …

➢ Location Independence❑ Software will be deployed to multiple locations

✓ On-premises across multiple data centers

✓ Across multiple “Cloud” providers

✓ Across multiple Cloud instances

❑ Software will execute on multiple servers

What’s Really Different in the Cloud? (2)

➢ Scaling❑ Containers are VERY lightweight

✓ A LinuxOne can launch tens of thousands containers/sec

✓ A LinuxOne can support over one million light containers

❑ Containers are quickly created and destroyed✓ Container locations can thus be extremely dynamic

✓ Container start up/shut down times measured microseconds

➢ Entirely New Application Environment❑ Deployed in containers

❑ Developed in new languages and runtimes✓ Go, JavaScript (Node.js), Node-RED

❑ Use new Databases & Filesystems✓ NoSQL

Questions?