Using Microservices to build Megaservices
In this week’s blog, Bernard Foot, Strategy Analyst at MYHSM, the global Payment HSM as a Service provider, gets educated on Microservices and considers how they might benefit the Payment HSM user.
As we use Thales payShields in MYHSM’s Payment HSM as a Service, a recent post about Microservices by the Thales VP of Research and Development caught my eye. Not being a developer, I didn’t know much (or anything, to put it another way) about Microservices. So I thought I’d put myself through a do-it-yourself 101 course, with the internet as my tutor, and think about what this means for Payment HSMs.
What are Microservices?
Microservices are all about architecting an application as a network of (generally) small, independent software components rather than as a software monolith. It’s an approach that fits in well with the modern trends towards the Cloud, containerized software, Agile development, multi-disciplinary teams, and DevOps.
The benefits for the development process include agility; use of small, focussed teams; smaller, easier to manage units of work; ability for teams to work in isolation without impacting other teams; using the best tools to develop each Microservice; and easier testing. For operational systems it is easier to isolate failed components and switch to replacements, and to scale up by having multiple instances of just those Microservices which are the bottleneck rather than of a whole monolith.
So that’s the future, is it?
Well, although the potential benefits are very real, there are plenty of warnings that switching to a Microservices architecture is not a panacea and may not be the solution for everyone. Although the architecture makes it easier to develop components of the application, management of the whole application and its development process becomes more complex. Different skill sets are needed. And the architecture could lead to congested networks and higher latency.
HPE cautions that “These types of architectures are closely associated with DevOps, a philosophy that’s become popular enough to attract trend chasers and cargo cult thinking.”
Most of the existing applications that use Payment HSMs are complex monoliths. We may see some of these become re-architected as Microservices over time, or their replacements developed using a Microservice model. New entrants into the payments space may well adopt this architecture from Day 1. Adoption could be accelerated because organisations are able to go for a hybrid solution, with Microservices being used only for some, appropriate parts of the application. And because Microservices are accessed through an IP address, developers and users could access third-party Microservices on a pay-per-use basis rather than building their own.
What does all this mean for Payment HSMs?
Well, I can’t see it having any direct impact on the HSM. The clue is in the name – it’s a hardware module with embedded software (or firmware) that provides more security than you can achieve with a software-only solution, and so can’t be re-architected as one or more Microservices.
On the other hand, Microservices may well have an impact on how applications access Payment HSMs. A monolithic application has to be written for the HSM’s specific API, has to provide services like load-balancing and failover, and has to handle re-routing for DR.
In the world of Microservices, on the other hand, applications could implement a third-party Microservice provider’s generic API (or better still, an as yet non-existent industry standard API) to a service which will deliver the Payment HSM capability. The user would not know or care what type of HSM was being used or where it was. They could enjoy value added benefits such as: having their work directed to whichever type of HSM offers optimised performance for the specific task (e.g. PIN Block Translation vs. RSA keygen); using HSMs in that data centre which gives them the lowest latency; reduced costs by using under-utilised HSMs in the slack periods of other geographies; and 100% uptime guarantees by having access to HSMs in many, distributed data centres. All this on top of the benefits of not having to buy, manage, and maintain their own HSMs.
How exciting would that be for the user? And it would be great for MYHSM as well, because this would be predicated on the availability of cloud-based Payment HSM as a Service. In fact, we could offer the Microservices.
But probably not this year.