This site is optimized for Chrome, Firefox and Safari. IE users, please disable compatibility mode for best viewing experience.

GRAVITY BLOG

Busting a few myths about microservices

 6 Jul 2017 /  Abel Tong, Senior Director, Solutions Marketing, Blue Planet

The topic of microservices architectures for application development is getting a lot of attention. Abel Tong from Ciena's Blue Planet team highlights some of the myths that have emerged around network operator adoption.

This article was first published in Light Reading.

Netflix, Twitter, Amazon and Uber are among leading industry giants that have developed applications based on a microservices architecture.

As we now take a closer look at the telecom sector's software development infrastructure, the idea of leveraging microservices makes a great deal of sense. Network operators need microservices to increase the agility and flexibility of their management platforms, scale and manage new virtualized service environments and deliver value-added services and self-service monitoring systems. (See Getting Up to Speed on Microservices).

As with any technological advance, a few myths have emerged, which is why it's a good idea to clarify some finer points to help network operators resolve confusion and keep their modernization efforts on track.

Myth #1: Network operators may lack confidence because microservices don't perform the way software development has always been done

Despite the natural, innate desire to resist change, network operators understand that the same old traditional OSS software infrastructures used for decades simply can't keep up with growing and/or volatile service demands. Because microservices represent a new approach that differs from the monolithic, proprietary software processes of old, there is concern this "new" method won't hold up, especially for enterprise-wide or large-scale applications.

However, the old software limitations have grown burdensome. Even small changes are difficult to complete. Each time a change is made in a monolithic application, the entire platform must be rebuilt and redeployed. Scaling, for example, requires replicating and scaling of the entire application rather than just the few individual service components that require more resources. This has slowed the process of delivering new services to a glacial pace. Meanwhile, the capex and opex of traditional monolithic application development processes are rising, as the costs to operate, maintain and upgrade legacy applications grow.

As a software development architecture, microservices deliver the same functionality as legacy monolithic applications, while adding openness, flexibility and the ability to easily make changes. Microservices use a development methodology first made popular in cloud services, and specifically designed to make applications easier to enhance, maintain and scale as needed. Network operators are finding that microservices can also help them achieve greater agility to remain competitive.

Myth #2 'Micro' means small or little services

Well, sort of. In computer science, a "service" is a function performed on behalf of a higher order program. In a microservices architecture, applications are built from loosely coupled and highly modular software components. Because the software components are largely independent, an application architected with microservices is easier to enhance, maintain and scale. Since each service component is decoupled, applications can be upgraded and new features can be added and deployed independently of the rest of the platform, with no downtime or interruption to operational processes.

Myth #3: One can easily 'convert' legacy, monolithic applications to microservices

Some software industry giants have told customers they've easily converted their heavyweight, monolithic platforms over to microservices. But in reality, adopting microservices requires "refactoring" or rewriting of the software architecture: It's not something that can be achieved by taking an existing, legacy monolithic application and changing a few lines of code. Instead, the process of adopting microservices takes time and effort.

Ultimately, the migration to modern microservices and open, collaborative software requires the transition away from legacy, monolithic, proprietary applications. But by learning to embrace a microservices architecture in software development, network operators will speed service delivery and agility. Embracing microservices will also increase collaboration across internal product and IT operations teams and improve the career path of IT professionals.

Leveraging software built from the ground up with a microservices architecture will help network operators generate the agility and flexibility they need to keep pace with changing market demands and shrink the time it takes to introduce new services. Network operators must understand it takes time and practice to fully incorporate microservices into an organization's development processes. Here's hoping this helps clarify a few of the myths to keep the migration to microservices on track.

RELATED

SEE THE LATEST POSTS ON SDN/NFV

Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) are...

Read More

WHITE PAPER: BLUEPLANET SDN AND NFV ARE CHANGING THE GAME

Network operators are struggling to meet performance, availability...

Read More

QUIZ: 5 FACTS TO TEST YOUR SDN/NFV KNOWLEDGE

Software-Defined Networking (SDN) and Network Functions Virtualization....

Read More
Get started now