Many communications service providers (CSPs) are considering the deployment of microservices as part of their transition to DevOps and as a facilitator for the adoption of open APIs. In this interview, Neural Technologies VP of Marketing Claus Nielsen discusses how CSPs should embark on this transition to a microservices architecture and the implications that it will have for their IT organisation.
MN: What is the right starting point for the adoption of a microservices architecture in an IT organisation?
CN: For any service creation it starts with the user journey. Once you’ve ironed out what your business objectives are with the solution that you’re trying to create then you start to look into how you address that particular customer journey. And that’s where microservices can help you. For example, let’s assume for this particular customer journey there is a need for a specific customer engagement. If other customer engagements already exist, you can take specific components or microservices within that application and reuse them as part of the new solution you are developing.
When you are looking at different applications, with a view to move to a microservices architecture, you need to think about which elements it might be possible to reuse in other applications. It’s a question of seeing what commonalities exist across different apps.
MN: How do you transition from large monolithic apps to a microservices architecture?
CN: You should look at what sections of your app would benefit from being split up into microservice components. This comes down to what commonalities you see across different apps. It’s a bit like a car manufacturing plant and deciding which functions and processes you automate by using robots and which ones you don’t. Some parts of the factory may not benefit from automation or robots.
The same is true of microservices where it may be possible to scale some applications independently in which case there is no real case for microservices. That said, when any application has grown to a certain size or complexity it may benefit from being split up into smaller components.
MN: What are the new skills or roles that you need for a microservices architecture?
CN: The most important new position is a microservices solution architect. The role of a solution architect before was different. They were responsible for the architecture of the particular application. Now the solution architect has to worry about when you divide an application into microservices and how the developer team works together. We’re talking about a DevOps organisational structure here, a key part of which is a willingness to share. Before the solutions architect was a technical role, but now you need someone who understands technology but also understands people.
The role is a bit like being the conductor in an orchestra – responsible for how all the different instruments of the orchestra plays their individual instruments but also how they come together as one that will produce the expected concert.
MN: Does the company need to make organisational changes if it is to adopt a microservices architecture?
CN: The big difference is that teams (of developers) become focused on a specific line of business or division – it could be a front-end customer function, or a back end division or maybe the marketing or finance function. They become more aligned to the business rather than just sitting in IT.
Before marketing came to IT and created this vision of the application they wanted. IT then went away, created something and came back and says this is what you want, and it might be right or it might be wrong. Now, each team or division has its own developers and they can take microservices that have been developed in other parts of the business. The microservice solution architect is just responsible for making sure that each team follows the rules.
From a governance perspective, the microservice solution architect is responsible for creating a common set of tools, or for stipulating that the business uses standard-based APIs for communication, or a common data structure. So, in this microservices architecture there is a set of rules for standardised tools across the organisation but different teams have freedom to decide how they use these tools. In this way the microservice solution architect becomes an enabler or an inventory manager of the tools and capabilities that different individual business IT teams can use.
MN: From a develop perspective are any new skills needed in a microservices architecture?
CN: Developer skills are basically the same. But they do need to have a mindset that they own a piece of a solution and not “everything I’ve built is mine”. As we’ve already said, the role of the microservice solutions architect is different.
MN: What types of CSPs are starting to embrace microservices?
CN: It’s really the larger ones, the operator groups. But even with these companies, if they don’t have a good digital transformation strategy it’s not going to work, microservices need to get to other data to enable intelligent decisions.
I was speaking to a chief architect at a large European operator group recently about data and data management. He told me that they were already using microservices in customer-facing systems but they hadn’t introduced them for back-end systems managing the BSS and OSS. One of the reasons for this is because they don’t share data across the organisation. If you think, for example, about fraudulent activity on the network, the back-end systems need information from the customer-facing part of the business in order to make an informed decision.
As part of the TM Forum’s Open Digital Architecture initiative, data is shared across the entire organisation and you adopt a virtualized data lake concept. This means that even if the data is dispersed in different places around the organisation, you can use a metadata dictionary to get hold of the data that you need.
