In a blog on the NuWave Technologies website 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 article is intended to dive into the world of 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 software 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 last part 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.
Amazon, Google, Microsoft, IBM and others all support microservices via their various cloud and API gateway solutions, and many large organizations have built their entire software ecosystem using a microservices-based approach. Netflix, for instance, runs their massive online video streaming operation using microservices, and have gone so far as to build their own orchestration system, called Conductor, which brings it all together (and that they have open-sourced for anyone interested in learning more or perhaps using it). See https://medium.com/netflix-techblog for more details on their microservices implementation.
How does this all apply to typical NonStop environments, where we see large, some would say monolithic, applications being the norm? How do we respond when our enterprise architects come calling to tell us about the new microservices initiatives at play elsewhere in the organization?
NonStop application developers and architects may wish to have their applications participate in a microservices environment in a number of ways, including:
- 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 may be good reasons 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, REST middleware solutions such as LightWave Client can be used to allow your NonStop application to quickly and simply access the currency conversion microservice.
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.
Of course, microservices within your organization could be implemented to provide many other functions, depending on your organization’s needs, and architectural approaches, but chances are there will be capabilities available that could be useful to your NonStop applications.
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. While it might not be necessary to break up the entire application into microservices, as is becoming common on other platforms, it may still be important to make key functions available as microservices. 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.
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. REST middleware solutions like LightWave Server can be 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, or similar solutions, 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.
Be the first to comment