Within the past few years, organizations have begun to recognize not only the business benefits, but also the technical benefits of network automation. Automation within specific domains has driven significant improvements in productivity and efficiency, which is pushing organizations to look to the new wave of network automation that orchestrates across technology – Multi-Domain Service Orchestration (MDSO).
MDSO is something we’ve been able to help our customers build impressive initiatives around. The unique flexibility of the Itential Automation Platform has enabled organizations to use it across a wide range of contexts, use cases, and domains. In some environments, the platform is exclusively performing as a multi-vendor, single domain automator, while other implementations are dedicated to performing service orchestration across multiple technologies and domains. These experiences have given our team of architects and engineers a unique perspective and insight into the challenges and opportunities that come with ambitious orchestration implementations.
The Complications of MDSO Across CLI & API-Driven Domains
Multi-domain service orchestration has it challenges – effective service design, availability considerations for orchestration platforms, and mitigation strategies for environments with incomplete sources of truth. I actually covered this in a recent webinar with Steven Schattenburg, a Senior Architect at Itential, who has helped our customer’s implement MDSO in their own environments.
During our conversations preparing for this particular webinar, Steven and I were able to discuss a lot of our different experiences and perspectives implementing MDSO projects and an interesting topic arose that isn’t often talked about when discussing the challenges of MDSO – the challenge of how to connect automation activities that are being driven within domains to the activities that are being driven by IT Service Management (ITSM) or Service Order Management (SOM) to orchestrate emergent multi-domain services in the edge and hybrid cloud realms.
The reality is that there are unique complexities of implementing multi-domain service orchestration in environments that contain some domains dominated by network functions/devices that were primarily CLI-driven (like IP and mobile core domains, which have undergone the transition to NetConf/Yang) and other domains that are predominantly API-driven, such as cloud domains (public/private/hybrid). It may look a bit like this:
Not only are these domains providing fundamentally different functionalities, but the controllers associated with these domains are exposing capabilities at different levels. Capabilities like intent are significantly more robust in the cloud domains, where tools like Terraform are widely being used. In the CLI-heavy domains, intent has been much more difficult to fully implement. The diversity of network functions, implementations, and configuration options have made it virtually impossible to expose a level of intent that even comes close to the cloud domains – except for very limited use cases.
An example I’ve used often is a McDonald’s Happy Meal, something most are familiar with (who doesn’t love a Happy Meal!). In this context, one domain may be able to execute on the request for a Happy Meal, while the other domain controller requires me to order my Happy Meal individually as one cheeseburger, one small fries, one drink, one toy, and one box – forcing me to take on the effort of building a Happy Meal myself. Both outcomes are the same, but one domain makes it easier to order than the other.
This situation leaves teams with some difficult choices to make – as they cannot count on equivalent levels of capabilities from the domain controllers. The heavy lifting needs to be performed either at the MDSO level or at the domain controller level, and most platforms have developed their systems based on the assumption that the other systems will do the work.
How Itential’s Flexibility Drives Multi-Domain Service Orchestration Success
One of the key capabilities and differentiating components of the Itential Automation Platform is it’s flexbility. Instead of hard coding the platform to a specific data model and implementation pattern, the platform utilizes JSON and JSON schema as the internal data representation model. This enables Itential to easily translate between disparate models, domains, and systems. One benefit of this is that the platform can address the gaps between domains, whether CLI or API-driven, by incorporating features such as our low-code workflow orchestration capabilities and our data transformation functionality.
Since you’re probably still thinking about that Happy Meal, let’s use that example again. An Itential user can quickly create an object called “Happy Meal” that identifies all necessary components (cheeseburger, fries, toy, drink, and box). This object can be called from a workflow that would have the intelligence to understand which type of order to place instead of having to order each item individually. One of the design goals of our platform was to provide a toolset to make these kinds of operations simpler, as this scenario happens constantly in a multi-domain environment. This unique approach makes our platform the solution of choice for multi-domain service orchestration.
In fact, ACG Research just named Itential as a leader multi-domain automation and orchestration based solutions, with our platform’s flexibility being a big contributor as to why we’re top choice for communications service providers across the world. You can learn more about our unique approach and why it makes us a leader in the full report.
Both Steven and I agree that the next 18-24 months are going to be critical for any organizations implementing multi-domain service orchestration solutions that go beyond basic services to provide true Network as a Service (NaaS) functionality. The choices they make regarding North/Southbound interfaces will have a huge impact on the cost and complexity (and ultimately the success) of their implementations. You can learn more about Itential’s unique approach to multi-domain service orchestration here or check out recent webinar here.
Morgan Stern
Vice President, Automation Strategy ‐ Itential
Morgan Stern serves as the Vice President of Automation Strategy for Itential, where he is responsible for assisting Itential’s global customers in developing, implementing and deriving value from their automation strategies using the Itential Automation Platform. For the majority of his career, Morgan has focused on assisting large enterprise and service provider organizations in maximizing the business impact of new technologies as an architect, consultant, author, and industry speaker.
