TIBCO Silver [EOL] Reviews

I attended TIBCO's PaaS workshop, where they showed and demoed Silver Fabric - the product that has come forth from the DataSynapse acquisition in September 2009. Erik Hageman, Mario Invernizzi and Steven van der Kroft lead the session.

The location was the Radisson Blu near Schiphol, a fine location with excellent service and food & drinks. After we had those, the session started at 1 PM



Silver Fabric is a middle layer between the OS and application. It sits right in between, so it can allow for upgrades, scale up or down, and failover and failback - without human intervention (hold your horses please)

The man in the middle is the Silver Fabric Broker - you'd usually have one of these per environment, seconded by an identical copy of course, and it's the central agent - an environment would typically be the development environment, test, UAT, production.

Whether your machine park consists of physical or vertical machines, it's divided into Engines - rule of thumb is one Engine per core



Each Engine has a Daemon to it. The Daemon controls deployment and operation of Components such as e.g. a service or web application, which is always wrapped inside an Enabler. There are different kinds of Enablers, such as a Tomcat one for J2EE, a Command Line one for starting components from script, and additional ones are available from TIBCO, or you can create them yourself.

The Components that run inside an Enabler can be created with a wizard, that will guide you through the setup steps of assigning it a name, Features and Options



Features are optional behaviors such as capturing, logging, and start condition checks / schedules, Component Options e.g. are the maximum activation and deactivation time, activation delay time. Components can have dependencies on other Components, e.g. when component A depends on B, A doesn't get started (or remains active) unless B is running. This dependency also enables inheritance of runtime context variables from B to A

Allocation constraints can be set that limit the number of CPU's or Engines that can deploy and run a Component (group) - think of licenses per core or CPU that you want to respect. Runtime variables are set per Enabler, and inherited by the Component(s); typically these are paths, URLs, ports, etc



After you've edited a Component, its status will change. There's a very neat option that lets you Compare with Published so you can simply edit (for instance, upgrade) a running Component, use that option to see what's different, and Publish Changes or Cancel Changes to move the new Component into production. Of course you'd have to restart that particular component within the Engine before the changes become effective



As a Component is a relatively simple (albeit highly extensible and configurable) reflection of an application, Components can be grouped into Stacks. Those stacks can be subjected to allocation policies and visibility, all serving one and the same user, account and / or role.

Even Schedules can be set to policies, allowing for different sets of allocation policies based on time, day or date



The most important part of policies are Rules. They can adjust Component allocation levels based on e.g. load, dependance, and pretty much any other condition. There are Resource Preferences, Component Dependencies, Enablement Conditions, Threshold Activation, and Engine Group Rules give you control over e.g. OS and memory. Want to run on at least 4GB? Or maybe maximum 3GB? The preferences can vary from required to prohibited.

Component Dependencies allow to set shutdown preferences, enforce other Components to run on the same host, etc. Enablement Conditions enable you to make the depend the running of some Component on a condition, such as statistic values from other Components  or an external condition - you can set a sampling window during which these are evaluated. Another way to trigger on- or offload of Components is Threshold activation. Total CPU greater than 80% for 2 minutes? Automatically add an Engine. Last but not least, Engine Group Rules allow you to set minimum and maximum instances for Components running on a specific subset of Engines



Once every minute, the Silver fabric Broker will evaluate all Engine allocation and Component Enablement, and decide whether to add or remove either one - or leave everything just as is



The beauty of this all is the fact that it can "slip and slide" anywhere you want. The Silver Fabric is the middle layer on which everything rests. Engines can run on the same physical or virtual machine, location or more: you could scale within an entire datacentre or even across datacentres.

Imagine running this in the Cloud? Yes that would mean it's not vanilla out-of-the-box Cloud, but why should it be? What if Silver Fabric were a new Cloud OS, on which you can land anything, seamlessly upgrade, scale up and down across the entire world or just within a single rack?

I'm not knee-deep into PaaS, but this seems to me like it is. This is proven technology used for tens of thousand of servers, in financial industries, where time-critical (and extreme customisation) is spelled in capitals.

With Silver Fabric you can choose the bandwidth for anything: hardware, software, CPU, core, memory, location, use, processes, processing power - and it all is automatically provisioned after that. Want to take that a step further? Word on the streets has it, that it can also claim processing power from virtualised desktops running in the same cloud; using the same system of surgical precision that allows for any variable to enter the equation. Utility computing for real, but all within your so very strict control



With TIBCO Silver Fabric, you virtualise at the application level, not infrastructure. Hostnames, IP's, URL's, even security certificates are made entirely transparent. It will do to your applications what shared memory did to databases: make them fly

---

I forgot to include what struck me most during the workshop: I see great potential for version management, license management and environment management (want to switch on the entire TEST environment? It takes roughly 10 minutes to deploy a new set of applications on Amazon, as the workshop showed). Switch it off if you don't need it? Why not? Imagine the savings...

Silver Fabric also holds the records for every single version of every single piece of software in use. The license negotiations will get a whole lot less tougher on the buy side, and the sell side will see a steep drop in shelfware - maybe that word will even take on a whole new meaning.
What I particularly loved is being able to fixate and pin down "applications" to physical locations: legal requirements might force you to keep your apps and / or data within your own country or continent so there's an extremely strong business case here to go Cloud.
Last and absolutely not least is the huge potential for data centre migrations. I once plead for a "no man's land" Cloud to save us all the burden and cost of moving hardware from one location to the other when e.g. your outsourcing contract changes - these operations take years and tens of millions if not more. With Silver Fabric, you could do that in less than a day