Many internet-facing companies, including Amazon and Netflix, make extensive use of microservices--it’s said that Amazon uses over 100 microservices to display a product page, and Netflix has over 600 microservices managing their backend. When this many microservices are in use, an aggregation layer, or API gateway, is essential. But what about in the NonStop world, where we often see more monolithic applications than microservices? Why would we consider working with an API gateway?
There are many reasons why NonStop applications may need to “play nice” with an API gateway. Many NonStop installations have API gateways set up within the enterprise, and these gateways will have a list or directory of all supported enterprise services. Developers are able to use those services as they build their applications, knowing that they are secure, and are pre-authorized for usage within that enterprise environment. API gateways can provide many benefits in these “microservice” environments, including:
- Insulating clients from how the application is partitioned into microservices
- Insulating clients from the problem of determining the locations of service instances
- Providing the optimal API for each client
- Reducing the number of requests/round-trips. For example, the API gateway enables clients to retrieve data from multiple services with a single round-trip
- Simplifying the client by moving logic for calling multiple services from the client to the API gateway
- Translating from an external API protocol to whatever protocols are used internally
As NonStop developers within these environments, we may want to work with our enterprise API gateway in at least two different ways:
- Our NonStop applications may wish to make use of one or more services provided by the gateway. This could allow us to rapidly bring new functionality into our NonStop applications, in a manner that is approved by our enterprise security administrators. In that case, our application would be a client to the API gateway.
- We may wish to make one or more of our NonStop transactions available to enterprise users via the API gateway. We may even want to break up our existing NonStop transactions into microservices. In that case, our NonStop applications need to be service end points for the gateway. A twist on this use case would be where an organization uses an API gateway to insulate the NonStop applications from the external internet. Users and/or applications would connect to the API gateway, and the gateway would allow authorized users to access the services available on the NonStop.
In either use-case, we need to figure out the best way of communicating with the gateway. In most cases, this will need to be a modern protocol, as most API gateways predominantly handle modern, web-based protocols. Representational State Transfer, or REST, will almost always be supported by API gateways, and may be the best way for NonStop applications to interact with them. If this REST-based approach is chosen, then the NonStop applications need to be REST-enabled. NuWave LightWave ServerTM and LightWave ClientTM are the quickest and easiest way to REST-enable NonStop applications.
In the first use-case above, LightWave ClientTM would be installed to allow NonStop applications to easily to get to the API gateway, and the services that it provides. The NonStop application would send a simple inter-process message (IPM) to LightWave ClientTM, which would transform that IPM into a REST request that conforms to the API gateway’s requirements. The gateway would do whatever was required to process that request, including any external service invocation, aggregation, etc, and return the reply to the NonStop. LightWave ClientTM would receive the REST-based reply and transform it into an IPM to be returned back to the calling application.
This approach might be used, for instance, in an environment where the NonStop application needed up-to-date currency conversion information. If the API gateway supported a currency conversion service (where the service was fulfilled either internally or externally), the NonStop application could receive currency information via a simple, LightWave ClientTM-based call to the API gateway. The same approach could be used for any service that the gateway supports.
In the second use-case above, LightWave ServerTM would be used to allow the API gateway to request services from the NonStop using REST. These services could be existing transactions, or newly “broken up” microservices. In either case, LightWave ServerTM would receive the REST request from the API gateway, then would transform that request into an IPM that the NonStop application was expecting to receive. The application would process the request, and return the response back to LightWave ServerTM, which would be transform it into a REST response to be sent back to the gateway.
This approach might be used where the API gateway needed to access transactions available on the NonStop, for instance, a PIN change, or a balance inquiry. Clients of the API gateway could access those services easily and quickly, and the gateway could request the service of the NonStop application via a LightWave ServerTM-based REST request. Over time the application may be enhanced to break out additional microservices from the monolithic application, and make those microservices available through the API gateway.
API gateways serve an important purpose in modern microservice environments, but for traditional NonStop applications and use cases, they can be be extremely useful, too. NuWave LightWave solutions allow for a simple move to API gateways, with the potential for a gradual migration to microservices as business needs arise. Contact NuWave at email@example.com if you would like to hear more about LightWave products and API gateways, and comment below to tell us about how you're using API gateways in your enterprise.