Scott Carey, in his article on InfoWorld, poses the question, “Now, with many vendors focusing on managed services and abstraction, the pendulum appears to be swinging the other way. After the great fragmentation, are we due a great consolidation?”
If we look into the past, across telecommunications and IT technologies, we do notice pendulum swings across many macro concepts including the swing between modularisation / fragmentation and consolidation / monolithic architectures. Carey is right to point out that many vendors (and carriers) are focusing on managed services and abstraction currently. There’s a related macro-shift from outsourced telco systems development to insourced models. That’s brought about the hiring of developers and integrators to create customised solutions by the big telcos. This represents a shift towards software-isation of telcos, which are following the lead of hyperscalers by bringing increased programmability to their infrastructure stacks.
This line of thinking has generated many benefits for service providers. For example, an increase in Agile-led delivery has arisen in parallel with greater modularity and in-house control of what’s being developed. Advanced integration techniques have allowed for abstraction of the networks. This facilitates building highly flexible software stacks on top of the many, less adaptable and often legacy, network hardware stacks that telcos are obliged to keep alive and integrate with.
Service-oriented thinking has allowed for networks, old and new, to be wrapped in standard APIs and common services exposure patterns such as those proposed for Network as a Service (NaaS).
How to introduce Network as a Service
Think of this as an above-the-line / below-the-line concept, where “the line” is represented by the common API layer. Everything above the API is highly flexible software. Below the line consists of hardware and software, but is generally less malleable than software alone. Even considering virtualised and software-defined networking trends, changes below the line, in the networks and network orchestration domains, are not occurring at such a rapid pace. Changes are still happening, but just not at such a rapid rate of change as above the line, in the product catalog and service orchestration domains.
Carey’s article also refers to a commonly cited quote from Ray Ozzie (of Lotus Notes and Microsoft fame), “Complexity kills. It sucks the life out of developers; it makes products difficult to plan, build, and test; it introduces security challenges; and it causes user and administrator frustration.” And we should point out that Ozzie’s quote was made back in 2005. With the proliferation of choice available in the cloud-native era, the level of complexity that’s facing developers today would be many-fold greater than when Ozzie quoted those famous words. There were certainly far fewer choices facing OSS and BSS developers back in the monolithic days of Ozzie’s quote.
In some ways, complexity has diminished since then because developers are able to leverage existing libraries and containerisation, abstracting away complexity from their work. However, this shouldn’t be confused with there being decreased complexity in the top-to-bottom stack, as the log4j vulnerability has highlighted recently. Developers are now faced with more difficult choices between the many technological options available at design time, not just for initial development, but for entire DevSecOps life-cycles. Carey’s article also highlights that, “each of the big three cloud providers—Amazon Web Services, Microsoft Azure, and Google Cloud—offers about 200 unique services to customers, across compute, storage, database, analytics, networking, mobile, developer tools, management tools, IoT, security, and enterprise applications.”
Getting back to the technology pendulum, like Carey we wonder whether there will be a shift to greater consolidation of frameworks. Instead of these hundreds / thousands of discrete services, will we see greater consolidation via packaged combinations of these discrete services? Looking at this from a more local perspective, could you make things easier for your developers by increasing consolidation, especially below the line?
The SunVizion tools combine many discrete services. They also provide a common API / services layer that allow for abstraction of network complexity for above-the-line application developers to utilise. This provides the best of both worlds for developers – the ability to rapidly evolve for any customer-facing needs (above the line), whilst also retaining consistency of service exposure (on the line), yet having a proven track-record of being secure and adaptable to any network trends (below the line). Applicable SunVizion tools include:
- Service Fulfillment – a service-oriented solution that consolidates Service Inventory, Service Catalogue, Workflow driven Service Order and Orchestration, Resource Management, Workforce and Material Management
- Network Inventory – a comprehensive solution for managing multi-technology networks, their connections and ongoing capacity management
- Smart Service Designer – a catalog-driven solution for decomposing orders into dynamic orchestration plans that can be pushed into your network
If you’d like to reduce complexity for your DevSecOps teams, then book a consultation with us to find out how the range of SunVizion solutions can help.