xebialabs - optimizing app deployment to ibm websphere

Optimizing  App  Deployment  to  IBM  WebSphere  

Andrew Phillips, VP Products 13 Nov 2014

2 Copyright  2014.  

Housekeeping  

▪ TODO

3 Copyright  2014.  

About  Me  

▪ VP Products for XebiaLabs

▪ Lots of enterprise software development on high-performance systems

▪ Been on both sides of the “Dev…Ops” fence

▪ Active open source contributor and committer

▪ Regular meetup, conference etc. presenter

4 Copyright  2014.  

About  XebiaLabs  

▪ Leading provider of delivery automation software focused on helping companies deliver higher quality software faster.

▪ Reduce development applications costs

▪ Accelerate application time to market

▪ Bridge the gap between Development and Operations

Global  Customers,  Global  Success  

and  more…  

5 Copyright  2014.  

Agenda  

▪ Context: DevOps, CD and more…

▪ WebSphere App Deployment Challenges

▪ The Bigger Picture

▪ Getting Started

▪ Q & A

6 Copyright  2014.  

Context:  DevOps,  CD  and  more  

▪ Organizations need to dramatically accelerate the pace delivery of new features

▪ Agile, DevOps and Continuous Delivery as key initiatives

▪ New architectural paradigms (microservices) and runtime environments (containers, PaaS) coming too

7 Copyright  2014.  

Context:  DevOps,  CD  and  more  

▪ Getting releases to production is faster involves much more than just app deployment, of course…

▪ …but it’s one of the tasks that needs to be carried out much more frequently

▪ Delivery pipelines also require on-demand environments, so relying on “the test environment configured at the dawn of time” is out

8 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

1.  Defining your deployment package

2.  Limiting access for self-service

3.  Managing configuration

4.  Promoting to downstream environments

5.  Configuration drift

9 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

Defining your deployment package

▪  Ensure you have a complete deliverable…

▪  …not “code here and config in an email/support ticket/spreadsheet”

▪  How to specify configuration in an environment-independent way?

▪  How to specify configuration without asking developers to include scripts or code in the deployment package?

▪  How to control which attributes are available to developers, and which values are permitted, without manual review?

10 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

11 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

12 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

Limiting access for self-service

▪  WebSphere admins shouldn’t be spending time clicking through app deployments to Test and QA environments!

▪  Giving developers access to WebSphere directly usually results in “interesting” configurations

▪  How to allow developers to deploy without giving them WebSphere credentials and access to the machines on which WebSphere is running (e.g. for config files)?

▪  How to limit access to certain parts of WebSphere, e.g. allow only server- or cluster-scoped datasources?

13 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

14 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

15 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

16 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

Managing configuration

▪  How to ensure the app has been approved for promotion?

▪  Same code and config, different settings

▪  Environments may have different sizings, different versions or even different runtimes (e.g. SA vs. ND)

▪  May require different deployment strategies −  E.g. rolling hot deployments vs. “standard” deployment with downtime

▪  Need to be able to abstract targeting information and orchestration logic from the deployment package!

17 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

18 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

Promoting to downstream environments:

▪  How to ensure the app has been approved for promotion?

▪  Same code and config, different settings

▪  Environments may have different sizings, different versions or even different runtimes (e.g. SA vs. ND)

▪  May require different deployment strategies −  E.g. rolling hot deployments vs. “standard” deployment with downtime

▪  Need to be able to abstract targeting information and orchestration logic from the deployment package!

19 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

20 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

Configuration Drift:

▪  How often have you heard: “But it works in the Test environment”?

▪  Configuration drift across environments is one of the most common causes of failed deployments

▪  Automated config management can help get rid of this problem…

▪  …but until that is done across the board “config diffs” are incredibly useful

21 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

Configuration Drift:

▪  Challenge: how to look at only “the relevant bit” of the configuration?

▪  Discovering everything takes too long and produces far too much data to usefully work with

▪  How to identify “expected” vs. “unexpected” differences?

▪  What to do once you discover an unexpected difference?

22 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

23 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

24 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

25 Copyright  2014.  

WebSphere  App  Deployment  Challenges  

26 Copyright  2014.  

▪  WAS is not the only target for many applications

▪  Think database changes, config files on the file system, MQ resources etc. etc.

▪  Define them as part of the same deployment package…

▪  …or (if shared) as part of a dependent package

▪  Handle these as part of the same “automated transaction”

▪  And handle all “the usual” automation requirements: rollback, audit trail, reporting, integrations etc. etc.

The  Bigger  Picture  

27 Copyright  2014.  

▪  Many organizations are looking at automated environment provisioning and new runtime platforms

▪  “If I spin up a new WAS installation using PureSystems, can I deploy to it straight away?” −  i.e. is it “known” to my automation tooling?

▪  “If I want to try out Liberty Profile/BlueMix/Docker/your-favourite-runtime-here today, how big is the tooling overhead?” −  “trying out” doesn’t just mean doing the Hello World example, it means

seeing how easy it is to use as part of your delivery stream

▪  “Can I deploy to different runtimes as part of the same app pipeline transparently?”

The  Bigger  Picture  

28 Copyright  2014.  

▪  “We have all these apps and config spreadsheets? Where do we start?”

▪  Building your deployment packages doesn’t have to be a “boil the ocean” approach

▪  Start with the most common elements first −  Obviously, the app code −  Usually things like queues and datasources

Getting  Started  

29 Copyright  2014.  

Getting  Started  

30 Copyright  2014.  

▪  Tooling that can “reverse engineer” packages will accelerate the process

▪  Not magic: need to pick the correct elements to include in the package (e.g. no shared config) and need to tokenize environment-dependent values

▪  Should be used as a one-off “kickstarter” rather than the standard procedure for package delivery!

Getting  Started  

31 Copyright  2014.  

Getting  Started  

32 Copyright  2014.  

Getting  Started  

33 Copyright  2014.  

Getting  Started  

34 Copyright  2014.  

Key  Takeaways  

1.  Define environment-independent packages with code and app config

2.  Version and automate your shared config 3.  Allow for self-service deployment without full

access to WAS 4.  Include code and config beyond WAS 5.  Start with the most common config types first

35 Copyright  2014.  

Next  Steps  

▪ Download XL Deploy: xebialabs.com/download/xl-deploy

▪ Learn more about XebiaLabs & WebSphere: xebialabs.com/products/xl-deploy xebialabs.com/resources/whitepapers

▪ Stay informed:

blog.xebialabs.com

@XebiaLabs

youtube.com/xebialabs

Thank    You!