Continuous Delivery is the ability to get software changes - including new features, enhancements, configuration changes, and bug fixes - into production safely and quickly, in a sustainable way. In these slides, I am giving a very high-level introduction to microservices architecture, and why it is considered as enabler to continuous delivery. We cover the key characteristics of a microservice, some common concepts, architectural patterns, and implementation guidelines. In addition, we quickly cover the main concepts and activities in DevOps, which the Application Lifecycle Management process to support continuous delivery.

1. | © Copyright 2015 Hitachi Consulting1
Microservices & DevOps
Software Architectures for Continuous Delivery
Khalid M. Salama, Ph.D.
Business Insights & Analytics
Hitachi Consulting UK
We Make it Happen. Better.

2. | © Copyright 2015 Hitachi Consulting2
Outline
 What is Continuous Delivery?
 Operational Objectives of a Software Architecture
 Service-Oriented Software Systems
 Microservices – Characteristics, Patterns, and Guidelines
 Application Life-cycle Management (ALM): Then vs. Now.
 DevOps Concepts & Activities
 The 12-Factor App
 Resources & Useful links

3. | © Copyright 2015 Hitachi Consulting3
Continuous Delivery

4. | © Copyright 2015 Hitachi Consulting4
What is Continuous Delivery?
Continuous Delivery is the ability to get software changes - including new features,
enhancements, configuration changes, and bug fixes - into production (for end users)
safely and quickly, in a sustainable way
Overview

5. | © Copyright 2015 Hitachi Consulting5
What is Continuous Delivery?
Continuous Delivery is the ability to get software changes - including new features,
enhancements, configuration changes, and bug fixes - into production (for end users)
safely and quickly, in a sustainable way
Overview
Faster Time to Market,
with lower cost and
risks, and higher
quality

6. | © Copyright 2015 Hitachi Consulting6
What is Continuous Delivery?
Continuous Delivery is the ability to get software changes - including new features,
enhancements, configuration changes, and bug fixes - into production (for end users)
safely and quickly, in a sustainable way
 Think about any software systems that have
millions of users using it 24/7, need new features
and enhancements all the time,
and can’t tolerate any downtime..
 E.g., facebook, gmail, digital retailers,
online banking, cloud services providers,
SaaS providers, etc.
Overview
Faster Time to Market,
with lower cost and
risks, and higher
quality

7. | © Copyright 2015 Hitachi Consulting7
What is Continuous Delivery?
How to achieve it?
Continuous
Delivery

8. | © Copyright 2015 Hitachi Consulting8
What is Continuous Delivery?
How to achieve it?
Continuous
Delivery
Modern Software Architecture
(& Technologies)
 Set of independent components (services)
 Organized around business capabilities
 Each is replaceable, extensible, versioned, and
deployable independently
 Containerization, scalability, and fault-tolerance of
individual services

9. | © Copyright 2015 Hitachi Consulting9
What is Continuous Delivery?
How to achieve it?
Continuous
Delivery
Modern Software Architecture
(& Technologies)
 Set of independent components (services)
 Organized around business capabilities
 Each is replaceable, extensible, versioned, and
deployable independently
 Containerization, scalability, and fault-tolerance of
individual services
Modern Application Lifecyle Management
(Process & Tools)
 Team Collaboration & Agile planning
 Source Control & Build Automation
 Automated testing and integration
 Automated deployment to different environments
 Release and configuration management
 Seamless integration between Dev and Ops activities

10. | © Copyright 2015 Hitachi Consulting10
What is Continuous Delivery?
How to achieve it?
Continuous
Delivery
Modern Software Architecture
(& Technologies)
 Set of independent components (services)
 Organized around business capabilities
 Each is replaceable, extensible, versioned, and
deployable independently
 Containerization, scalability, and fault-tolerance of
individual services
Modern Application Lifecyle Management
(Process & Tools)
 Team Collaboration & Agile planning
 Source Control & Build Automation
 Automated testing and integration
 Automated deployment to different environments
 Release and configuration management
 Seamless integration between Dev and Ops activities
Microservices DevOps

11. | © Copyright 2015 Hitachi Consulting11
Service-Oriented Software
Architecture

12. | © Copyright 2015 Hitachi Consulting12
Service-Oriented Architecture
The relational behind any software architecture is to meet the operational objectives
(non-functional requirements) of such a system…
Why we architect systems that way?

13. | © Copyright 2015 Hitachi Consulting13
Service-Oriented Architecture
The relational behind any software architecture is to meet the operational objectives
(non-functional requirements) of such a system…
Why we architect systems that way?
• Maintains performance with
increased data/workloadsScalability
• Operational 99.95% of the
time (reliable)
Availability
(Reliability)
• Maintains its data in an
(eventual) consistent state
Consistency
• Refers resilience and
recoverability
Fault-Tolerance
(Resilience)
• Ability to communicate,
exchange and process data
Interoperability
• Monitor, Configure, debug,
etc. (serviceability)
Supportability
• Can run on different
platforms
Portability
• Secure Identity, data at rest,
and communication
Security &
Protection

14. | © Copyright 2015 Hitachi Consulting14
Service-Oriented Architecture
The relational behind any software architecture is to meet the operational objectives
(non-functional requirements) of such a system…
Why we architect systems that way?
• Maintains performance with
increased data/workloadsScalability
• Operational 99.95% of the
time (reliable)
Availability
(Reliability)
• Maintains its data in an
(eventual) consistent state
Consistency
• Refers resilience and
recoverability
Fault-Tolerance
(Resilience)
• Ability to communicate,
exchange and process data
Interoperability
• Monitor, Configure, debug,
etc. (serviceability)
Supportability
• Can run on different
platforms
Portability
• Secure Identity, data at rest,
and communication
Security &
Protection
• Extensibility, Replicability,
Reusability, Composability
Agility
(non-behavioural)

15. | © Copyright 2015 Hitachi Consulting15
Service-Oriented Architecture
What is a Microservice?
Autonomous
a self-contained unit of
functionality with loosely
coupled dependencies on
other services.

16. | © Copyright 2015 Hitachi Consulting16
Service-Oriented Architecture
What is a Microservice?
AutonomousIsolated
Owned
Protects itself
from unwanted
access/usage
Owns
all of the state
(data) it depends
on
Organized
around
Business
Capabilities
Contained
In a separate
process, with
communication
endpoints
Replaceable &
Versioned
Elastic
a self-contained unit of
functionality with loosely
coupled dependencies on
other services.
a independent unit of
deployment, can be
modified, without
impacting other Services
Can be scaled
independently of
other services
owned by one team
from development
through deployment

17. | © Copyright 2015 Hitachi Consulting17
Service-Oriented Architecture
What is a Service?
AutonomousIsolated
Owned
Protects itself
from unwanted
access/usage
Owns
all of the state
(data) it depends
on
Organized
around
Business
Capabilities
Contained
In a separate
process, with
communication
endpoints
Replaceable &
Versioned
Elastic
a self-contained unit of
functionality with loosely
coupled dependencies on
other services.
a independent unit of
deployment, can be
modified, without
impacting other Services
Can be scaled
independently of
other services
Configurable
Programable
Open
(tech. agnostic
APIs
owned by one team
from development
through deployment
Automated

18. | © Copyright 2015 Hitachi Consulting18
Microservices Architecture
Overview - evolution
Stand-
alone
Client
Server
Browser
Web
Server
Db Server
Any Device
From Monolithic to Microservice
microservices

19. | © Copyright 2015 Hitachi Consulting19
Microservices Architecture
Overview – e-commerce example
Any Device UI
E-commerce Web App
API Gateway
Login/User Profile
Service
Product Catalog
Service
Shopping Cart
Service
Order Processing
Service
Recommendation
Service
Reporting
Service
.Net
Key/value
Java
Search
Index
.Net
Document
Ruby
RDBMS
Python
Graph
Scala
Column-
family
Cache Service

20. | © Copyright 2015 Hitachi Consulting20
Microservices Architecture
Patterns and Guidelines - Layers
Microservice
HTTP/REST APIs
Domain Model
Business Logic (rules, validation, calc.)
Repository (data access services)
Data store
Integration (queues)
SDK (public/private)
 Expose REST APIs for interoperability
 Contains its BL, Model, queues, and repository services
 Can be written in any language – Polyglot Programming
 Owns its data store, which can be any technology
(SQL/NoSQL) – Polyglot Persistence
 Provides SDK (for programmability)
 Runs on its own execution boundary
Layers = Code
organization

21. | © Copyright 2015 Hitachi Consulting21
Microservices Architecture
Patterns and Guidelines – Data Store
Microservice 1 Microservice 2
Data
 Data is passed across services, rather than
giving a refence to service data store
 No assumption about shared data store
 Enables schema evolution
 Enables choosing different data store
technologies that fit the processing nature
of each microservice function

22. | © Copyright 2015 Hitachi Consulting22
Microservices Architecture
Patterns and Guidelines – Integration
Service 1 Service 2
Service 3
Send command
/event
consume
Send command
/event
Consume
Queue 1
Queue 2
Enterprise Service Bus
Service 1 Service 2 Service 3
Orchestration Choreography

23. | © Copyright 2015 Hitachi Consulting23
Microservices Architecture
Patterns and Guidelines – Scalability
System
WebApp
Service Instance 1
WebApp
Service Instance 2
UI
 Multiple instance of the Web App are
spun to handle increase of requests

24. | © Copyright 2015 Hitachi Consulting24
Microservices Architecture
Patterns and Guidelines – Scalability
System
WebApp
Service Instance 1
WebApp
Service Instance 2
UI
Load Balancer
Request/Command
 Multiple instance of the Web App are
spun to handle increase of requests
 A load balancer handles the
incoming requests

25. | © Copyright 2015 Hitachi Consulting25
Microservices Architecture
Patterns and Guidelines – Scalability
System
WebApp
Service Instance 1
WebApp
Service Instance 2
UI
Load Balancer
Service 1 instance1
Service 1 instance2
Service 1 instance 3
Service 2 instance1
Service 3 instance1
Request/Command
Service 2 instance 2
 Multiple instance of the Web App are
spun to handle increase of requests
 A load balancer handles the
incoming requests
 1 or more instance are run for each
microservices, based on its
scalability needs

26. | © Copyright 2015 Hitachi Consulting26
Microservices Architecture
Patterns and Guidelines – Scalability
System
WebApp
Service Instance 1
WebApp
Service Instance 2
UI
Load Balancer
Service 1 instance1
Service
Registry
Service 1 instance2
Service 1 instance 3
Service 2 instance1
Service 3 instance1
Request/Command
Service 2 instance 2
 Multiple instance of the Web App are
spun to handle increase of requests
 A load balancer handles the
incoming requests
 1 or more instance are run for each
microservices, based on its
scalability needs
 Instance are registered in a service
registry, which is used to fetch the IP
of a particular service instance to use

27. | © Copyright 2015 Hitachi Consulting27
Microservices Architecture
Patterns and Guidelines – Scalability
System
WebApp
Service Instance 1
WebApp
Service Instance 2
UI
Load Balancer
Service 1 instance1
Service
Registry
Service 1 instance2
Service 1 instance 3
Service 2 instance1
Service 3 instance1
Request/Command
Service 2 instance 2
 Multiple instance of the Web App are
spun to handle increase of requests
 A load balancer handles the
incoming requests
 1 or more instance are run for each
microservices, based on its
scalability needs
 Instance are registered in a service
registry, which is used to fetch the IP
of a particular service instance to use
 Multiple instance of the database are
run and configured as cluster
 Data is sharded and distributed
amongst databased, with a
replication factor
 Service communicate with its
database as a one unit (regardless
of the sharding)

28. | © Copyright 2015 Hitachi Consulting28
Microservices Architecture
Pattern and Guidelines – Infrastructure
Rack 1
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
Rack 2
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
 Hardware infrastructure (on-prem or cloud IaaS),
which represent your compute resources

29. | © Copyright 2015 Hitachi Consulting29
Microservices Architecture
Pattern and Guidelines – Infrastructure
Rack 1
Cluster
VM1 VM2 VM3 VM4
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
Rack 2
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
 Hardware infrastructure (on-prem or cloud IaaS),
which represent your compute resources
 A set of VMs, connected though a network to
perform a cluster

30. | © Copyright 2015 Hitachi Consulting30
Microservices Architecture
Pattern and Guidelines – Infrastructure
Rack 1
Cluster
VM1 VM2 VM3 VM4
Service
(Container)
1
Service
(Container)
2
Service
(Container)
3
Service
(Container)
4
Service
(Container)
5
Service
(Container)
6
Service
(Container)
7
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
Rack 2
Service
(Container)
8
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
 Hardware infrastructure (on-prem or cloud IaaS),
which represent your compute resources
 A set of VMs, connected though a network to
perform a cluster
 (Containerized) services, each can have multiple
instance (each is a new container)

31. | © Copyright 2015 Hitachi Consulting31
Microservices Architecture
Pattern and Guidelines – Infrastructure
Rack 1
Cluster
VM1 VM2 VM3 VM4
Cluster Manager
Service
(Container)
1
Service
(Container)
2
Service
(Container)
3
Service
(Container)
4
Service
(Container)
5
Service
(Container)
6
Service
(Container)
7
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
Rack 2
Service
(Container)
8
Core 1 Core 2
Core 5 Core 6
Core 3 Core 4
Core 7 Core 8
 Hardware infrastructure (on-prem or cloud IaaS),
which represent your compute resources
 A set of VMs, connected though a network to
perform a cluster
 (Containerized) services, each can have multiple
instance (each is a new container)
 The cluster manager performs the following:
 Distributes service/containers within a
cluster
 Restarts services/containers in the case of
failure
 Redistributes services/containers based on
resource consumption

32. | © Copyright 2015 Hitachi Consulting32
Microservices Architecture
Containerization
What is a Container?
• Let you slice up the OS to run multiple services on a single OS
• Allows for a version set of dependencies (libraries, file system, runtimes, etc.) to run side by side
with another set of dependencies in an isolated runtime environment on the same machine
Why Containers?
 Encapsulate the application environment
 Improved application deployment and introspection
 Manage applications instead of machines
 Relieve developers and operations from being concerned with the
specific details of the machine and OS
 Allows infrastructure team flexibility in rolling out new hardware, OS,
or system SKUs without impacting applications
Microservices and containers?
 Microservices is an architectural design point; containers
are an implementation detail that often helps.
 Typically you run one application/service per container

33. | © Copyright 2015 Hitachi Consulting33
Multiplicityof
Goods
Multiplicityof
methodsfor
transporting/storing
DoIworryabout
howgoodsinteract
(e.g.coffeebeans
nexttospices)
CanItransportquickly
andsmoothly
(e.g.fromboattotrain
totruck)
…in between, can be loaded and
unloaded, stacked, transported
efficiently over long distances,
and transferred from one mode
of transport to another
A standard container that is
loaded with virtually any
goods, and stays sealed until
it reaches final delivery.
Microservices Architecture
Containerization

34. | © Copyright 2015 Hitachi Consulting34
Static website
Web frontend
Background workers
User DB
Analytics DB
Queue
Dev VM QA Server
Single Prod
Server
Onsite
Cluster
Azure
Contributor
laptop
Customer
Servers
Microservices Architecture
Containerization

35. | © Copyright 2015 Hitachi Consulting35
App
A
Hypervisor (Type 2)
Host OS
Server
Guest
OS
Bins/
Libs
App
A’
Guest
OS
Bins/
Libs
App
B
Guest
OS
Bins/
Libs
AppA’
Host OS
Server
Bins/Libs
AppA
Bins/Libs
AppB
AppB’
AppB’
AppB’
VM
Container
Containers are isolated,
but share OS kernel and, where
appropriate, bins/libraries
Guest
OS
Guest
OS
…result is significantly faster deployment, much
less overhead, easier migration, faster restart,
better use/share of resources
Docker Deamon
Microservices Architecture
VMs vs Containers

36. | © Copyright 2015 Hitachi Consulting36
Microservices Architecture
Technology Options for Microservices Deployment
Azure Service Fabric
Azure
Container
Services
Azure Web Hosting Plans
Web
Apps
API
Apps
Logic
Apps
Web
Jobs
Docker Containers .NET Java
Docker
Swarm
Azure
On-prem/ IaaS
(Windows/
Linux)
Azure
On-prem/ IaaS
(Linux)
Azure

37. | © Copyright 2015 Hitachi Consulting37
Application Development
Lifecycle and Continuous Delivery

38. | © Copyright 2015 Hitachi Consulting38
Application Development Lifecycle
Then and now…
Methodology
Process
Patterns
Platform

39. | © Copyright 2015 Hitachi Consulting39
Application Development Lifecycle
Then and now…
Methodology
Process
Patterns
Platform
Waterfall
Gated
Monolithic
Windows

40. | © Copyright 2015 Hitachi Consulting40
Application Development Lifecycle
Then and now…
Methodology
Process
Patterns
Platform
Waterfall Agile
Scrum
N-Tier Layered
Windows / Linux
Gated
Monolithic
Windows

41. | © Copyright 2015 Hitachi Consulting41
Application Development Lifecycle
Then and now…
Methodology
Process
Patterns
Platform
Waterfall Agile Lean Engineering
Continuous Delivery
Microservice Architecture
Cloud
Scrum
N-Tier Layered
Windows / Linux
Gated
Monolithic
Windows

42. | © Copyright 2015 Hitachi Consulting42
DevOps
“The union of people, process, and
products to enable continuous delivery
of value to our end users.”
- Microsoft

43. | © Copyright 2015 Hitachi Consulting43
DevOps
The big picture...

44. | © Copyright 2015 Hitachi Consulting44
Plan
1 Monitor + Learn
ReleaseDevelop + Test
2
Development Production
4
3
DevOps
The Application Lifecyle
Automation of Build, Test, and Deploy

45. | © Copyright 2015 Hitachi Consulting45
It starts with an idea – and a plan
how to turn this idea into reality …
Manage work
(Epics, Features, User Stories)
Develop + Test 1
Project starts
Plan
(People & Sprints)
Track progress
(Tasks & Burndown)
DevOps
Plan

46. | © Copyright 2015 Hitachi Consulting46
Write Code
Unit Testing
2
Build
Version Control
Integration Test
Release
Once the iteration starts, developers
turn great ideas into features …
DevOps
Dev+Test

47. | © Copyright 2015 Hitachi Consulting47
Value
cspkg
DevOps
Continous Integration (CI)

48. | © Copyright 2015 Hitachi Consulting48
Load
Testing
Integration testing
environment
Automated functional
testing environment
3
Pre-production
environment
Staging
environment
Monitor + Learn
When all tests pass, the build is deployed to
testing environments for each stage in the
release process
DevOps
Release

49. | © Copyright 2015 Hitachi Consulting49
Value
DevOps
Continous Deployment (CD)
Infrastructure as Code

50. | © Copyright 2015 Hitachi Consulting50
Learn and understand how users use your app, how it reacts and
quickly fix issues and bugs
Monitor + Learn
4
Monitor
Feedback
Plan the next
iteration
DevOps
Monitor
App Logs, Telemetry, Fault Injection,
Customer Feedback etc.

51. | © Copyright 2015 Hitachi Consulting51
DevOps
with Microsoft

52. | © Copyright 2015 Hitachi Consulting52
DevOps
Tools and Technologies
https://newrelic.com/devops/toolset
https://xebialabs.com/periodic-table-of-devops-tools/

53. | © Copyright 2015 Hitachi Consulting53
The 12-Factore App

54. | © Copyright 2015 Hitachi Consulting54
The 12-Factore App
Guidelines
A Microservices has a single root repository,
does not share code with another apps
(isolation & ownership)
Codebase
All dependencies (libs & runtimes) are explicitly
declared, shipped and deployed with the
microservice
Dependencies
No hard-coded configurations; read from config
store or environment variablesConfig
Treat backing service (database, queue, other
service) as attached resource via configResources
Strictly separate build, release, & run steps
Build, Run,
Release
A Microservice executes as 1+ stateless
process & shares nothing (containerization)
Processes
Export services via port bindingPort Binding
Scale out via having multiple running instance
of the same microserviceConcurrency
A microservice instance can crash/be killed
quickly (and gracefully) & start fast
Disposability
Keep dev, test, stage, and prod environments
similar (containerization)
Dev/Prod
Parity
Log to stdout (dev=console; prod=file &
archived)Logs
Infrastructure and admin tasks as code (scripts)Admin

55. | © Copyright 2015 Hitachi Consulting55
Useful Resources
 Pattern: Microservice Architecture - http://microservices.io/patterns/microservices.html
 Microservices: a definition of this new architectural https://www.martinfowler.com/articles/microservices.html
 The 12-Factor App - https://12factor.net/
 What is Docker ? - https://www.docker.com/what-docker
 DevOps with Microsoft Azure -
https://www.microsoft.com/en-gb/cloud-platform/development-operations
 MVA courses on DevOps - https://mva.microsoft.com/training-topics/devops#!lang=1033
 Why a microservices approach to building applications? -
https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-overview-microservices