Below is an extensive list of the fixes that have gone in the last beta and this first release candidate. Changes are group by whether they are in the ControlTier project or and the underlying AntDepo framework (with tracker ID, if available):

Monday, October 01, 2007

ControlTier 3.1-beta-1 has bug fixes and performance enhancements throughout Antdepo and Workbench. But the biggest thing included in this release is the new Job Center application.

Job Center

Job Center is a web interface for creating, scheduling and managing jobs executed in the Antdepo environment. It is still in Alpha form (0.4-alpha), so the interface may eventually be different and bugs may pop up.

Features include:

Jobs can either be transient (one-off), stored for on-demand execution, or scheduled to run periodically.

Job execution progress can be followed live on the web

Browse, filter and customize reports of previously executed jobs

Easy access to all Jobs that are Now Running, or have recently finished executing.

Intuitive interface.

Technical Notes

Job Center development required converting the Antdepo Framework concept into an embeddable application. Since Antdepo executes in the Ant environment, this posed some problems because Ant was not necessarily designed to be embedded within another application. Until now, Antdepo has not had to address this problem because the Antdepo context is necessarily single-user and short-lived when running as a command line application. Converting this method of operation into a multi-user, long-lived web server process paradigm required getting over some hurdles in both the Ant and Antdepo frameworks.

One problem brought up by Ant was that of output on STDOUT and STDERR. For example, when a command is dispatched to a remote Node, an Ant SSHExec task is created to handle the SSH connection to a node and execution of a remote Antdepo command. The SSHExec task in Ant prints its output to STDOUT and STDERR. With the command-line "ad" command this is not a problem. However in Job Center the output of the command has to be captured by the executing thread in order to make it visible for the user. In addition, multiple commands may be running simultaneously in several Java Threads, and if multiple commands are executing SSHExec tasks then all of the output will end up on the output console and not in the command log where we want it to go.

The solution to this problem is to use a custom replacement for the Java System's standard-output and standard-error PrintStream objects. By using the special InheritableThreadLocal class, the STDOUT and STDERR can be replaced by a custom OutputStream for each command Thread. The OutputStream is then inherited by any child Threads spawned by the command thread. This is necessary because SSHExec specifically uses another Thread while it is executed, and other tasks may do the same thing. This custom OutputStream logs the execution output to a file for use by Job Center to view the command output. After execution, the InheritableThreadLocal is cleared of the custom OutputStream for the Thread.

Sunday, September 23, 2007

Simply put, it's about giving customers freedom and helping them better align their IT costs with their business.

More specifically*:

1. Open source platforms can be leveraged to a far greater benefitIf you look across the software industry for past 5 or so years, you'll see that the new platforms that have been widely adopted are all open source platforms. This success has more to do with freedom then with a license price.

The success of any technical platform depends on a user's willingness to invest in the skills needed to leverage that platform to its fullest extent. The only way developers (and in turn, a development organization) will get the maximum return on that investment is if they are acquiring an open and transferable skill.

Users must be free to reuse the platform and their skills anywhere and anyhow they see fit. Any license or monetary barrier that stops reuse diminishes the value of the platform.

With ControlTier, you can be assured that any effort put into learning or using the platform can be reused and leveraged across your organization however you see fit.

2. Open source licenses don't restrict your businessThere are different ways that traditional closed-source license schemes measure deployment and use. However, they all have one thing in common, the more you use the more you pay. This business model ends up imposing an artificial "tax" (mental and monetary) on your business operations.

In the changing world of online services, you must be able to scale your environment in any direction you wish. Constraints on where you can deploy licensed software only interfere with your business. As architectures become even more service oriented, the physical infrastructure is shared across multiple services and business applications. Aligning those infrastructure costs to any particular business function becomes very difficult in these new architectures.

If you want to move to a larger number of commodity servers, you shouldn't have to pay more. If you want to open another disaster recovery center, you shouldn't have to pay more. If you want to broaden the use of the software to include other employees, you shouldn't have to pay more. You should be free to change the scope and shape of your physical environment or operations in any way you see fit and not be penalized for it.

Another way that closed-source licensing restricts your business is by forcing upgrade cycles upon you. Updates or fixes are limited to what the vendor wants to give you. Upgrades or new versions generally only come after additional negotiation and you are forced to accept a bulk of features that you may not want or need.

With ControlTier, you are free to distribute or use our software in any way you wish. You are also free to modify our software in any way you like, so long as you honor the spirit of the open source license. The fact that we aren't selling upgrades avoids feature bloat and encourages you can accept or make updates on your own schedule.

ControlTier also has a strong aversion to the "per box tax" when it comes to our support and implementation services. To us, we are being paid to help you design and deploy automation for a particular business application, process, or stack. The complexity of the automation and the level of support we provide is what determines our compensation, not where the automation is installed or how many users or machines rely on it. This makes it easier for our customer to directly align their costs with particular business applications or services.

3. Open Source ensures that ControlTier's business goals and our customers' business goals are alignedOpen source licensing combined with a services and support-based business model ensures that our goals are aligned with our customer's goals. At ControlTier we earn our revenue by providing direct value to our customers. This is quite different from traditional closed-source business models where customers pay a large fee upfront and then significant annual fees for the promise of value being delivered in the future. For those vendors the biggest incentive is on selling you more promises, not on deliver on those promises.

Under our model we have to prove direct and measurable value for each dollar a customer spends with us. If we don't prove that we can get the implementation done with the highest quality and lowest price point, you are free to go elsewhere (most likely in-house). If our support services don't deliver on their value, you are free to drop them. Our model keeps us on our toes and forces us to find new ways to help you make more money. To us, that seems to be a better deal for everyone.

*Note: You'll probably notice that license cost isn't on this list. Of course, getting something with significant commercial value for free is a nice thing, but that really doesn't tell the whole story as to why the Open Source model is a vastly superior one for enterprise customers. Additionally, no matter what a vendor charges for a closed source license, that dollar amount is trivial compared to how the freedom of true open source software changes the overall economics and manageability of a customer's business.

The word manifesto may be a bit too overloaded, but we've always hated the meaningless content of corporate mission statements. So here it is:

The ControlTier Manifesto

Who we are...

1. We are a unique combination of development and operational experts that have lived in each others' shoes. With a deep understanding of each others problems and requirements, we have set out to streamline and automate operations across development, QA, and production environments.

2. We are developers and administrators who are determined to provide services that give our customers a competitive advantage by enabling them to achieve operational excellence and improved margins.

What we do...

1. We are our customers automation partners. We act as their independent agents of change focused on improving the efficiency of the application lifecycle through streamlined processes and extensive automation. We don't just provide the missing tools, we provide the expertise and accumulated best practices needed to successfully implement the tools and bridge the gaps between the various groups involved with the application lifecycle.

2. We develop and implement model-driven toolchains that automate build, deployment, configuration, and management activities. These toolchains implement an enterprise's specific processes, are reusable across all environments, are built to be flexible and extensible, and are built on open source tools and frameworks.

Further, we believe...

1. Build, deployment, and configuration activity happens all across the application lifecycle and impacts Development, QA, and Operations budgets. Too many talented and expensive technical resources, in every group, are being consumed by these non-value adding activities.

2. While acknowledging that writing source code has some elements of an artistic endeavor, the rest of the application lifecycle is a strict engineering endeavor and must be be expected to have the same level of widespread reliable automation and visibility that is found in traditional manufacturing operations.

3. The point of companies that operate software as a revenue producing service is to operate software as a revenue producing service. It is pointless for all software not to be "operations-ready" from the moment it is checked-in by developers. To enable operational readiness, all Development, QA, and Operations groups must be linked by a common automated build deployment framework.

3. All automation must pass the "two toss" test: If you throw any machine out of a window, can you automatically and instantly rebuild your service to a properly working state? If you toss any developer or admin out of a window, does your ability to deploy and maintain your service remain intact?

4. In order to be successfully adopted, automation frameworks must be available under a free Open Source license. Developers want open, transferrable skills to which they are free to apply in any manner, form, or frequency they see fit. Enterprises should be free to utilize, modify, or extend their automation (and its underlying framework) in any manner, form, or frequency they see fit. Traditional closed source licensing only places an unnecessary and burdensome "tax" on both individuals within the enterprise and the enterprise itself.