ti 1641 - delivering enterprise software at the speed of cloud

Delivering Enterprise Software at the Speed of CloudVincent Burckhardt, Stephen Crawford

Notices and DisclaimersCopyright © 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 cont.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.

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

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.

• 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.

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 (multitenancy) 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 do we need to change?

We want an architecture, technology stack and processes that allow us:

– To scale lineraly

From several millions to several hundreds millions

– 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

– 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”: released to 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

Modern UI stack

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 collaboration between all actors involved

in the delivery

Automation of delivery processes

Faster iterations, more frequent deployments

On-premises (2006 - ...)

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 2010 - ...)

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

DeployedSoftware

Adapt software to user/market demandsby making code changes

to add functionalities=> Seek frequent changes

Responsible for stability of deployedsoftware

=> Seek to minimize changes

Front enddev team

ServerSide

dev team

ProductMgmteam

DBAteam

QA team(Functional)

QA team(Perf.)

UXteam

NetAdmin

SAN adminteam

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 deployingindividual change

Large batch of changes

delivered to production

Higher risks(that sth goes wrong)

More coordinationneeded 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

AdminSAN admin

Microservice

Coordination

Requirements

Stories

Microservice 1

Product Mgm + Front-end + back-end

+ QA functional + QA performance

+ UX

Stories

Microservice 2



+ UX

Stories

Microservice 3



+ UX

Microservice Microservice

Coordination Coordination

Breaking down silos through architecture changes

DBANet

AdminSAN admin

Microservice

Coordination

Requirements

Stories

Microservice 1



+ UX

Stories

Microservice 2



+ UX

Stories

Microservice 3



+ UX




Interface

DBANet

AdminSAN admin

Microservice

Coordination

Requirements

Stories

Microservice 1

Front-end + back-end

+ QA functional + UX

Stories

Microservice 2



Stories

Microservice 3





“Experts” as a service: Security, performance,software architect, automation

tooling, UX...


Interface

DBANet

AdminSAN admin

Microservice

Coordination

Requirements

Stories

Microservice 1



Stories

Microservice 2



Stories

Microservice 3





“Experts” as a service: Functional test anchor point, Security, performance

software architect, automationtooling, UX...

Additional culture changes

Interface

BDD (Behavior Driven Dev)

TDD (Test Driven Dev)

Pair Programming

Software architecture for Cloud

Increasing architecture trend in the industry

– Netflix, Amazon.com, Facebook

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 axis of scalability

From theartofscalability.com

Y axis – functional decomposingSplit different things

Z axis – data partitioning(“sharding”)Split similar thingsX axis – horizontal

duplicationCloning 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 commitmentsto single technology stack

Faster to build

Deploy independently

Small: easier to understandend to end

Scale independently

Fault isolation

Enable a “re-org”

Surface code toproduction faster

Scalability / resiliencebenefits

Fast rollforward

Challenges

Eventual consistency

Larger deployment overhead

Larger monitoring overhead

Larger operationoverhead

Async programmingLarger deployment overhead

Larger monitoring overhead

Larger operationoverhead

Extra coding considerations

Cache invalidationLog 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

Challenges

Continuous delivery

Releasing faster

Capabilities

Configurationchanges

Fixes

Experiments

Several timesper day

Without any

Regressions (functional, resilience,

performance)

Consistently: with similar processes regardless

of the type of change

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

Continuous integration (CI) pipeline

Commit stage Build Unit testsAcceptance

tests

Continuous integration

Promotebinaries

CI aims at preventing integration problems between code deliveries from multiple developers

Everybody delivers to the same branch “trunk” on a daily basis

To avoid quality issues, quality checks are automatically run for every delivery in a pipeline

Continuous integration (CI) pipeline


tests


Promotebinaries

Many tools to support CI implementation appeared over the years

Feedback: “Stop the line” approach. Problems with a code delivery are surfaced immediately to the team and should be fixed as top priority

Increase visibility of the build, test processes

Final mile to production

Production

Bunch ofmanual steps

The final mile


tests


Promotebinaries

Slow, manual, error-prone, infrequent and inconsistent deployments

Walking back from production

Production


tests

Fetch binaries

Automated applicationdeployment

Manual stepsto improve

quality


Automate deployment of software and its dependenciesIntroduce configuration managementMakes deployment repeatable on any environment

Promotebinaries

Automated consistent deployment

Rollback support

Dashboard for clear visibilityof what is deployed where Integrated with middleware,

provisioning and service virtualization

Orchestration of changes across servers

Try it out: https://developer.ibm.com/urbancode/products/urbancode-deploy/

Continuous delivery pipeline

Production


tests

Fetch binaries

Promotebinaries

Deploy ontest server(UDeploy)

Capacitytesting

Resiliencetesting

Chaotictesting

Automatic applicationdeployment

Manual stepsto improve

quality

Extensive automated system and performance testing: how does the app behave

under load

Continuous delivery pipeline

Production


tests

Fetch binaries

Promotebinaries

ManualExploration

testing

Deploy ontest server(UDeploy)

Capacitytesting

Resiliencetesting

Chaotictesting

Automatic applicationdeployment

Human centric testing cannot be eliminated:Exploration testing (usability), pen testing It can be minimized however

Automated delivery pipeline

Commit stageUnit

and functionaltesting

Systemtesting

Publishbinaries to

central repo

Deploy to pre-prod

Continuous integration Continuous delivery

ManualExploration

testing

Release toproduction

Less than 24 hours

Isolated functionaltesting

Isolated reliabilitytesting

Integration testing

Isolated functionaltesting

Isolated reliabilitytesting

Microservice 1

Microservice 2

System testing

Microservices help keeping pipeline flowing

Less than 24 hours

ManualExploration

testing

Release toproduction

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/

Using feature flags for testing in production Canary testing – beta testing in production

– Make a feature available to a subset of users

– Monitor errors / issues, track discovered bugs

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

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

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

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 ofDefect based on

Actual end-user impact

Feed into design thinking:* Diverge/converge to generate ideas

* Test ideas through A/B testing

Modern UI stack

Overview

Where we are Understand the gaps How we can change! Frameworks to support

Where we are - Presentation Layer Current Scenario, J2EE application layer produces JS bundles and bootstraps UI with Java/Struts

Below shows the topology of a Connections Screen rendering for one Application - Homepage

CommonJava Servlet

Aggregation ofCSS/JS Modules

HomepageJava Struts

Bootstrap HTML

BrowserJS/CSS

J2EE WebSphere

API server

Understand the gaps – pain points Large deployment topology

Less optimal developer experience

UI frameworks evolved at different speeds between applications – lack of consistency

UI tightly bound to API/Backend layer

Slower feedback from customers

Fear of change!

All the above leaves us feeling like this…..

Change 1 – Get closer to our runtime The Web Browser is our runtime OS, JavaScript is its language, lets make it a first class part of our

deployment

Run the presentation server layer on NodeJS, which itself is a lightweight JavaScript runtime.

– Low footprint, can scale horizontally easily.

– Speed up feature development and prototyping by using first class tooling. Automate build and run in JavaScript

– Reduce context switching between Java and JavaScript

– Shared JavaScript context between browser and server. Isomorphic applications

Strongloop

StrongLoop is an IBM company which provides enterprise grade management of NodeJS servers via Process Manager

– Supports automated deployment services for NodeJS inc containers

– Remote management of servers (inc aggregated logging, cluster management – auto horizontal scaling)

– Integrated monitoring and profiling.

Javascript is everywhere

Truly universal language

– Desktop

– Mobile Web

– Mobile Native

– Server

– Browser

Isomorphic (Universal) JS Share the same JavaScript on NodeJS server and Browser

– Render visible elements on the server and send to client, major performance boost on 'time to first load'

– Client takes over and bootstraps current state. Achievable with React and Flux architecture

Client

Browser

Server

NodeJS

Universal JS

API

Change 2 – Consolidation Decouple Presentation layer from J2EE stack and consolidate and share resources, render Single

Page architecture.

NodeJS

Browser

Services (JSON Graph)

JSON Graph Query Libraries There has been an emerging trend in Graph Query languages two notable

ones are

– Netflix with Falcor. https://github.com/Netflix/falcor

– Facebook with Relay/GraphQL. https://facebook.github.io/relay/

Both define a JSON Schema language that can combine multiple data sources

Provide a JS library to declare data fetching requirements

Benefits to developers and 3rd parties

– Single interface to many data sources, meaning client code only has to program to one interface

– Network is hidden – simply declare your dependencies where needed and let the framework fetch resources. Including handling de-duplication efficiently.

– Fetch only the API payload you really need by declaring your dependencies.

– Allows API to be updated independently from the client code.

JSON Graph Query API - Falcor

https://facebook.github.io/relay/

JSON Graph Query API – Relay/GraphQLPlain React Component

GraphQL query to schema

Results auto bound to props in React Component

Change 3 – Deploy fast and Fail fast Decoupled Presentation layer is deployed independently and frequently

Rapid prototyping is supported to get design feedback

A/B testing and metrics used to get closer to the customer and help us ensure successful outcome.

Design First - Features

PrototypeDesign

Development

ReactComponent

Library Feature

Gatekeeper MetricsNewRelic

Change 4 - Eliminate risk of change Automation is vital to Cloud first delivery

– Build with NodeJS and Gulp

– Deployment via Containers

– Jenkins pipeline from developer to production

Automated testing is central to everything and is pervasive

– Selenium based Webdriver tests (DVT, BVT, FVT)

– Jasmine unit testing with Karma runner.

– Rational Performance Test for AVT accessibility compliance scans

– Security and Ethical hacking

A/B testing

– All features are progressively disclosed via gatekeeper process

– All code is infused with metrics (New Relic) to relate back real-time analysis of features

Presentation layer – Tools and Frameworks

React – Web components Flux/Redux – State management architecture SASS – CSS library NodeJS / StrongLoop – deployment Gulp/Webpack – JS Build automation Multi-Channel – Responsive Web development Graph Query Language – Falcor/Relay GraphQL

React and Flux React is a modern web component library created by Facebook

Flux is an architecture which dictates uni-directional flow of state in the application from back to front. Update entire dom anytime the state changes. This sounds expensive…. How is this managed? React virtual Dom!

React eco-system is flourishing in OSS

Learn more - https://facebook.github.io/react/index.html

Responsive Web Design – Multi Channel All Web-UI should adhere to Responsive Web Design principals and support multiple channels

through usage of

– SASS and media queries (device detection)

– Fluid grids

– CSS3 Flexbox

Main takeaways

Shortening the feedback loop requires a organization culture change (re-org)

Deep architecture change with microservices can help push the re-org

Microservices also helps with:

– Scalability

– Resilience

– Continuous delivery

Microservices are for “tall-enough” applications

– To justify the extra cost of distributed application development and deployment

Number of emerging modern UI framework and tooling

– Performing UI stack

– Enable truly automated continuous delivery of front-end elements

Questions ??

Your Feedback Is Important!Based upon your session attendance, a customized list of surveys will be built for you.

Please complete your surveys via the conference kiosks or any web enabled device at https://www.connectsurveys.com or through IBM Event Connect.

ti 1641 - delivering enterprise software at the speed of cloud

Presentations & Public Speaking