Talk:Orchestration (computing)

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Buzzy?

"In reality, orchestration ..." does not seem to be befitting to an encyclopedia. J12t (talk) 19:31, 25 November 2011 (UTC)[reply]

Not to mention the whole thing is just a meaningless buzzword invented by Canonical to differentiate themselves. This article is clearly astro-turfed by Canonical employees. — Preceding unsigned comment added by 109.145.165.125 (talk) 13:20, 18 August 2012 (UTC)[reply]

This is full of jargon and buzzwords, unintelligible to most readers. I suggest this whole article on orchestration needs to be re-written by someone both conversant with the approach and able to write material in plain Englsh suitable for an encyclopedic entry. — Preceding unsigned comment added by 62.7.73.66 (talk) 08:59, 14 May 2013 (UTC)[reply]

Agreed, needs much work, to at least use the Wikipedia style, for example. Sigh. It is an accepted term, however, so deleting might not be in order. W Nowicki (talk) 21:12, 3 September 2016 (UTC)[reply]

I came for a clear definition of the term, and was left more confused. Needs an initial sentence explaining that in IT, orchestration refers to ... PS Nothing wrong with Canonical - Red Hat need some competition. — Preceding unsigned comment added by 80.194.70.52 (talk) 15:29, 26 October 2016 (UTC)[reply]

Agreed with the above -- this article has no substance. I still don't know what orchestration means. 160.91.17.0 (talk) 20:00, 5 March 2018 (UTC)[reply]

As a summary: modern decoupled software applications are architectured as the composition of several, independent services, and the relationships among them. Think of micro-services architectures, or their predecessors, SOA architectures. Whenever there is a control service which manages the relationships among the services which compose the application, we say that the architecture is orchestrated. These applications are easy to implement, but are risky because that control service (a sort of orchestra director) constitutes a unique point of failure: break it, and the whole applications is pulled down.

Coreography, on the other hand, has no control service at all, which means that all what is happening in the application is handled by the services themselves. These applications are harder to implement, but they are more robust (some services might fall down and the application keep working with the rest of them) and easy to evolve.

Imagine, for instance, a web page which shows a list of the Users in a given application: you may have a microservice to handle User profiles (names, addresses, etc), and another microservice to handle User pictures. Under coreography architecture, the Picture handler service might fail, but the web page would work well, exception made that users pictures would be showing all the same default picture. In an orchestrated architecture, even though the Picture service and the Profile service were working perfectly, were the orchestra director down, the web page contents would be blank, in fact even the whole web page might be showing an HTTP 500 error. — Preceding unsigned comment added by Jmquarck (talk • contribs) 12:15, 9 March 2018 (UTC)[reply]