Why not build my own solution?
From ControlTier
First of all, the ControlTier system is more than just an automation framework. The knowledge and best practices that come as part of its infrastructure, built-in automation building blocks and workflows are what ultimately provide you with the biggest time, stability, and efficiency gains. But putting that aside for now, let's examine what it would take to duplicate the functionality ControlTier provides.
So what does it take to build a ControlTier-like system that is on the one hand, expressive enough for developers to declare and develop application control automation, yet on the other hand, be managed and operated by administrators who run complex large scale environments? What does it take to satisfy enterprise requirements like scale, rollback, access control, version control, notifications, centralized logging, and auditing/reporting? How do you build it so your automation can be maintained and extended in a collaborative, controlled, and highly visible manner?
The diagram below describes the requirements we have acknowledged after years of living and breathing these problems. It would be hard to imagine a truly effective enterprise-grade solution that ignores any of them.
Each shaded box represents a set of requirements and capability that must be satisfied by the solution. The table below describes why it is needed, what technologies that can be leveraged to satisfy it, and where the requirement is supported in ControlTier.
| What | Why | Leverages | ControlTier |
|---|---|---|---|
|
Repository |
To function as the central depot of all release artifacts, automation code, and deployment metadata. The repository should also a flexible organizational system, allowing users to accomodate new repository elements and utilize their own layout schemes. Because the repository elements must be accessible to different tools, the repository should be exposed via scriptable interfaces. While it is ideal that an organization standardize on a single release archive format, it is often impossible due to heterogeneous system and application platforms. Therefore, the system must allow for the description of packages, their dependencies, and their distribution and installation behavior be pluggable. |
Workbench | |
|
Visualization |
To graphically present the configuration and control model. Understanding an information model is often easier, if it can be visualized. Further, because environments may have many components with many inter-relationships, it should be possible to view subsets of the model and select categories of information to display. |
Workbench | |
|
Reporting |
To track and audit activity. Any change made to a model or command execution should be logged. Further, the event should be correlated to the greater app and environment context. |
||
|
Security |
To govern who can do what, where and when. Security should permeate through all aspects of the solution. This ranges from authentication and authorization, as well as, encryption, integrity and consistency. |
CTL, JobCenter and Workbench all
have configurable ACL. |
|
|
Model and Metadata |
To describe application resources, their environment, relations and procedures. A model of an application should reflect three rough aspects, abstract configuration of components (i.e., their logical structure), concrete deployment (i.e, how they fit in a physical environment), and control (how to configure and manage their runtime state). All models should be based on a generic metamodel from which users create higher level models based on their own types and usage constraints. Data from the model should also be accessible to external tools. The model store should also maintain revision history of the model and automation code. Any change made to the model should result in a new version of the model. Changes should be atomic and result in a model revision that can be rolled back. It should be possible to compare two revisions of a given model object. |
Workbench type.xml, project.xml, job.xml | |
|
Collaboration |
To provide synchronized access for multiple users to develop, manage and execute configuration and control models. This should include the ability for teams to work independently and pass modules between them. The tool should encourage and facilitate knowledge sharing, allowing users to describe key aspects of their management life cycle processes. This includes generatation of documentation from the Model and Metadata. |
WebDAV, Apache Forrest |
Workbench, ProjectBuilder, |
|
Config Generation |
To generate environment and release specific configuration files based on templatized configurations bound to model views. Instead of creating a variation of a config file due to environment or release differences, this strategy takes a file template that replaces hard coded settings that change over time with references to a configuration Model and Metadata view. |
CTL architecture Workbench | |
|
Automation Code Generation |
To generate templatized procedures bound to model views. Procedure declared in the control model should be made executable via generated code modules. The execution layer must provide a data binding capability that ties model references in the generated code to a view of the model. |
Jena, XSLT |
ProjectBuilder and Workbench |
|
Distributed Execution |
To provide centralized, coordinated sequencing and control of management tasks. Because application components are distributed across machines, remote execution of commands, coordinated by a higher level representation that understands dependency order, must be provided. To make a procedure usable in different environments, it must be abstracted from environment detail. Therefore, procedure should be generated by and bound to a model of the abstracted environment. Procedures should also be packaged in modules that can be plugged into a generic dispatching framework to separate interface from implementation. |
Ssh, HTTP (dispatch). Bean scripting framework, Ant |
|
|
Job Scheduler |
Allows web-based creation, scheduling and execution of key management tasks. Enables the self delegation of administrative and operational activity to less knowledgable staff or people in other groups, especially when self-service is a requirement. |
Jobcenter |
One last general requirement not mentioned in the table above is integration and interoperability with external tools and operating systems. The solution should be capable of running on a wide range of system platforms and complement existing toolsets.
After reflecting on this broad set of requirements, it becomes abundantly clear, to solve this problem there are a number of difficult implementation challenges and it is NOT a trivial development project. It's not unusual to hear about multi-year efforts that do not achieve the ultimate goal and have cost organizations thousands of hours of development only to end up with a home-grown solution with high maintenance costs.
A common response to these challenges is to build many disparate specialized tools to cope with each problem area (rather than a holistic solution). The greatest lesson we have learned is that these capabilities must seamlessly interoperate to achieve the maximum benefits in efficiency. Not doing so often results in special tools built and maintained by different groups, with a lot of elbow grease and email to make it all work.
| ||||||||||||||
