designing cloud native applications file• agile development methodologies and the devops culture...

Designing Cloud Native Applicationswith Microservices and Containersv2.0

Hector Morales, Technology Solutions Architect

[email protected]

DEVNET-1230

• Introduction to Cloud-native Applications

• Cloud-native Framework

• Web Application Design Principles and Cloud Patterns

• Microservices

• Containers 101

• Container Orchestration

• CI/CD

• Cloud-native Applications Design Framework

• Conclusion

Agenda

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

What we will discuss• Cloud native applications principles: architecture, microservices, containers and dynamic scheduling on top of cloud computing

infrastructure

• Web-scale architectures in Cloud Native Applications

• Agile Development Methodologies and the DevOps culture

• Continuous Integration, Delivery and Development pipeline, Development, Testing and Integration tools for Cloud Native Applications

• An overview of Containers, Container Management and Container Orchestration Technologies to automate the compute, storage and networking infrastructure

• Standardization efforts for Cloud Native Applications.


Cloud Native Application

A cloud-native application 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 design patterns and operated on a self-service elastic platform[1]

5DEVNET-1230

[1] N. Kratzke and R. Peinl, "ClouNS - A Cloud-native Application Reference Model for

Enterprise Architects," in IEEE Xplore, Amsterdam, 2016.


Cloud Native Framework

• Cloud Computing Essential Characteristics:• On-demand and self-service,

• Broad network access,

• Resource pooling,

• Rapid elasticity and

• Measured service

• Framework… • Cloud Service Models: IaaS, PaaS, SaaS

• Cloud-focused Patterns

• Web-scale Architectures

• Microservices, API’s and Containers

• Container Management, Orchestration and Scheduling

6DEVNET-1230

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco PublicDEVNET-1230

From Monolithic to Fully-distributed apps

Web Server+

Application

+

Database

Physical Server

Web Server

Physical Server

Application

Physical Server

Database

Physical Server

Physical Server

Physical Server

Physical Server

Hypervisor

Web Server

Web Server

Hypervisor

App App

Hypervisor

DB DB

OS OS OS OS OS OSPhysical Server

Kernel

Web Server

Web Server

Web Server

Web Server

Web Server

Web Server

Web Server

Web Server

Physical Server

Kernel

App App

App App

App App

Physical Server

Kernel

DB DB

DB DB

Requirements

Flexibility/Scale

Vertical Scale

• Physical Servers

• More resources

Horizontal Scale

• Virtual Servers

• More utilization

Web/Hyper Scale

• Containers and Microservices

• More scalability


Web Application properties

• Scalability – a system property to dynamically adapt to demand

• High-availability – a design that ensures operational continuity

• Performance – a system property to respond accordingly to a request or trigger

• Manageability – the system has to be managed easily and natively

• Feature-rich – the system has to offer features easily according to user demand or needs

• Low-cost – development, deployment, operations and scale is proportional to the size of the system and it is variable in costs but not exponential

• Revenue-generator – more importantly, the application has to generate money almost immediately to cover costs initially but to produce margins

8DEVNET-1230

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 9DEVNET-1230

Cloud Patterns

PaaS

Public Cloud

Elastic Infrastructure

Block Storage

Virtual Networking

3-tier cloud application

• Cloud Computing Fundamentals

• Cloud Service Models

• Cloud Deployment Models

• Cloud Offering Patterns

• Cloud Architecture Patterns

• Cloud Application Management Patterns

• Composite Cloud Application PatternsDistributed application

Elastic LB

License: http://creativecommons.org/licenses/by/4.0/


Software-based vs Infrastructure-based Design

• 12-factor App Design Approach

• All referred as code routines

• Agile Development

• Platform: clusters, containers, schedulers, virtual overlays

• All referred as Infrastructure components: compute, storage, network

• Agile IT

Development

Domain

Operations

Domain

SOURCE: Subway map to Agile Practices

https://www.agilealliance.org/agile101/subway-map-to-agile-practices/

AGILE METHODOLOGIES• Agile Scrum Methodology

• Lean and Kanban Software Development

• Extreme Programming

• Crystal methodologies

• Dynamic System Development Method

• Feature-Driven Development

Dev

Ops

https://www.agilealliance.org/agile101/subway-map-to-agile-practices/


Distributed Applications and Services

• In a distributed application, different pieces of the app are called “services.”

• Services are also called microservices because they are small and dedicated to specific functions as we have shown in first section

• The services or microservices are really just “containers in production.”

• A service only runs one image, but it codifies the way that image runs—what ports it should use, how many replicas of the container should run so the service has the capacity it needs, and so on.

• Scaling a service changes the number of container instances running that piece of software, assigning more computing resources to the service in the process.

• API’s – is a software interface used to communicate microservices.

Cloud Native App

API API

Front End

Service 1

Front End

Service 2

Front End

Service 3

Front End

Service 4

Back End

Service 1

Back End

Service 2

Communication Logic

API

API

API API API

API

NOTE: For our discussion, a microservice is a

cloud-hosted service that delivers a specific

narrowly scope capability and responds to a

business need or requirement

DEVNET-1230 11


Container TechnologiesAn Architecture View

Infrastructure

Runtime

Orchestration

Kubernetes

Container Platforms

Nomad

12


Containers

• Docker Containers - Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications using Containers. http://docker.org

• Single-process support

• Stateless

• Linux Containers or LXC - The goal is to offer a distro and vendor neutral environment for the development of Linux container technologies. http://linuxcontainers.org

• Multi-process support

• Stateful

• Other container technologies: Rkt, Open Containers

• https://coreos.com/rkt/

• https://www.opencontainers.org/

NOTE: For our discussion, we will focus on Docker Containers only. However, with the

proposed methodology any container technology and tooling can be used

http://docker.org/

http://linuxcontainers.org/

https://coreos.com/rkt/

https://www.opencontainers.org/


Host

14

What makes a container?• Linux kernel namespaces provide a worskpace

isolated from the rest of the resources (hence the term "container")

• Linux kernel cgroups – Control Groups – provide the resource limiting and accounting needed inside the container: CPU, Memory, I/O, Bandwidth

• Docker Engine uses namespaces such as the following on Linux: • The pid namespace: Process isolation (PID: Process ID).

• The net namespace: Managing network interfaces (NET: Networking).

• The ipc namespace: Managing access to IPC resources (IPC: InterProcess Communication).

• The mnt namespace: Managing filesystem mount points (MNT: Mount).

• The uts namespace: Isolating kernel and version identifiers. (UTS: Unix Timesharing System).

Container

Kernel

cgroup

pid

mount IPC user uts

network

Container Engine

DEVNET-1230


Dynamic schedulers using Swarm clusters as example

• A swarm is a group of machines that are running Docker

and joined into a cluster.

• After that has happened, you continue to run the Docker

commands you’re used to, but now they are executed

on a cluster by a swarm manager.

• The machines in a swarm can be physical or virtual.

After joining a swarm, they are referred to as nodes

(workers).

• Swarm is made up of multiple nodes, physical or virtual

• The concept is simple:

Multi-Host

Docker Engine

Kernel

Webnet Network

Docker Swarm - Manager

Docker Engine

Kernel

Webnet Network

Docker Swarm - Node

Instance

Flask

Redis

Instance

Flask

Redis

Instance

Flask

Redis

Docker Engine

Kernel

Webnet Network

Docker Swarm - Node

Instance

Flask

Redis

Instance Instance

VisualizerVisualizer

Webnet Network

Docker

Swarm Manager

CLI commands and Capacity Management

Docker

Swarm Worker

Provide capacity for App Instances

$ docker swarm init # Enable swarm mode and make current machine the manager$ docker swarm join # Enable machine to join the swarm as workers

• Kubernetes

Master/Nodes

architecture is also

another scheduling

mechanism (see slide in a

minute or 2)

DEVNET-1230 15


Container Management

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

Host

Kernel

Container

cgroup

pid

mount IPC user uts

network

Container

cgroup

pid

mount IPC user uts

network

Container Engine

Container

cgroup

pid

mount IPC user uts

network

• Manageability

• Flexibility

• Portability

• Container clustering

• Container orchestration at scale

• Web-scale automation


Container Orchestration using Kubernetes

• A Kubernetes (or K8) is an open-source

platform designed to automate deploying,

scaling, and operating application containers.

• Kubernetes components:

• Cluster (at least 3 nodes)

• Container engine (Docker, Rkt or Open

Container are supported engines)

• Kubernetes cluster:

• Master – coordinates the cluster and also

schedules the Pods

• Nodes – workers that run applications

• Kubelet – agent that communicates with

Kubernetes Master

• Nodes must have a container engine

• Pods are the atomic unit on the Kubernetes

platform

• Deployment creates Pods with containers and

other resources like volumes inside them

K8 Cluster

Node

K8

Master

Pod

Kubelet

C1

Application instances

Docker

C2 C3

Pod

C1 C2

Node

Kubelet Docker

Node

Kubelet Docker


Container Networking

Host: myvm1

192.168.99.100

Host: myvm2

192.168.99.101

clivestartup_webnet

10.0.0.0/24

Gateway 10.0.0.1

C

1

C

3

C

5

C

6

C

8

End

Point

ingress

10.255.0.0/16

Gateway 10.255.0.1

clivestartup_webnet

10.0.0.0/24

Gateway 10.0.0.1

C

2

C

4

C

7

C

9

C

1

0

End

Point

ingress

10.255.0.0/16

Gateway 10.255.0.1

Swarm Swarm

K8 Cluster

Node 1

K8

Master

Pod

Kubelet

C1

Docker

C2 Vol

Pod

C1 Vol

172.18.0.2 172.18.0.3

Node 2

Kubelet` Docker

Pod

C1 C2 Vol

20.2.2.2

Node 1 IP

172.17.0.46

Node 2 IP

20.0.0.2

C1 IP: 10.0.0.1 C1 IP: 10.0.0.1


The role of containers in Cloud Native Applications

• Traditional IT Applications developers : they can't create a piece of infrastructure from the code

• Microservices is the architecture evolution from Monolithic Application to Web-Scale Applications

• Containers is the evolution from bare metal and virtual servers to a Web-Scale Flexible Infrastructure

• Containers are running instances that are invoked in quantity as needed and are called as a process – Infrastructure as code

19DEVNET-1230

Monolithic

Application


Continuous Integration, Delivery and Deployment

Continuous Integration (CI)

Source

Control

Phase

Build

Phase

Staging

Phase

Production

Phase

Continuous Delivery (CD)

Continuous Deployment

v1.1

v2.0

v1.0

Needs Approval to deploy

Automatic deployment

Automated Process

Automated Process

Central

Repository

Commit

ChangesRun Build Test

Run Unit Test

Deploy to stage environment

Run integration and load tests

Deploy to production environment


Traditional IT vs Cloud Native Applications

Traditional IT Cloud Native

Requirements Complete requirements gathering

to begin design

Requirements are gather as they

appear

Design Waterfall development Agile development

Architecture Scale Up, Vertical growth Scale Out, Horizontal Growth

Deployment Virtual Machines on Dedicated

servers

Containers on Commodity

servers,

Platform Traditional Data Center Cloud Computing

Operations TOGAF, ITIL DevOps

Maintenance Waterfall, Complex, expensive CI/CD

Consumption Model Standard up front payments As a Service

21DEVNET-1230


Cloud Native App

API API

Front End

Service 1

Front End

Service 2

Front End

Service 3

Front End

Service 4

Back End

Service 1

Back End

Service 2

Communication Logic

API

API

Public API’s

Internal API’s API API API

API

Microservices

22DEVNET-1230

Cloud Native Applications Design Framework

DevelopersOther

systems/appsUser Functionality

App LogicCloud

Patterns

Container Runtime

Engine

Container

Orchestration

Engine

Cloud Platform

(IaaS, PaaS, FaaS)

Users for my App

Business Service map to

a Microservice

Business Intelligence

and Support Services

map to a Microservice

Container instances


STEP OBJECTIVE Comments

1. What is my expected User Functionality? IDENTIFY APP FUNCTIONALITY Test your idea and build your MVP

2. What are my Revenue Generating SERVICES? IDENTIFY PUBLIC MICROSERVICES Start with basic functionality and code initial idea

3. What SERVICES talk to External World? PUBLIC

API’S, CLIENTS

IDENTIFY PUBLIC API’S Envision which clients your app will use: Mobile, Web,

Sensors Platforms, Microcontrollers, Other Apps, etc

4. What are my SUPPORT SERVICES? IDENTIFY SUPPORT MICROSERVICES What stuff my app needs to work on the Backend: DB,

Analytics, IA etc. My app can talk to other systems?

5. How the SERVICES talk between them? DEFINE APPLICATION LOGIC How the app will communicate? What is the flow?

6. What is the best Cloud Pattern for my App? DEFINE CLOUD PATTERN Static or Dynamic Workflows, 2-Tier, 3-Tier, Multitenancy, etc

7. How services will interact between them? DEFINE COMMUNICATION LOGIC Do I need internal API’s? Queues? Comm Bus?

8. How my app will deal with elasticity? DEFINE DYNAMIC SCHEDULING Code your app to dynamically adjust demand: load balancers,

network overlay, container-specific tools (i.e. Swarms,

Kubernetes)

9. Choose your container runtime engine DEFINE CONTAINER STACK Docker, Rkt, Linux Containers, Open Containers, Cloud Native

Foundation

10. Choose your container orchestration engine DEFINE CONTAINER ORCHESTRATION Cloud-based (AWS, Azure, Google, etc), Docker EE,

Kubernetes, Mesos, Marathon, other

11. Choose your cloud platform DEFINE CLOUD SERVICE MODELS,

DEPLOYMENT MODELS

IaaS, PaaS, FaaS, Public, Private, AWS, GCP, AZURE,

OPENSTACK-BASED, Other

12. Choose your CI/CD pipeline CI/CD as a Service or Private Deployment Cloud-provided (AWS, Azure, IBM, GCP), On-premise

13. Choose your DevOps Agile Framework CHOOSE AGILE METHODOLOGY Agile Scrum, Lean and Kanban Software Development,

Extreme Programming, Crystal, Dynamic System

Development Method

Feature-Driven Development


Industry Standardization

• Docker is a standard de-facto:• Infra kit

• Linux kit• Containerd

• Open Container initiative:• Run-time specification

• Image-spec• https://www.opencontainers.org/

• Project Moby:• Moby is an open framework created by Docker to assemble specialized container systems without reinventing the

wheel. It provides a “lego set” of dozens of standard components and a framework for assembling them into custom platforms

• https://mobyproject.org/

• Cloud Native Computing Foundation:• Create and drive the adoption of a new computing paradigm that is optimized for modern distributed systems

environments capable of scaling to tens of thousands of self healing multi-tenant nodes• https://www.cncf.io/

24DEVNET-1230

https://www.opencontainers.org/

https://mobyproject.org/

https://www.cncf.io/


Cisco Live Barcelona Announcement

• https://blogs.cisco.com/cloud/ciscocontainerplatform

25DEVNET-1230

https://blogs.cisco.com/cloud/ciscocontainerplatform


Some references

C. Fehling, F. Leymann, R. Retter, W. Schupeck and P. Arbitter, Cloud Computing Patterns: Fundamentals to Design, Build, and Manage Cloud Applications, 1st edition ed., Vienna: Springer, 2014.

P. Mell and T. Grance, "National Institute of Standards and Technology, US Department of Commerce," 1 September 2011. [Online]. Available: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf. [Accessed 30 04 2017].

N. Kratzke and R. Peinl, "ClouNS - A Cloud-native Application Reference Model for Enterprise Architects," in IEEE Xplore, Amsterdam, 2016.

S. W. Devine, E. Bugnion and M. Rosenblum, " Virtualization system including a virtual machine monitor for a computer with a segmented architecture". United States of America Patent 6,397,242, 26 October 1998.

J. Engates, "The 7 Stages of Scaling Web Apps," in LinuxWorld Conference and Expo, San Francisco, 2008.

A. Wiggins, "The Twelve Factor App," The Twelve Factor App, 30 January 2012. [Online]. Available: https://12factor.net/. [Accessed 8 May 2017].

D. Hughey, "Comparing Traditional Systems Analysis and Design with Agile Methodologies," University of Missouri-St. Louis, 2009. [Online]. Available: http://www.umsl.edu/~hugheyd/is6840/waterfall.html. [Accessed 15 May 2017].

M. McLaughlin, "What is Agile Methodology?," VersionOne, 2017. [Online]. Available: https://www.versionone.com/agile-101/agile-methodologies/. [Accessed 1 May 2017].

Agile Alliance, "Manifesto for Agile Development Software," Agile Alliance, 4 August 2008. [Online]. Available: https://www.agilealliance.org/agile101/the-agile-manifesto/. [Accessed 1 May 2017].

H. Morales, “Designing Cloud Native Applications with Microservices and Containers”, in Applications for Future Internet Summit, Toluca, Mexico, 2017


Cisco Spark

Questions? Use Cisco Spark to communicate with the speaker after the session

1. Find this session in the Cisco Live Mobile App

2. Click “Join the Discussion”

3. Install Spark or go directly to the space

4. Enter messages/questions in the space

How

cs.co/ciscolivebot#DEVNET-1230


• Please complete your Online Session Evaluations after each session

• Complete 4 Session Evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt

• All surveys can be completed via the Cisco Live Mobile App or the Communication Stations

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at www.ciscolive.com/global/on-demand-library/.

Complete Your Online Session Evaluation

http://ciscolive.com/Online

http://www.ciscolive.com/global/on-demand-library/


Continue Your Education

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Tech Circle

• Meet the Engineer 1:1 meetings

• Related sessions:

• SOLCLD-1001 and PSOCLD-1225 – Containers and Microservices to Accelerate your Digital Business

• BRKCLD – Containers on Baremetal is a reality on Cisco UCS

• BRKSDN-2115 – Introduction to Containers and Container Networking

• BRKSDN-2256 – Container Networking Deep Dive with Docker Enterprise Edition and Cisco Contiv

29DEVNET-1230

Thank you

designing cloud native applications file• agile development methodologies and the devops culture...

Documents