agile and continuous delivery – how ibm watson workspace is built

Vincent Burckhardt

Brendan Arthurs

Agile and Continuous Delivery – How IBM Watson Workspace Is Built

Please note• IBM’s statements regarding its plans, directions, and intent are subject to

change or withdrawal without notice at IBM’s sole discretion.

• Information regarding potential future products is intended to outline our

general product direction and it should not be relied on in making a

purchasing decision.

• The information mentioned regarding potential future products is not a

commitment, promise, or legal obligation to deliver any material, code or

functionality. Information about potential future products may not be

incorporated into any contract.

• The development, release, and timing of any future features or functionality

described for our products remains at our sole discretion.

• Performance is based on measurements and projections using standard IBM

benchmarks in a controlled environment. The actual throughput or

performance that any user will experience will vary depending upon many

factors, including considerations such as the amount of multiprogramming in

the user’s job stream, the I/O configuration, the storage configuration, and the

workload processed. Therefore, no assurance can be given that an individual

user will achieve results similar to those stated here.

2/21/2017

2

An app (“Watson Workspace”): a cross-device team-based collaboration experience to “get work done” Team-based persistent conversations Infused with cognitive insight from

Watson Try it today at workspace.ibm.com!

A platform (named “Watson Work Services”): A collection cognitive collaboration services surfacing rich APIs, that can be used to build new apps, enrich existing application… https://developer.watsonwork.ibm.com

Watson Workspace – The Journey Begins

https://workspace.ibm.com/

https://developer.watsonwork.ibm.com/

More than just IBM Watson Workspace…. Journey and transformation to build Cloud-first software

– Current trends, and best practices around building Cloud-first software

Session for anyone interested to learn about some of the transformations currently ongoing within IBM, social offering … – But also in the industry in general

Technical point of view– Explore more about some or all of what is described

in this session for your own solutions Business perspective

– Transparent about the changes we are currently making

– Influence the way we're delivering capabilities

What is this session about?

Taking existing on-premises applications and deploying them on a Cloud environment– Fastest path to offer applications on the Cloud– Requires only a few updates to software (multi-

tenancy) and processes That approach works perfectly fine! … up to a certain

extent: – Slow and disruptive process to update the software.

Requires a monthly maintenance of several hours downtime to upgrade the application.

– Does not scale linearly with number of users– Further reliability goals are difficult to reach with on-

premises technologies SLA: never enough 9s...

Why did we need to change?

We want an architecture, technology stack and processes allowing us:

1. To scale linearly From millions to hundreds of millions

2. With as little downtime as possible No downtime for upgrades of new versions Resilience: No downtime due to failure of

some of the underlying services

3. To establish a continuous feedback loop with end-users

High level goals on Cloud

Hypothesis

Develop

Test

Deploy

Capture metrics

Insights

Going through the loop as fast as possible is key to innovation:– Ensure building what end-users needs, as

opposed to what we think they need– Reduce risk of changes– Simplify definition of “done” – ie: “used by

end-user in production”

Cloud enables us to tighten the feedback loop– Control development + infrastructure +

deployment + metrics gathering

Delivering at the “Speed of Cloud”

Tighten the

feedback

loop

Hypothesis

Develop

Test

Deploy

Capture metrics

Insights

Historical context– Cloud characteristics– Importance of continuous feedback loop

Organization culture Software Architecture for Cloud Continuous delivery and automation Monitoring and gathering insights

Agenda

Organization culture

Many technology changes on Cloud– Releasing faster requires an organization change as much

as technical changes– Technical changes can help organization to change and evolve

Devops: establishing an organization culture to enable more frequent deployment to production in a reliable and sustainable way

Importance of organization culture changes

Better collaborationbetween all actors involved

in the delivery

Automation of delivery processes

Faster iterations, more frequent deployments

On-premises

Clear separation of development of application from operations– Development is IBM– Deployment and operation

handled by customer purchasing software from IBM

Early Cloud releases (ca 2009)

Apply same “winning” patterns as on-premise: separate development organization from operation organization

Not specific to IBM– Similar organization

documented by other major actors on Cloud (Netflix, Facebook, Amazon, ...)

Main effects:– Similar release cycles as on-

premise: once every few months– Obstacles to accelerate release

cycles to a daily / weekly basis

Conflicting interests within same organization

Development teams Operations

Deployed

Software

Adapt software to user/market demands

by making code changes

to add functionalities

=> Seek frequent changes

Responsible for stability of deployed

software

=> Seek to minimize changes

Front end

dev team

Server

Side

dev team

Product

Mgm

team

DBA

team

QA team

(Functional)

QA team

(Perf.)

UX

team

Net

Admin

SAN

admin

team

Single application

Technical and schedule coordination across multiple large teams

Requirements / stories

The whole organization is siloed – not just dev and ops

Effects of segregated teams on release velocity

Fear of deploying

changes

High cost of deploying

individual change

Large batch of

changes

delivered to production

Higher risks

(that sth goes wrong)

More coordination

needed between

teams

Less frequent

deliveries of

changes

Segregated teams

Functional decomposing

“Traditional” monolithic app

Functional decomposing

“Traditional” monolithic app

Microservices:

small apps running independently

DBANet

Admin

SAN

admin

Coordination Coordination Coordination

Breaking down silos through architecture changes

Storage Microservice

Requirement: An awesome small team collaboration platform

Story: I want to share files

Feature: File Upload

Product Mgm

+ Front-end

+ back-end

+ QA functional

+ QA performance

+ UX

Story: I want to chat…

Feature: Chat Messages

Product Mgm

+ Front-end

+ back-end

+ QA functional

+ QA performance

+ UX

Story: I want to be notified…

Feature: Notifications

Product Mgm

+ Front-end

+ back-end

+ QA functional

+ QA performance

+ UX

Chat Microservice Push Microservice

Cloud-scale architecture

Small, independent, loosely coupled runtime components that work together– Exhibit strict boundaries (through network interface)– Composed together to produce overall solution /

product– Unix philosophy: “do one thing and do it well”– Independent deployment unit

How small?– “Application that fits in your head” James Lewis,

Thoughtworks

Microservices

Example - functional decomposing

“Traditional” monolithic app Microservices based app

Example - Different runtime

“Traditional” monolithic app Microservices based app

Example – Inside view

The 3 axes of scalability

From theartofscalability.com

Y axis – functional

decomposing

Split different things

Z axis – data partitioning

(“sharding”)

Split similar thingsX axis – horizontal

duplication

Cloning app (WAS

clustering)

Common aspects of microservices

Discoverability

Observability

Configuration

Single entry point

(routing, aggregation,

common API)

Advantages ...

Autonomous

teams around microservices

Eliminate long term commitments

to single technology stack

Faster to build

Deploy independently

Small: easier to understand

end to end

Scale independently

Fault isolation

Facilitates “re-org”

Ship features

faster

Scalability / resilience

benefits

Fast rollforward

(Perceived…) Challenges

Eventual consistency

Larger deployment overhead

Larger monitoring overhead

Larger operation

overheadAsync programming

Larger deployment overhead

Larger monitoring overhead

Larger operation

overheadExtra coding considerations

Cache invalidation

Log analysis

Network latency

Resilience of overall system

Scalability / resilience

Essentially similar challenges as for any distributed applications but...– Number of documented design patterns to

tackle those challenges– Frameworks are emerging and getting mature

simplify inherited distributed complexity One example: circuit breaker pattern

– Remote calls can fail for various reasons– Wrap any remote call in “circuit breaker”

object. Detects errors and prevent them from happening constantly

– Circuit breaker “trips” based on threshold of failures (associated with monitoring)

– Netflix Hystrix is an opensource Java implementation of this pattern

(Perceived…) Challenges

Continuous delivery

Capabilities

Configuration

changes

Fixes

Experiments

Several times

per day

Without

regressions

(functional, resilience,

performance)

Using the same

process regardless

of the type of change

Get changes to production quickly, safely and in a sustainable way

Release Faster

Dev Practices Matter

There’s a lot more to development than writing code

• How will I test it?

• What will I do to deploy it?

• How will I monitor its behavior?

• How will it behave under load?

• How will it behave at scale?

• Will it be resilient to unexpected

failure?

32 2/21/2017

Delivery Pipelines

Distinct stages allow granular validation, starting with the smallest possible artifact:

• Pre-Merge gives committers confidence in the code they’re about to merge

• Post-Merge validates one component’s APIs in isolation

• Integration validates full system behavior

• Resilience confirms our ability to withstand sustained load and on-the-fly changes to live environments33

Many microservices mean many repos, and many pipelines

We validate artifacts independently before integrating them with others.

So failures are smaller, faster and better.

34 2/21/2017

Chat gitrepo

Auth gitrepo

Push gitrepo

Chat Pre-Merge

Pipeline

AuthPre-Merge

Pipeline

Push Pre-Merge

Pipeline

Chat Merge Pipeline

Auth Merge Pipeline

Push Merge Pipeline

Integration Pipeline

Resiliency Pipeline

Deployment practices really matter

And not just in production…

All environments are built and deployed using the exact same automation

To ensure every failure matters

35 2/21/2017

Deployment Automation

Dev Sandbox

Integration Environment

Resiliency Environment

Production Environment

Automation Repository

VM

36 2/21/2017

Containers Matter

Container

Chat Service

Java Runtime

OS Libraries

Container

Storage Service

Java Runtime

OS Libraries

Kernel

• Removes configuration drift across deployments

• Improves hardware resource utilization, allowing multiple

components to run side-by-side on the same VMs

• Opens up the wonderful world of container orchestration

Roll out small, roll out often

We roll out changes to a single microservice at a time

37 2/21/2017

Chat ServiceStorage Service

Auth Service Web ClientGroup

ServicePeople Service

Notification Service

Push ServicePush Service

v

Group Service

People Service


IBM Watson Workspace



38 2/21/2017

People Service


Push Service

v

Group Service

People Service





ServicePush Service



39 2/21/2017

Group Service

People Service


Push Service

v

Group Service

People Service




Auth Service Web ClientPush Service



We update as few instances at once as possible

40 2/21/2017

v


Group ServiceGroup

ServiceGroup Service






People Service





41 2/21/2017

v

Group ServiceGroup







People Service






42 2/21/2017

v

Group ServiceGroup







People Service






43 2/21/2017

v

Group ServiceGroup







People Service






We rollback in a matter of seconds if system health degrades

44 2/21/2017

v






People Service



Group ServiceGroup


v

US West Coast


US Central


US East Coast


workspace.ibm.com

v

BETA


PRODUCTION


PRODUCTION


workspace.ibm.com

v

beta.workspace.ibm.com

v

BETA


PRODUCTION


PRODUCTION


workspace.ibm.com

v


Group

Service

Multiple times per day

v

BETA


PRODUCTION


PRODUCTION


workspace.ibm.com

v


Group

Service

24 hours later

Feedback loop

Feature flags

Corner piece of continuous integration:– Developers deliver every day to trunk (no feature

branches)– The code can end up in production in 24 hours with

continuous delivery– Thus, need a mechanism to hide new features being

built from end-users Conditional statement (“flags”) hiding capabilities from

end-user– Developer can enable a feature through

configuration changes–

Pushing further, flags can also be used in production for further technical and user experience testing– Number of tooling, framework available for feature

toggles– http://www.beautifulbuilds.com/feature-toggle-

frameworks-list/

http://www.beautifulbuilds.com/feature-toggle-frameworks-list/

Using feature flags for testing in production

A/B testing– 2 variants of same feature are made available

to 2 groups of users– Measure / get feedback on best variant

Progressive rollout– Make a new feature available progressively

overtime (ie: a week)– Measure performance impact over time

Measuring

Key to understand whether you're heading in the right direction (=delivering a delightful experience to users)

Technical metrics (performance / system)– Usual system centric (uptime, heap,

memory…)– Often forgotten: trace back errors affecting

specific users, including client-side errors End-user usage patterns metrics

– Capture events on most end-user interaction with the product

Transform discrete events into insights through analytics– Distinguish technical obstacle to adoption

from actual user experience issues– Feed into design thinking process as input

Why?

Technical issues? Usability issues?

Out of all user doing action A,

how many users are doing action B?

Fix it!

Adjust priority of

Defect based on

Actual end-user impact

Feed into design thinking:

* Diverge/converge

to generate ideas

* Test ideas through

A/B testing

2/21/2017

5

3

Do we have an issue with space creation on iOS?

In summary…

54 2/21/2017

• Combination of:

– Culture

– Architecture

– Continuous Delivery

• … is critical to scale a continuous feedback loop• … allowing us to innovate faster

Resources

2/21/2017 IBM Connect 2017 55

Tue, 2/21

1256 Design Thinking for App Developers

1249 IBM Watson Workspace and Work Services Strategy and Roadmap

Follow up with 1251, 1255, 1388, 1607 and 1687.

Wed, 2/22

1588 Make it Cognitive — Applying Watson Work Services to Your Own Apps

1598 Watson Work Services: What’s in it for Me?

Follow up with 1065, 1098, 1254, 1304, 1488, 1513, 1579, 1592, 1633 and 1664.

Thu, 2/231560 Designing and Building the Future — How Watson Workspace Innovated Like a Lean Startup

Follow up with 1417, 1420 and 1600.

2/21/2017 IBM Connect 2017 56

To learn more about Watson Workspace and Watson Work Services

Check it out!

Watson Workspace apps in action

• For marketing professionals: https://ibm.biz/wws4mktg

• For sellers: https://ibm.biz/wws4sales

Sample code

• Official: http://github.com/watsonwork

• JavaScript: http://github.com/van-ibm

• Java: https://wiki.openntf.org/display/WWSJava

• Node-RED: https://github.com/fdescollonges/wwsNodes

2/21/2017 IBM Connect 2017 57

Resources

• The Watson Work Services Developer Guide

https://developer.watsonwork.ibm.com

• Watson Workspace

https://workspace.ibm.com

• The Watson Workspace Help Center

https://workspace.ibm.com/help

2/21/2017 IBM Connect 2017 58

2/21/2017 IBM Connect 2017 59

Watson Workspace and Work Services-related sessions

2/21/2017 IBM Connect 2017 60


2/21/2017 IBM Connect 2017 61


Notices and disclaimers • Copyright © 2017 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.

• IBM products are manufactured from new parts or new and used parts. In some cases, a product may not be

new and may have been previously installed. Regardless, our warranty terms apply.”

• 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 law2/21/2017

62

Notices and disclaimers continued

• 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, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ, Tealeaf®, Tivoli®, Trusteer®, Unica®, 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.

2/21/2017

63

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

Thank you

64 2/21/2017