introduction to microservices and cloud native application architecture

© 2015 IBM Corporation

Introduction to Microservices and Cloud Native Application Architecture

David Currie, Senior Software Engineer

@dcurrie | [email protected]

Agenda

• What does it mean to be Cloud Native?

• Twelve Factor Apps

• What are Microservices?

• Developing and Deploying Microservices

1

What does it mean to be Cloud Native?

• Clean contract with underlying OS to ensure maximum

portability

• Scale elastically without significant changes to tooling,

architecture or development practices

• Resilient to inevitable failures in the infrastructure and

application

• Instrumented to provide both technical and business insight

• Utilize cloud services e.g. storage, queuing, caching, …

• Rapid and repeatable deployments to maximise agility

• Automated setup to minimize time and cost for new developers

2

Twelve Factor Apps12factor.net

3

Twelve Factors

I. Codebase

II. Dependencies

III. Config

IV. Backing Services

V. Build, release, run

VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs

XII. Admin processes

• One codebase tracked in

revision control, many deploys

• Bluemix: utilize IBM Bluemix

DevOps Services or Cloud

Foundry deployment tools

(Urban Code Deploy, Gradle,

Jenkins, …)

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Explicitly declare and isolate

dependencies

• Typically platform dependent

e.g. npm, bundler or Liberty

feature manager

• Never rely on system-wide

dependencies

• Bluemix: buildpack adds

external dependencies

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Store config in the environment

• Separate config from source

• Avoid ‘config groups’

• Bluemix: applications

parameterized via system

provided and custom

environment variables

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Treat backing services as

attached resources

• Local and remote resources

should be treated identically

• Bluemix: same mechanism for

creating and binding to all

services (including custom user

provided)

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Strictly separate build and run

stages

• Bluemix: output of build and

staging is immutable container

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Execute the app as one or more

stateless processes

• Never rely on sticky sessions

• Bluemix: application instances

are stateless (state held by

services)

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Export services via port binding

• Bluemix: containers expose

HTTP port externalised via

route

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Scale out via the process model

• Individual VMs can only scale

vertically so far

• Stateless nature makes scaling

simple

• Bluemix: cf scale and auto-

scaling service

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Maximize robustness with fast

startup and graceful shutdown

• Application instances are

disposable

• Crash-only design is logical

conclusion

• Bluemix: architecture can

rapidly start and stop instances

but need to ensure the

application can respond

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Keep development, staging, and

production as similar as

possible

• Use the same backing services

in each environment

• Bluemix: use for every

environment

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Treat logs as event streams

• Don’t write to log files

• Bluemix: loggregator provides

event streams for applications;

can be drained to third-party log

management system

Twelve Factors

I. Codebase

II. Dependencies

III. Config



VI. Processes

VII.Port binding

VIII.Concurrency

IX. Disposability

X. Dev/prod parity

XI. Logs


• Run admin/management tasks

as one-off processes

• E.g. database migrations or for

debugging

• Bluemix: push single-shot

applications bound to same

services

What are Microservices?

16

MonolithicApplication

MonolithicApplicationModularity


Scaling


Failing


Failed


Update

MonolithicApplicationRevolution


Develop

MicroservicesApplication

MicroservicesApplicationInteractions

MicroservicesApplication

Scaled

MicroservicesApplicationEvolution

Monolithic versus Microservices

Monolithic Microservice

Architecture Built as a single logical executable (typically

the server-side part of a three tier client-

server-database architecture)

Built as a suite of small services, each running

separately and communicating with lightweight

mechanisms

Modularity Based on language features Based on business capabilities

Agility Changes to the system involve building and

deploying a new version of the entire

application

Changes can be applied to each service

independently

Scaling Entire application scaled horizontally behind

a load-balancer

Each service scaled independently when needed

Implementation Typically written in one language Each service implemented in the language that

best fits the need

Maintainability Large code base intimidating to new

developers

Smaller code base easier to manage

Transaction ACID BASE

30

Microservice Challenges

• Greater operational complexity – more moving parts

• Devs need significant ops skills

• Service interfaces and versioning

• Duplication of effort across service implementations

• Additional complexity of creating a distributed system – network

latency, fault tolerance, serialization, …

• Designing decoupled non-transactional systems is hard

• Avoiding latency overhead of large numbers of small service

invocations

• Locating service instances

• Maintaining availability and consistency with partitioned data

• End-to-end testing

31

Developing and Deploying Microservices

32

Reducing Operational Complexity

• Platform-as-a-Service exists to remove the complexity of

deploying applications – the PaaS provider also handles the

complexity of managing and monitoring the infrastructure

• Cloud Foundry provides a consistent deployment mechanism

regardless of programming language

• Buildpacks ensure that applications are kept up-to-date with

new versions of the runtime and libraries

• Routing and load balancing handled by Cloud Foundry router

• Service dependencies are resolved at deployment time

• Repeatable deployment through IBM DevOps Services or CLI,

Maven/Gradle/Travis/Jenkins plugins (you can even run Jenkins

on Cloud Foundry!)

• Cloud Foundry V3 API to allow multiple processes per app

33

Service Discovery

• Within a Cloud Foundry environment, routes and the CF

router provide all that is needed to locate a service instance

• Cloud Controller manages distribution and availability of

application instances

• Blue-green deployments supported by binding multiple

application versions to the same route

• cf cups (create user provided service) provides a convenient

mechanism to inform one microservice of the route for a

microservice on which it is dependent

• Where instances of a microservice are deployed to multiple

Cloud Foundry environments, consider using a runtime registry

e.g. Eureka or highly-available data store e.g. etcd, consul or

Zookeeper

34

Communication Protocols

• Cloud Foundry currently only supports inbound HTTP

• Web sockets is an option in preference to long polling

• JSON may be the best fit for client facing services but consider

other options such as Apache Thrift or Google Protocol Buffers

where serialization efficiency is important

• Typically start with synchronous protocols and add

asynchronous (e.g. via MQ Light) where needed to support the

interaction style or performance goals

• Parallel invocation of downstream services may be required to

ensure responsiveness is maintained

• Consider using a reactive programming model (e.g. RxJava) or

Java 8’s CompletableFuture

35

Design for Failure

• Any service call could fail where failure could be anything from

an immediate error code to never returning – need to handle

that gracefully

• Emphasis on real-time monitoring of technical and business

metrics

• Application monitoring through Monitoring and Analytics service

or third-party service e.g. New Relic

• Gives insights which might not be uncovered in a monolithic

application

• Implement patterns from ‘Release It!’ e.g. via Netflix Hystrix

• Circuit Breaker – protect from downstream failures

• Bulkhead – limit resources that can be consumed

• Timeout

• Testing for failures: Simian Army

36

Questions?

37

Summary

• What does it mean to be Cloud Native?

• Twelve Factor Apps

• What are Microservices?

• Developing and Deploying Microservices

38

Thank YouYour Feedback is

Important!

Access the InterConnect 2015

Conference CONNECT Attendee

Portal to complete your session

surveys from your smartphone,

laptop or conference kiosk.

Notices and Disclaimers

Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or

transmitted in any form without written permission from IBM.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with

IBM.

Information in these presentations (including information relating to products that have not yet been announced by IBM) has been

reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM

shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY,

EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF

THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT

OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the

agreements under which they are provided.

Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without

notice.

Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are

presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual

performance, cost, savings or other results in other operating environments may vary.

References in this document to IBM products, programs, or services does not imply that IBM intends to make such products,

programs or services available in all countries in which IBM operates or does business.

Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not

necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither

intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.

It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal

counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s

business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or

represent or warrant that its services or products will ensure that the customer is in compliance with any law.

Notices and Disclaimers (con’t)

Information concerning non-IBM products was obtained from the suppliers of those products, their published

announcements or other publicly available sources. IBM has not tested those products in connection with this

publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM

products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to

interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,

INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A

PARTICULAR PURPOSE.

The provision of the information contained herein is not intended to, and does not, grant any right or license under any

IBM patents, copyrights, trademarks or other intellectual property right.

• IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document

Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand,

ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™,

PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®,

pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®,

urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of

International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and

service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on

the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

http://www.ibm.com/legal/copytrade.shtml

introduction to microservices and cloud native application architecture

Software

stages bluemix

ibm bluemix devops services

config groups bluemix

port binding bluemix

sticky sessions bluemix

environment separate

isolate dependencies

external dependencies