IBM Connect 2016 presentation

1. Delivering Enterprise Software at the
Speed of Cloud
Vincent Burckhardt, Stephen Crawford

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

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

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

5.  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?

6.  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?

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

8.  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

9.  Historical context
– Cloud characteristics
– Importance of continuous feedback loop
 Organization culture
 Software Architecture for Cloud
 Continuous delivery and automation
 Modern UI stack
Agenda

10. Organization culture

11.  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

12. On-premises (2006 - ...)
 Clear separation of development
of application from operations
– Development is IBM
– Deployment and operation
handled by customer
purchasing software from IBM

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

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

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

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

17. Functional decomposing
“Traditional” monolithic app

18. Functional decomposing
“Traditional” monolithic app
Microservices:
small apps running independently

20. DBA
Net
Admin
SAN
admin
Microservice
Coordination
Requirements
Stories
Microservice 1
Product Mgm
+ Front-end
+ back-end
+ QA functional
+ QA performance
+ UX
Stories
Microservice 2
Product Mgm
+ Front-end
+ back-end
+ QA functional
+ QA performance
+ UX
Stories
Microservice 3
Product Mgm
+ Front-end
+ back-end
+ QA functional
+ QA performance
+ UX
Microservice Microservice
Coordination Coordination
Breaking down silos through architecture changes

21. DBA
Net
Admin
SAN
admin
Microservice
Coordination
Requirements
Stories
Microservice 1
Product Mgm
+ Front-end
+ back-end
+ QA functional
+ QA performance
+ UX
Stories
Microservice 2
Product Mgm
+ Front-end
+ back-end
+ QA functional
+ QA performance
+ UX
Stories
Microservice 3
Product Mgm
+ Front-end
+ back-end
+ QA functional
+ QA performance
+ UX
Microservice Microservice
Coordination Coordination
Breaking down silos through architecture changes
Interface

22. DBA
Net
Admin
SAN
admin
Microservice
Coordination
Requirements
Stories
Microservice 1
Front-end
+ back-end
+ QA functional
+ UX
Stories
Microservice 2
Front-end
+ back-end
+ QA functional
+ UX
Stories
Microservice 3
Front-end
+ back-end
+ QA functional
+ UX
Microservice Microservice
Coordination Coordination
“Experts” as a service: Security, performance,
software architect, automation
tooling, UX...
Breaking down silos through architecture changes
Interface

23. DBA
Net
Admin
SAN
admin
Microservice
Coordination
Requirements
Stories
Microservice 1
Front-end
+ back-end
+ QA functional
+ UX
Stories
Microservice 2
Front-end
+ back-end
+ QA functional
+ UX
Stories
Microservice 3
Front-end
+ back-end
+ QA functional
+ UX
Microservice Microservice
Coordination Coordination
“Experts” as a service:
Functional test anchor point, Security, performance
software architect, automation
tooling, UX...
Additional culture changes
Interface
BDD (Behavior Driven Dev)
TDD (Test Driven Dev)
Pair Programming

24. Software architecture for
Cloud

25.  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

26. Example - functional decomposing
“Traditional” monolithic app Microservices based app

27. Example - Different runtime
“Traditional” monolithic app Microservices based app

28. Example – Inside view

29. The 3 axis 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)

30. Common aspects of microservices
Discoverability
Observability
Configuration
Single entry point
(routing,
aggregation,
common API)

31. 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
Enable a “re-org”
Surface code to
production faster
Scalability / resilience
benefits
Fast rollforward

32. Challenges
Eventual consistency
Larger deployment overhead
Larger monitoring overhead
Larger operation
overhead
Async programming
Larger deployment overhead
Larger monitoring overhead
Larger operation
overhead
Extra coding considerations
Cache invalidation
Log analysis
Network latency
Resilience of overall system
Scalability / resilience

33.  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

34. Continuous delivery

35. Releasing faster
Capabilities
Configuration
changes
Fixes
Experiments
Several times
per 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

37. Continuous integration (CI) pipeline
Commit stage Build Unit tests
Acceptance
tests
Continuous integration
Promote
binaries
 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

38. Continuous integration (CI) pipeline
Commit stage Build Unit tests
Acceptance
tests
Continuous integration
Promote
binaries
 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

39. Final mile to production
Production
Bunch of
manual steps
The final mile
Commit stage Build Unit tests
Acceptance
tests
Continuous integration
Promote
binaries
Slow, manual, error-prone,
infrequent and inconsistent
deployments

41. Walking back from production
Production
Commit stage Build Unit tests
Acceptance
tests
Fetch
binaries
Automated
application
deployment
Manual steps
to improve
quality
Continuous integration
Automate deployment of software and its dependencies
Introduce configuration management
Makes deployment repeatable on any environment
Promote
binaries

42. Automated consistent deployment
Rollback support
Dashboard for clear visibility
of 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/

43. Continuous delivery pipeline
Production
Commit stage Build Unit tests
Acceptance
tests
Fetch
binaries
Promote
binaries
Deploy on
test server
(UDeploy)
Capacity
testing
Resilience
testing
Chaotic
testing
Automatic
application
deployment
Manual steps
to improve
quality
Extensive automated system
and performance testing:
how does the app behave
under load

44. Continuous delivery pipeline
Production
Commit stage Build Unit tests
Acceptance
tests
Fetch
binaries
Promote
binaries
Manual
Exploration
testing
Deploy on
test server
(UDeploy)
Capacity
testing
Resilience
testing
Chaotic
testing
Automatic
application
deployment
Human centric testing cannot be
eliminated:
Exploration testing (usability), pen
testing
It can be minimized however

45. Automated delivery pipeline
Commit stage
Unit
and functional
testing
System
testing
Publish
binaries to
central repo
Deploy to
pre-prod
Continuous integration Continuous delivery
Manual
Exploration
testing
Release to
production
Less than 24 hours

46. Isolated functional
testing
Isolated reliability
testing
Integration
testing
Isolated functional
testing
Isolated reliability
testing
Microservice 1
Microservice 2
System
testing
Microservices help keeping pipeline flowing
Less than 24 hours
Manual
Exploration
testing
Release to
production

47. 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/

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

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

50. Modern UI stack

51. Overview
 Where we are
 Understand the gaps
 How we can change!
 Frameworks to support

52. 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
Common
Java Servlet
Aggregation of
CSS/JS Modules
Homepage
Java Struts
Bootstrap HTML
Browser
JS/CSS
J2EE WebSphere
API server

53. 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…..

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

55.  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

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

57. Javascript is everywhere
 Truly universal language
– Desktop
– Mobile Web
– Mobile Native
– Server
– Browser

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

59. Change 2 – Consolidation
 Decouple Presentation layer from J2EE stack and consolidate and share resources, render Single
Page architecture.
NodeJS
Browser
Services (JSON Graph)

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

61. JSON Graph Query API - Falcor

62. JSON Graph Query API – Relay/GraphQL
Plain React Component
GraphQL query to
schema
Results auto bound to
props in React
Component

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

64. Design First - Features
PrototypeDesign
Development
React
Component
Library Feature
Gatekeeper Metrics
NewRelic

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

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

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

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

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

70. Questions ??

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