Everyone talks and refers to Orchestration, however it seems that each means something slightly or sometimes very different. Also, it seems that no one has a conceptual solution for orchestration.
This short post will try to outline the key concept and what it means from a technology perspective.
Introduction into Orchestration
The world of Infra is changing, fast. Cloud, Hybrid, Microservices combined with Internet of Things (IoT), Big Data and “Software defined everything” is changing and shifting infrastructure, and with it the role of Capgemini Infra and our partners.
This shift is moving Infrastructure from a once “only technical focused” capability, where infrastructure capabilities like MHz, RAM or FLOPS was the only target, to a business enabling capability where outcomes are business focused. Infrastructure is becoming more “business aware”.
This shift is driving the “componentisation” of standard Infrastructure services to enable easier application. The shift will allow us to construct and consume infrastructure like using electricity…today – it should just work; in a turn-key fashion without having to mess about with deep technical and mechanical aspects.
Next to the “componentisation” of standard Infrastructure services (the Lego approach) Infrastructure is increasingly automated (read DevOps), hybrid (read mix of private and public cloud services) and software based (for compute, storage and network).
In Technovision 2015 we introduced the idea of an “invisible infostructure”; an “infostructure” that uses the Lego principle to construct and deliver Business enabling IT solutions. The next challenge for Infra is now to orchestrate these services and capabilities – both for the Business to consume and for the IT to provide.
As per wiki :”Orchestration is the automated arrangement, coordination, and management of complex computer systems, middleware and services.”.
Furthermore it defines: “orchestration in this sense is about aligning the business request with the applications, data, and infrastructure. It defines the policies and service levels through automated workflows, provisioning, and change management.”
This creates an application-aligned infrastructure that can be scaled up or down based on the needs of each application. Orchestration also provides centralized management of the resource pool, including billing, metering, and charge-back for consumption.
For example, orchestration reduces the time and effort for deploying multiple instances of a single application. And as the requirement for more resources or a new application is triggered, automated tools now can perform tasks which, previously, could only be done by multiple administrators operating on their individual pieces of the physical stack”
Orchestration in detail
Orchestration has become more and more important as companies increase the use of cloud related capabilities. As with so many terms in the IT industry the word “orchestrator” can related a number of areas:
- Business / Application Orchestration
- Cloud Orchestration
- Traditional Orchestration
As illustrated when designing a solution (here a simple end 2 end business process) the aggregation of all individual service behaviours is needed to ensure that overall business process executes in (for example) under 1sec, or is 99% available etc.
Many applications are now also hosted on SaaS (Software as a Service) based platforms and to complete a full business process a number of application services maybe have to be invoked, both on and off- premise.
When consuming such a service an end user has seldom neither the ability nor the need to “open the box” and understand what is inside. There is no need to understand whether the service is constructed on a mainframe system or on a single host Linux server being capable of providing the application service according to a certain non-functional characteristics.
However, more and more services are “constructed” using / consuming a number of SaaS services in tandem and as soon as this is the case, closer consideration regarding the non-functional characteristics of an individual service is needed –a business / application level orchestrator is needed.
The same / similar principle can be applied to infrastructure near capabilities. To support the business process three different applications might be used and each might be implemented using a hosted cloud based, an application that is running on a private cloud and an application that is running on traditional infrastructure.
Business Process Orchestration
When looking at both definitions as well as at the products and services that are entering the market there is a clear need for a “business process oriented infrastructure”. An infrastructure capability that is business aware without being business near. The key idea is that infrastructure services should be can be scaled up or down based on real time end user needs. Service Orchestration also provides centralized management of the resource pool, including billing, metering, and charge-back for consumption.
In order to scale up or down, the related infrastructure has to be “orchestration compatible”. In particular when business processes traverse company boundaries interfaces the “infrastructure service capabilities” have to be aligned to ensure that the resulting end to end business process complies with the overall service level agreements (SLA) as well as the key performance indicators (KPI).
Infra Orchestration based BluePrint
Service Orchestration is first and foremost about maximising value for money by using / re-using services from different sources – suppliers/vendors. And as the IT market is moving more and more into infrastructure commodity where server hosting, storage as we as other infrastructure near services are readily available might suggest that Service Orchestration can consider infrastructure services as black box. Also when constructing the end 2 end business process model traversing numerous vendor boundaries some might consider that infrastructure is an area that can be dealt with at a later stage.
Both assumptions are invalid. Not considering infrastructure related aspects at the start of a project or assuming that infrastructure is a black box will lead to an end 2 end solution that will most likely not work; it will struggle to meeting overall performance and service level requirements as well as might miss critical security related requirements.
Using the material outlined in the Microservices document as well as applying Cloud, Automation and Orchestration related principles the following BluePrint can be defined:
Implementing an orchestrated infrastructure requires a clear understanding, a business case(s) as well as a clear transformation plan incl solution. Cloud is a key “ingredient” and using a microservices approach will help organisation achieve their business objectives.
No two organisations approach the Cloud with the same objectives. Through Cloud Choice , we help enterprises develop and execute the cloud strategy they need to support ongoing innovation and sustainable value.
Thanks for Reading.
About the Author: Gunnar Menzel has been an IT professional for over 25 years and is the VP and Chief Architect Officer for Capgemini’s Infrastructure Business. Gunnar is also currently the President & Chairman for the Open Data Centre Alliance. His main focus is business- enabling technology innovation.
 MHz = Mega Herz
 Ram = Random Access Memory
 FLOPS = Floating Point Operations per Second
 Cloud Choice : https://www.uk.capgemini.com/cloud-services/cloud-choice
This article was written by Gunnar Menzel from CapGemini: Capping IT Off and was legally licensed through the NewsCred publisher network.