We’re at interesting time in the development of B/OSS for CSPs. Just recently, the TM Forum released a whitepaper on Open Digital Architecture (ODA), which will be the blueprint for the industry to develop architectures that will capture revenue from future digital services. It’s great, not only because Hansen has been involved in the effort from the start, but because the industry is thinking deeply about architecture in a collaborative way, something which it did not do 25 years ago.
And that’s how I think about microservices – something that requires deep thought and pragmatic consideration before jumping on the bandwagon. We’ve seen many things that have been hyped and hailed as saviours for the industry over the years because many people didn’t truly understand what they were. Similarly, there’s a danger that’s happened to microservices.
In effect, microservices are the next iteration of service-oriented architectures (SOA), which in turn grew out of the development of application programming interface (APIs), which stemmed from the use of enterprise service bus (ESB) for integration and so on.
Microservices architecture allows software to be decomposed and containerised, the result being that a large application can be written as a series of modules. As each module is written to support a specific task using a well-defined interface to communicate to other modules, there is an opportunity to re-use some modules for other services in a portfolio, which can standardise and speed up new product development. In short, microservices enables you to scale, are easier to use for new business models, and provide developers the choice of frameworks for developing applications and its business functionality.
When applying a microservices approach to legacy B/OSS, you can see that it’s a very good idea – let old legacy billing, mediation, and CRM systems remain where they are and overlay them with applications that expose services at a granular level so that other systems – legacy or otherwise – can readily use their capability. The benefit to CSPs: data will be managed and processed more efficiently, and you’ll get more out of your legacy investment while avoiding costly change requests for new functionality of old systems.
For its part, Hansen has always had a service-oriented and agile overlay approach at the core of its vision for B/OSS architecture. (And good news: this concept is part of the ODA). Our solutions, having been architected using a microservices approach, currently offer small modules of services to other Hansen products and other non-Hansen constituent applications. So, when it comes to microservices, we say, “bring it on” and we’d advise any CSP that they should make sure all systems implemented from now on have a microservices approach.
However, choosing to pursue microservices has its risks as well as potential benefits – what’s needed is a common-sense approach. In our view, not all applications need to be broken down into small services. It takes time, effort and resources to pursue a microservices framework so one should consider the likelihood of a CSP business actually needing and gaining benefit from smaller service capabilities of a given application to be exposed. Having done this for Hansen Catalog, our advice is to think deeply about whether an application will need to expose their capabilities.
Microservices are not the saviour of legacy B/OSS, but they are definitely the right thing to consider as CSPs develop their architectures for the provision of digital services. Don’t microservice an application just because you can – microservice an application with an idea of a valuable business application in mind.