The catch-22 of service orchestration

Automating service deployment can cause a dilemma if not done properly. Deploying services manually has the benefit of unlimited flexibility. Smart engineers can principally configure services to meet any customer requirement. However, that way of working is infeasible. Service deployment projects take too long time and introduce too many errors. Furthermore, the operational cost is too high since you need a larger staff to cope with the demand.

Accordingly, many service providers and enterprises automate service delivery.  Ironically, this type of automation is often counterproductive. Service providers tell us this leads to a culture of “it works, don’t touch”.  We refer to this as the “catch-22 of service orchestration”.

In a typical example, a part of the catalog is automated with a “hard-coded” solution which required a long and costly software project. The solution then fulfills the goals of fast and error-free configuration, but it does not offer the flexibility to adopt the portfolio to new customer and market needs. It takes yet another long and costly software project to achieve this. Therefore, there is a risk the organization falls back to manual configurations.

Illustration of the catch-22 in service orchestration

How can we use service orchestration to  avoid this situation?

There are several things to consider to remain flexible and still automate:

  • Inhouse DevOps teams: Do not outsource everything to an external partner. You need the skills internally to implement changes.
  • DevOps culture: Your product owners, and operations and development teams need to work together in an efficient manner. See a presentation on the topic here: https://www.slideshare.net/stefanvallin/devops-for-network-engineers
  • An automation/orchestration platform that supports both design-time and run-time features. At design-time, the design team must be able to design, implement and test new or changed services within days or weeks. Operations can then easily automate the deployment. It is a litmus test when you select the platform, how quickly can you implement a simple service yourself. Is it hard-coded? Aim for model-driven platforms that render themselves from data-models like YANG or TOSCA. Evaluate seriously with your own development teams.

Illustration of an automation/orchestration platform that supports both design-time and run-time features.

A fast turn-around in the design phase delivers a quick turn-around of new services to the market. A fast and error-free run-time engine gives fast service delivery to customers.

It is also important to have a partner that guides the organization towards this way of working. You should focus on training, technical expertise to help in implementing the first services and work towards a model where you maintain and further the services internally.

At Data Ductus, we have helped clients around the globe to establish efficient in-house DevOps procedures. We’d be happy to share our experiences with you.