webMethods Integrations - Cloud Readiness Assessment

Knowledge base
,
1

  1. Introduction:

  • CIO mandated the Cloud Transformation?
  • Confused about moving towards Public Cloud or Private Cloud?
  • Want to re-use the integrations, frameworks already implemented, validated on webMethods Integration Server?
  • What could be the approach for connecting on-premises and cloud securely? 

This article explains about the items that needs to be considered for Cloud Transformation of webMethods Assets.

  1. Pre-requisites:

If you are newbie on the Cloud space, go through

It is also good to have an understanding of Enterprise Integration Patterns - http://techcommunity.softwareag.com/pwiki/-/wiki/Main/Enterprise%20Integration%20Patterns

  1. Solution Architecture & Integration Patterns:

The first step for moving towards cloud would be understanding the “AS-IS” Solution Architecture and Integration Patterns.

  • Solution Architecture:

Do you already have 4+1 architectural view model available for your Integrations? If not, this is good time start working on these views. Each view would help you to understand and apply the Cloud Transformation strategies - apply the Gartner’s 6 R’s – Retain (Encapsulate), Rehost (lift & Shift), Re-platform (Lift-think-shift), Refactor, Re-Architect (Lift & Reshape) and Rebuild/Replace.

Logical View: This view will provide the functionalities that are offered to business by current implementation. This will give a very good understanding of what functional pieces can be retired, what pieces can be transformed to cloud. It might be not necessary that the existing implementation would have to be transformed AS-IS.

Process & Physical (Deployment) Views: These views would point-out are the systems involved with the implementation and how they are connected and communicated with each other. These views also have an answer for the questions - What should be the mechanism applied to connect all the systems after Cloud Transformation? Do we need to apply the Hybrid Integration mechanism? Would it be multi-cloud Hybrid Integration? How scalable system is and should be in future? What are the business availability requirements (Non-functional)?

Implementation View: This is a programmer’s perspective of how the implementation is managed within the software. Perform an assessment on the webMethods implementation and catalogue the assets. Refer to http://techcommunity.softwareag.com/pwiki/-/wiki/Main/Cloud%20Transformation%20using%20webMethods%20Cloud%20Container for more details.

Scenarios: This view describes the interaction of business objects and their transformation through out the systems with the set of use cases. This is good reference for the Cloud Transformation and Use cases. Sometimes these details are captured in separate Solution Design documents for each use case.

Prepare the TO BE solution architecture and Cloud Transformation strategy based on the assessment. Below diagram represents the high-level solution overview for Multi-cloud Hybrid Integration.

1462×683 164 KB

  • Integration Patterns

Solution Architecture would provide the high-level vision whereas the integration Patterns would provide an overview of the actual implementation of the business scenarios.

File Transfer: Do you have the integrations reading and writing files in your AS IS system?

If yes, then this is something you like to refactor to a Cloud Storage.

webMethods Cloud Container is the public cloud offering that can help to transform the webMethods Integrations to Cloud. webMethods Cloud Container runs the integration server instances as containers on Kubernetes platform. It is not possible to map storage accessible for external systems.

Private Cloud offerings might provide similar file system capabilities and file storage capabilities. But if you would like to move towards Private Cloud, it is highly recommended to take Cloud Native deployment measures. It is not ideal to read/write to files within containers within Cloud Native initiatives.

It is better to refactor the integrations with Cloud Storage for these cases.

Shared Database: Do you have the shared database pattern across different applications? This is the most commonly used patterns for Integration use cases.

The next set of questions related to this would be, can this data store be migration/re-hosted on cloud? Does the existing data also need to be migrated to cloud? What if the database needs to be maintained on the on-premises? What are the possible options?

In all the above cases, there is no need to refactor the implementation for webMethods Integration. There might be changes in drivers but that will not affect the implementation.

Remote Procedure Invocation: In modern era, this is also referred as API Invocation. If you have APIs hosted on your AS IS and are invoked directly, this is some thing you might want to change.

APIs are the center of modern application architecture and you need to Monetize the APIs to understand the consumption pattern. Adopt your Multi-cloud Hybrid Integration strategy as mentioned below. Consider all on-premises hosted APIs are System APIs, orchestrate and create business processes and APIs using the System APIs. Expose the required Experience APIs to external consumers using API Gateway.

1278×611 77 KB

Messaging: This is one of pattern that proved its value over the decades. Thought it does not solve all the use cases, asynchronous pattern has always its advantages for batch processing, parallelizing, throttling, etc. Continue to adopt even driven approaches as much as possible on cloud. This pattern always has been scalable. This pattern has no limitations on both Public cloud and Private Cloud deployments.

Make sure your messaging patterns are adopting the Global standards e.g. JMS, MQTT, AMQP, etc.

B2B Integration:

Plan to migrate Partner Integrations hosted on on-premises to webMethods.io B2B.

  • Public Cloud: webMethods.io B2B can work with webMethods Cloud Container for the cloud Transformation. Existing integrations can be migrated to Cloud Container while the Trading Partner configurations can be migrated to webMethods.io B2B. Below diagram provides a high-level overview of Cloud Transformation for B2B Integration with Trading Networks.

1478×772 92.6 KB

  • Hybrid Cloud: webMethods.io B2B can also work with Private Cloud Deployments. In this case only Trading Partner configurations would be migrated to webMethods.io B2B where as Integration can reside on the Private Cloud.

  1. Other factors

  • Operating System dependencies: Often integrations tend to depend upon OS libraries, kernel nature, etc. Few examples are,
    • implementation using OS PGP libraries for encryption/decryption – Use OpenPGP libraries instead of OS libraries https://github.com/SoftwareAG/WxPGPUtlis
    • Accessing files using OS specific path convention, e.g. “/ for Unix” “\ for Windows”- use System.getProperty("file.separator")
  • LDAP Integration: Do you have LDAP Integration in your existing implementations? Is this imposed for Authentication and Authorization? This might not be a good approach when you move towards either Public Cloud/Private Cloud. Acquire a Cloud hosted Identity Provider -e.g., Azure AD, OKTA, etc. You can integration these using API Gateway OpenID Connect, SAML, JWT OAuth 2.0 mechanisms.
  • Custom Logging Frameworks: Do you have any custom logging mechanisms? If you prefer Private Cloud deployment, adopt the Log Aggregation mechanisms. Modify the Custom logging to console logging for containers. For Public Cloud offerings, consider logging to external data lakes.

  1. Conclusion

So, what should be the Cloud Transformation Strategy? Public Cloud/Private Cloud? Below Matrix might help you to make the decision.

Cloud Hosting / Characteristics

Public Cloud

(webMethods Cloud Container)

Private Cloud

(VMs/Containers)

Infrastructure - Maintenance & Upgrades
  • Managed by Software AG
  • Self-Managed Upgrades (fixes & new versions) – always has the capability to upgrade to latest version in minutes
  • Product fixes made available by Software AG
  • Managed by Customer
  • Upgrades should be managed by Customer
  • Fixes should be planned and managed by Customer

Platform Control
  • Software Patches/Downtimes are controlled and rolled out by Software AG. 
  • Availability and Downtimes are managed by customer

Elasticity
  • Can be scaled up and down as required
  • Can be scaled up and down limited to procured hardware

Security
  • Some common services are shared across other Organizations.
  • Runtime data isolation can be achieved through dedicated VPC for enterprise customers
  • Complete control on the resources to be exposed on shared

Cost
  • Cost effective with transaction-based pricing model
  • Costs are higher for dedicated infrastructure setup

In general, public cloud is preferred for High scalability where private cloud is for preferred for high control and better security of sensitive data. Overall, Multi Cloud strategy is surely winning, with Cloud Native Hosting as the key to success.