3 reasons to deploy applications built on microservices

While microservices architectures are nothing new to webscale companies, the network operator community is only now getting to grips with what it means to build software products and solutions in this way.

Netflix, Amazon and eBay have many advantages over classic communications service providers (CSP) in that they are (generally) working from a clean slate, developing new applications to deliver new services, rather than continuously trying to retrofit decades-old infrastructure. However, the telecommunications industry is currently undergoing its biggest evolutionary leap in perhaps the last century.

shopping-cart-with-boxes-on-laptop-computer.jpg

Network Functions Virtualization (NFV) and Software Defined Networking (SDN) initiatives are enabling operators to completely rethink not only how communications services are deployed but how they are delivered. They are quickly discovering that continuing to work with vendors who simply decouple software from proprietary hardware and port this archaic codebase onto whitebox switches and servers or virtual machines is not in their best interest.

In order to realize all the potential benefits of NFV and SDN, carriers are increasingly recognizing that their suppliers must fundamentally go back to the drawing board when it comes to architecting and developing individual network functions. Vendors building communications software for NFV or SDN infrastructures must start from scratch with new frameworks and modern development technologies and techniques, whether they are creating innovative new applications or simply supporting a profitable legacy service.

Developing and deploying applications using microservices methodologies affords numerous benefits over creating and installing software services with monolithic codebases.

1. Better software delivered sooner

As a codebase grows, it becomes increasingly difficult to understand and modify. This compounds over time, further complicating the software implementation while rapidly degrading the overall quality of the code. Large engineering teams must work in parallel, as even the smallest code change could affect other contributors in some manner. Plus, testing necessitates a complete new build of the software, requiring engineering groups working on otherwise distinct components to be totally synchronized.

With micoservices architectures, individual engineers or small groups of programmers can focus solely on one element of an overall application, contributing code far more rapidly and with their own programming style, without close regard for other components being delivered in a similarly disaggregated manner. These subject-matter-experts employ a microservices framework which provides a development toolchain that dramatically simplifies the software engineering process. The result: Better code delivered far more quickly than in the past.

2. Efficient and resilient implementations

Monolithic software designs demand monolithic implementation and scaling approaches. A Java application, for example, may comprise several services and components but it is deployed on a dedicated server or static virtual machine as a single, large WAR file. Not only do these instantiations have high overheads, they have inherent inefficiencies resulting in poor utilization of the underlying compute resources. With the slow boot times of servers and VMs, software resilience is typically implemented (effectively) 1+1, with complete copies of the application taking compute resources as they stand idle, waiting for failures.

In the same way that microservices are developed in more agile engineering environments, they are also deployed and scale in a far leaner fashion than classic, monolithic applications. Built to be cloud native, each instance of a microservice can be installed on-demand within its own lightweight Linux container. With the almost-instantaneous turn-up of a container, redundancy can be totally on-demand. Moreover, in the event of a failure, the system only needs to re-instantiate the individual microservice component that failed, rather than the entire application.

3. Easier upgrades and enhancements

Already recognized for their lengthy development cycles, monolithic software deployments continue to cripple service innovations and evolution. In production environments, these applications demand complete service upgrades for each small change, making the introduction of new features an extremely long and laborious process. Furthermore, it is practically impossible to change the underlying development framework. If newer technologies, programming languages or software engineering techniques emerge, the programmers cannot make use of their benefits and are forced to continue coding in the original language.

Complementing the agile development environment, microservices methodologies provide the foundation for the adoption of continuous development (DevOps) approaches to software development. Individual components can be enhanced in isolation, tested, and then deployed in the production environment without the risk of service-affecting outages. Microservices employ a framework which provides a development toolchain that dramatically simplifies the software engineering process, so software engineers can focus on new features rather than the underlying infrastructure.

Conclusion

As network operators make inroads in NFV and SDN, they must not forget that success depends on how the service delivery software is architected. As old network infrastructures are jettisoned and replaced with modern implementation templates, software development techniques of the past must also be left behind.

Microservices could make the difference between a fruitful business model and a failure, which is why microservices are a critical ingredient in rapidly emerging Network Function Disaggregation (NFD) product development and service deployment philosophies.

 

Download the white paper: The application of cloud native design principles to  network functions virtualization