NonStop Applications and Microservices

Posted by Andrew Price on Mon, Jul 29, 2019

In a blog last year, titled NonStop Applications and API Gateways -What's the Big Deal? we looked at API Gateways, and how NonStop applications can benefit from working with them.  Microservices are an important aspect of working with API Gateways, and while that article touched on microservices, it didn’t get into details. 

This blog is intended to introduce the reader to microservices - what they are, why they can be a good thing, and their relevance to NonStop applications and NonStop developers.

Microservices are an architectural approach to application development - in a microservice environment the application is built as a collection of small services.  Each service has a unique and well-defined role, and normally communicates via HTTP REST APIs. Microservices can be independently deployed, upgraded, scaled and restarted, without affecting other services in the ecosystem.  Hang on, that sounds a lot like NonStop TS/MP (Pathway to most of us) doesn’t it?

Microservices are often controlled by a centralized orchestration system, controlling how the services are put together to create the larger application and its capabilities.

The major benefit to microservices is that they can save developers from reinventing the wheel - the microservice is built once, and reused as needed.  With small teams working on each service, they can also allow for parallelized development, often speeding up development timeframes significantly.

Of course, as with most new technologies, these benefits don’t come without risks, or possible downsides.  Moving away from monolithic applications can result in a fragmented solution, where developers spend all their time figuring out how to get microservices to play nicely together.  Internal standards needs to be developed to ensure everyone keeps speaking the same language.

How does this all apply to typical NonStop environments?  Well, NonStop applications may wish to participate in a microservices environment in (at least) two ways:

  • NonStop application as microservice consumer
  • NonStop application as microservice provider

Let’s look at each of these scenarios in more details.

 

NonStop as Microservice Consumer

If your NonStop, and its applications, reside in an enterprise that is moving towards microservices, there is a good chance that you may need to incorporate the capabilities of one or more of these services into your NonStop application.  As an example, consider a finance company located in the US that starts doing cross-border business with Canada. That organisation may setup a microservice on a platform outside the NonStop that simply converts US dollars (USD) to Canadian dollars (CAD) at today’s exchange rate.  Now any application within the enterprise that is processing cross-border transactions needs to call this microservice if a USD-CAD conversion is required. As mentioned earlier, microservices are typically provided as HTTP (REST) APIs, so if the NonStop application needs a currency conversion as part of its transaction services, it will need to invoke the microservice as a REST Client.

In this scenario, LightWave Client can be used to allow your NonStop application to quickly and simply access the currency conversion microservice.

Lighwave_Client_Diagram 091616

As can be seen in this diagram, the NonStop application simply sends a formatted Inter Process Message (IPM) to LightWave Client, which builds and sends a REST-based microservice request to the microservice provider to convert the USD amount.  The converted amount is calculated by the microservice provider and returned to LightWave Client, which sends that back to the requesting application via IPM. The requesting application would then incorporate the converted CAD amount into the rest of its transaction processing.

 

NonStop as Microservice Provider

If your enterprise is moving towards a microservices architecture, chances are some of the transactional capabilities of your NonStop application might need to be deployed as microservices.  Indeed, this might be desirable, to ensure that your NonStop remains relevant. Perhaps a typical payment transaction (such as an account transfer) needs to be made available as a microservice, to allow other applications within the enterprise to access that capability.  Or maybe it’s a smaller component of the transaction, such as a PIN verify, that needs to be accessed. In either case, these transactions, or part-transactions, need to be accessible a microservices from elsewhere in the enterprise, meaning your NonStop needs to become a microservice provider.

 

image-7

 

In the diagram above, we have an API gateway (such as Mulesoft or Datapower) accessing the NonStop, and our NonStop application is exposing a transactional component like a PIN verify as a REST service.  LightWave Server is configured to support the PIN verify transaction as an IPM, and to provide that transaction as a REST service. The API gateway sends a REST request up to the NonStop, where LightWave Server receives the request and converts it into the PIN verify IPM request and sends that into the NonStop application.  Note that this IPM will be of a format already supported by the backend application, hence it will need no changes. The NonStop application checks the PIN, and returns a response back to LightWave Server, which formats that response and sends it back to the API gateway as a REST response. In this way we have made the PIN verify transaction available as a microservice, where it can be accessed by any part of the enterprise that is authorized to do so, via the API gateway.  Of course, this same architecture would work without the API gateway involved, where enterprise REST clients would directly access the new microservice, however API gateways are typically going to be involved, to assist with service aggregation and coordination.

Microservices can be an excellent way to ensure that your NonStop applications continue to be used, and remain relevant, as your enterprise evolves.  There are many valuable aspects to your NonStop applications, and these should ideally be made available in whatever form your enterprise architects require.  If there is a move to microservices in your organization, consider which of your existing transactions, or even parts of transactions, might make sense as microservices, and perhaps approach your enterprise architects to discuss with them - they may be surprised at what they can access and use from the NonStop, and how easy it is.  Talk to us at NuWave if you would like any help in this process, or would like to see how quickly your NonStop applications can be enhanced to work with/as microservices.

Topics: NuWave, HPE NonStop, HPE NonStop Middleware