Microservices architecture (MSA) can be defined as a system of fine-grained, independent and collaborating services that run in their own process spaces and communicate with lightweight mechanisms such as HTTP. The services are kept small and evolve over time with an increased set of features. The advent of cloud computing, DevOps and microservices (MS) has led to faster creation, delivery and refinement of new services and applications.
Think of DevOps and MS as the assembly line for cloud–based applications. Just as industrialization changed the process of production and distribution of physical good and services in the 19th and 20th centuries, DevOps and MS are changing the production and distribution of digital goods and services in the 21st. The assembly line, first introduced in the early 1900s, accelerated the pace of industrialization by replacing hand–crafted, custom–made parts with standardized parts, paving the way for mass production and a dramatic rise in productivity. As Henry Ford’s assembly line revolutionized auto manufacturing, MSA is revolutionizing the “manufacture” of cloud–native applications.
But what are the implications of MSA for telecommunications and communication service providers? While microservices have relevance in many environments, they are usually associated with cloud–native architectures, and CSPs are not yet on board for the cloud ride. Until recently, microservices were assumed to be a work of science fiction by many CSPs. They have been saddled with the baggage of legacy systems, technologies and processes and are used to buying IT systems from third–party vendors.
But times are changing. Digital transformation is becoming a top priority for most major CSPs with implications for all aspects of their service offerings.
■ Business – The synergy of the telecommunications industry with other industry domains gives CSPs the opportunity to explore new service offerings. The emergence of the new ecosystem is transforming organizations to create new service lines and rework the business processes with increased automation. For example, CSPs providing custom solutions for IoT networks and Machine–to–Machine communication.
■ Delivery – The adoption of cloud technologies like Platform–as–a–Service (PaaS) and Software–as–a–Service (SaaS) has led to the transformation of core assets, such as physical networks. Physical networks have been digitalized by software–defined–networking (SDN) and virtual network function (VNF). There is a need for all services to be intelligent and offered on–demand. For example, zero–touch provisioning, self–service, real–time analytics, etc. However, CSPs realize that virtualization alone may not be sufficient to provide the agility required to become digital service providers.
■ Operations – Compliance with SLA–based operational models will transform CSPs, reorienting them to service–level objectives (SLO) based internal operational functions. For example, moving from reactive incident resolution to proactive detection and resolution.
CSPs are reworking their business models, IT systems and cultures to stay current with market demand. It is now or never for them to figure out their Uber model for offering services. Digitalization and MSA will transform the key functions of CSPs in a number of ways, including the following:
■ Operation Support Systems (OSS) – MSA can facilitate frequent changes seamlessly to OSS components. Microservices can provide an outer layer, which decouples OSS from ever–changing environments consisting of discrete network–element managers. Some areas where MSA can be used include network diagnostics and monitoring, inventory provisioning and resource activation.
■ Business Support Systems (BSS) – By adopting MSA in BSS, CSPs can avoid expensive customization and upgrades of COTS packages. Feature gaps can be plugged by implementing microservices. This strategy not only reduces time to production but also takes care of sporadic traffic surge. Areas where BSS can take advantage of MSA are order management, offer management and product catalog.
■ Core Network Functions – There is a growing realization among CSPs that virtualization may not be enough to create the agility required to transition into digital service providers. The on–premise commodity–hardware–hosted VNFs will transition to cloud–native VNFs deployed as microservices on a PaaS layer. This will facilitate seamless feature upgrades and scalability. Microservices become the nuts and bolts of SDN platforms creating an environment for dynamic and on-demand bandwidth services.
Quite a few large operator groups have started initiatives to evolve their networks into the cloud; for example, AT&T’s Domain 2.0, Telefónica’s Unica, Telstra’s Network 2020 and Vodafone’s Project Ocean. Also, one of the three key concepts of the 5G architecture being talked about today is its cloud–native architecture. This would ensure popular modularization of network functions.
The world of cloud–native microservices looks exciting. However, CSPs must tread cautiously. Some aspects for CSPs to keep in mind include:
■ Change in organizational culture – Along with selecting the best tools and technologies, CSPs must focus on building a culture that encourages experimentation. They need to prepare for major organizational changes including new business cultures and decentralization of responsibility.
■ Adopting cloud–native technologies – There are a plethora of technology stacks available for doing the same thing. The challenge is to make judicious choices. For example, evolving monolithic applications into granular applications requires fresh design thinking based on the principles of domain–driven design and the relevant business processes.
■ Embracing DevOps culture and philosophy – CSPs must create a culture where teams are ready to deliver new features and code every few days. DevOps principles break down the silos within teams; everybody needs to be willing to perform any task including development, verification and operations.
■ Make realistic bets – Don’t try to create hundreds of microservices from the very beginning. This will make management and orchestration of microservices too complicated. It is fine to make modestly sized services in the beginning and break them down into smaller microservices over time.
Adopting MS is not a big–bang step, it’s an iterative journey. First, CSPs need to define a multi–year microservice adoption roadmap. Establishing the DevOps culture and choosing the appropriate technology stack is the foundation on which success of the microservices journey depends. A good reference for discovering microservice–based business capabilities is a suite of Open APIs offered by TM Forum, a global industry association. These APIs are mapped to the Frameworx Business Process and Information Frameworks (eTOM and SID). Aricent’s cloud–based deployment offerings enables the digitalization of legacy products and use of microservices architecture and container technologies for new product development. These and other resources can help guide CSPs on their journey of digital transformation.