logo_header
  • Topics
  • Research & Analysis
  • Features & Opinion
  • Webinars & Podcasts
  • Videos
  • Event videos

How to scale microservice architectures

Ed FinegoldEd Finegold
08 Mar 2023
How to scale microservice architectures

How to scale microservice architectures

As CSPs adopt microservices across their businesses, managing large environments will become more challenging – especially as they span multiple clouds, as examined in this extract from the report Microservices: paving CSPs’ path to the cloud.

“It’s not easy to manage and operate a bunch of microservices which are purpose-built and likely run by diverse teams that aren’t necessarily co-located… But it has tremendous upside potential if done right,” says a senior product manager with a leading hyperscale cloud provider.

Although there is not one simple, correct approach, “there are some widely accepted best practices when it comes to operating applications built on microservices architectures," the product manager says, citing monitoring and observability, network security and governance as key.

He points to the “shift left” movement, where operations or DevOps teams design observability, network security and governance into applications before code moves into production. “In essence, operations are no longer an afterthought, rather it is part of the application development lifecycle,” he says.

More sophisticated IT operations

Shifting left to applications development that is IT operations-aware demands new skills. In the survey for TM Forum’s Digital Transformation Tracker 6, more than twothirds of CSP respondents rated data analysis, machine learning, DevOps and cloud computing among the skills they need most, with security rounding out the top five.

Each of these skills comprises the multi-disciplinary abilities needed to operate cloud-native networks and large microservices architectures.

As IT operations become more complex, requiring observability, security and governance, IT operations need to be managed in a live network operations center (NOC).

“The pattern that I have seen emerge is more organizations are moving toward a single pane of glass experience [for IT operations], so their app development teams can quickly and with least possible effort identify an issue to achieve better MTTR [mean time to repair],” explains the hyperscale product manager.

This means that IT software engineers will be working with network engineers in CSPs' NOCs, and in some cases it might mean retraining or upskilling network engineers with software skills.

However, as automation of networks and operations progresses, the idea is for the NOC to become obsolete. Marc Rouanne, Chief Network Officer at DISH Wireless, explains: “My dream is to have no man-machine interface. No alarms, no reports. No NOC, no nothing.” In this vision, the network operations center ceases to exist because an alarm is just an event, a trigger for an orchestrator to act.

What about scale?

Whether microservices architectures can scale is a concern expressed by all the CSP architects interviewed for this report. The big question is how the increasing dependence on clouds and microservices will impact the network-service-customer models and practices used for network and service management.

TM Forum’s Glass says CSPs need to “work out many steps in the background about where the resources are, who has access to them, who has permission to use them, and how you prioritize them when demand exceeds supply. So, for example, when they are busy how do you manage competing requests from network microservices?” Here, the focus is not on the cloud IT infrastructure, but rather on how customers are impacted by the collective performance of the technology stack.

The underlying IT infrastructure and clouds are just one piece, but they represent a critical dependency that must be managed from a service management perspective. Glass suggests that network, service or operations functions should not be defined too granularly in independent microservices because “you end up having to build all the logic of these complex services.

Increased granularity can breed complexity, making it harder to scale, manage and diagnose problems with networks and services, which is part of what makes CSPs’ adoption of microservices across all domains so complex. But some operators and their hyperscale partners are already anticipating the next step for microservices.

Serverless computing

Microservices technology is evolving to find new ways to use componentization more efficiently at greater scale. Serverless computing architecture, for example, takes much of the overhead out of microservices deployments.

With this approach, users need not “deploy, maintain and operate the servers on which you run these microservices,” says the hyperscale product manager. He adds that because the service offers elasticity, “you don't have to predict and run large fleets” of servers to scale, which in turn lowers costs. Some operators are examining how to use serverless computing as an option for mobile core architecture. “Scaling is not a problem with serverless since it’s cloud managed,” says Harpreet Singh, Wireless Product Team Manager at TELUS.

“With serverless we kind of outsource container management and scalability, so we focus on functions and compute.”

He adds that this not only helps to eliminate or solve some of the scalability concerns with large, message volume heavy microservices architectures, but it also enables far faster development because developers are not tasked with scale and container management.

Other architects share concerns, however, that even in an IT infrastructure setting that might scale elegantly, the dependencies between network and service commitments and IT infrastructure performance must be observable and able to be reconstructed after the fact.

Read our report Microservices: paving CSPs’ path to the cloud to find out more.