Orchestration and the server environment Few words in the IT industry’s vocabulary are more grandiose than ‘orchestration’, evoking images of symphonic movements, rows of groomed musicians and wild-haired, baton-pointing conductors. Just how the term came to be used for the allocation of server resources must leave IT managers more than a little flummoxed, however. …
I first ran across the term "orchestration" being applied to IT in the mid-1980's, when IBM was trying to sell their concept of requestor/servor systems. The notion was that you had token ring networks of OS/2 PCs going through a TPF "orchestration layer" to a mix of IMS databases.
The design broke down in much the same way that all later attempts (eg 'web services" have. The orchestrator has to hold all context for a transaction; but cannot maintain simulataneous locks across across the various database systems. You can choose between creating a rich minefield of deadly embrace, or resign yourself to a large number of unresolved transactions.
What generally happens is fake orchestration, where specialized code is built to handle known issues with cross servor transactions at the orchestration layer, but each data base system operates it's function in isolation. If you are willing to abandon concurrency and reliabilty, you can give the appearance of orchestration.
Orchestration or Automation in a server environment exists and is more prevalent than you might think. Typically an organization requires a mature individual that understands the benefits and value of orchestration. Secondly, the organization requires a shift in thinking away from the manual processes that are so embedded in day to day activities. The second of the two is often harder to evangelize and spread throughout an IT shop. At first, orchestration technology may seem to make things take longer, but as an organization matures in this space, and orchestration becomes more second nature to the IT staff, the benefits become readily apparent.
The concept of “network orchestration” is one of rapidly moving around workloads, or deploying a system from a template in minutes. If you are running any good virtualisation stack and have paid for management tools with all the blue crystals, then you know this is both easy and doable today if you so wish. (You can do it on metal with ghost and its compatriots, but it's slightly messier.)
The first issue to mind is cost. You have to pay not only for your virtualisation management tools, but for all the blue crystals necessary to really make them shine. You have to reinforce your backend infrastructure. Those VM templates have to live somewhere, and that takes storage. Your network has to be fast enough to handle the demands placed on it. You might even have to upgrade from your current setup to something involving the acronym "SAN" before you can play in this magical fairy world of high and rapid availability where you can "orchestrate" workloads on your network. (This is something that is only now becoming a realistic option for smaller shops.)
The second issue, and perhaps a bigger one, is that the concept or "orchestrating" a network of servers implies that the sum total of systems administration is really nothing more than provisioning. Provisioning of servers has indeed become easy, but you still have to the legwork of honest-to-goodness R&D. Someone has to make those templates. You have to patch test, version test, regression test, check, re-check and do it all over again. Somewhere someone has to be constantly testing the network to see how long deploying a template will take, or how long migrating a workload from one node to the other will take. Not all workloads are feasible to hot-move, and scenarios must be drawn up to handle this. Somewhere disaster planning and documentation all have to be done, all of which is part of the performance, but occurs "behind the scenes."
The business sees provisioning. They request a server, and moments later they have one working. In this sense server provisioning has almost become as easy as desktop provisioning. The operating environments are just spawns of some master copy somewhere and you move on.
It is dangerous to use words like "orchestrating" because it's far too simple for others in the business to forget the amount of practice an orchestra requires.
I've used Citrix Provisioning Server (part of the XenDesktop suite) to boot servers from a single central image. This gives great agility when provisioning, and re-provisioning servers to particular roles.
It allows the hardware to be seen more as a resource, rather than dedicated "web server" or "file server". It takes IT deps a while to get their heads around this concept that a piece of tin can change its role as fast as it takes to reboot, but once they realise the agility this gives them - especially with rapid upgrades, easy rollback etc they generally quickly come on site.
This provisioning technology of course works best when you've virtualised your servers as it removes the hardware dependacy in the images but can be applied to "legacy tin" to achieve similar benefits.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
