About Me

My photo
Rohit is an investor, startup advisor and an Application Modernization Scale Specialist working at Google.

Tuesday, September 5, 2017

Porting WebSphere Datapower to Pivotal Cloud Foundry


Locked in and married unto death with WebSphere Datapower ? There is a way out where you can emerge stronger. Read on ...

Authors

- [Rohit Kelapure](https://www.linkedin.com/in/rohitkelapure/)
- [Elena Neroslavskaya](https://www.linkedin.com/in/neros/)

Replatforming 

Run DP in PCF with the native Docker support.
_Docker image of DP_
https://hub.docker.com/r/ibmcom/datapower/
https://developer.ibm.com/datapower/2016/11/09/using-datapower-for-docker-in-ibm-container-service/

OR

Modernization 

  • Scenario 1: XML Processing with XSLTs at wire speed. Incrementally migrate XSLT flows from DataPower to Spring Boot microservices leveraging java streaming XSLT 2.0/3.0 processors like [SAXON](http://www.saxonica.com/welcome/welcome.xml) and [Altova]. The Spring 5 and Spring boot 2 reactive support will allow us to process all logic reactively in a non-blocking fashion from end-user to server. If the XSLT transformations involve business logic then migrate those business rules to a Rules engine like DROOLs or orchestrate the data rules microservices logic with SpringCloudDataFlow.
  • Scenario 2: Authentication and Authorization, SSL Offload, Security vectors - HTTP threat protection: This is modernized and replaced via a combination of federated authn/authz + Web firewall and networking edge devices with NSX-T or NSX-V.
  • Scenario 3: mini-ESB Protocol Transformation and Governance: Use Spring Integration or Camel light weight implementation of EAI patterns to transform data.
  • Scenario 4: Caching: Leverage Redis or Pivotal Gemfire or Pivotal Cloud Cache to cache data alongside the app and not in the DMZ.
  • Scenario 5: Data Integration- Connectors to Mainframes and other EAI systems: Leverage zOS Connect 2.0 web service support on the mainframe to expose REST APIs for your zOS backend sub-systems like IMS, CICS, DB2, ... or use Java connectors to IMS and CICS. Implement data microservices that consume these APIs and/or use the connectors.
  • Scenario 6: API Gateway: Replace with a custom route service with a software layer 7 service aware router and load balancer like Netflix Zuul or leverage an integrated solution like [Apigee](https://apigee.com/about/blog/developer/edge-microgateway-pivotal-cloud-foundry-technical-updates) or [Istio](https://content.pivotal.io/blog/pivotal-and-istio-advancing-the-ecosystem-for-microservices-in-the-enterprise)

Recommendation:

We recommend following the path of modernization instead of replatforming since dockerizing DP will not yield the full benefits of a cloud native architecture. Modernizing instead of replatforming over the long term will end the dependence on DP and  and replace with more scalable and widely available software and people and process. 

WHY

  1. Running Docker images will give you IaaS efficiencies dropping OPEX cost
  2. Separation of responsibilities. Smaller teams can implement and own individual service capabilities without having a central god governance and transformation point. Choreography instead of orchestration. Smart endpoints, dumb pipes.
  3. Developer productivity with Java non XML code is high.
  4. Setting up a CI pipeline and integrating other DEVOPS tools is easier with microservices.
  5. Debugging is easier in java code than XSLT transforms
  6. Ramp up of developers and provisioning of environments becomes a lot easier.
  7. If Datapower is not being used for data transformation, connectors to backend systems, caching or Authenication and authorization then strangling the XSLT transforms can be done in a phased systematic fashion since the true value  of DP is not being leveraged.