Scaling the hybrid cloud horizontally

After being derided as “unpure” by cloud enthusiast when the idea was first presented, we can now safely say that the hybrid cloud is here to stay. The mix of dynamic requirements within the enterprise related to government/industry regulations, security and performance require a more flexible environment than the public cloud can offer. So what does a hybrid cloud actually mean? A hybrid cloud is a composition of a private cloud and public cloud. There are two types of scaling patterns when using a hybrid cloud: vertical and horizontal.

A vertical scaling pattern is the better-known scenario. This pattern spreads different components of one application across different clouds. An example of this would be where one part of an application, typically the data, is kept private, while another part is run in the cloud, such as the web front end or calculations being made on the data.

A horizontal hybrid cloud scaling pattern, on the other hand, spreads different instances of applications across different clouds. In this scenario, enterprises develop their own applications and run them in multiple environments, some on-prem, some in the cloud. Developers run it in a test environment, testers test it in a QA environment, and users access the version that has been deployed to the production environment. Each of these environments can be in the cloud or on-prem depending on the security, performance, flexibility and scalability requirements of that environment.
read more

Continuous deployment with Atlassian Bamboo and XebiaLabs Deployit

Over the past five to ten years, continuous integration has become a no-brainer for every medium to large scale software development project. It’s hard to imagine going back to not having every commit (or push) automatically trigger a build of the code and, most importantly, a test run of of the code. That test run will surely include unit tests, but setting it up to also run integration tests used to be harder. You’ll need to automatically deploy the application to the target middleware environment and then run the integration tests against that environment.

The Deployit plugin for the new 3.3 release of Atlassian Bamboo adds the enterprise-scale deployment capabilities of XebiaLabs Deployit to Bamboo. This allows you to speed up your development process by adding automated deployment to your continuous integration setup and make the the first step towards continuous deployment and continuous delivery. Instead of deployment being a bottleneck to your development process, it will be be an integrated part of it. You can test your application on the target platform as soon as possible, find any platform incompatibility and deployment issues early on, and, when it’s time to deploy to the production environment, your deployment will be quick and reliable.

read more

Leveraging the IBM Workload Deployer CLI to automate WebSphere application deployment

A few months ago I blogged about the integration between Deployit and IBM WebSphere CloudBurst (since renamed to IBM Workload Deployer). While that article gave an overview of the integration and included some nice screenshots, it did not really go into the details. Now is the time to explore the implementation of this integration..

Workload Deployer V3 and Deployit from XebiaLabs both “deploy” things, but they deploy different things. Deployit deploys application artifacts and resources, such as EAR files and data sources, to middleware systems like IBM WebSphere Application Server (but also HTML to web servers, IBM WebSphere MQ configurations to queue managers, and so on). IBM Workload Deployer, on the other hand, deploys patterns (or topologies) of virtual images to hypervisors — but not just any kind of virtual images. IBM Workload Deployer is especially geared toward deploying middleware topologies.

IBM Workload Deployer V3 is an updated and enhanced version of the WebSphere CloudBurst Appliance, renamed to reflect the expanded scope of workloads it can deploy, which are no longer limited to only WebSphere workloads. The content for this article (including screen captures) was created using a WebSphere CloudBurst Appliance, but everything noted here is equally applicable to IBM Workload Deployer V3. However, for the sake of consistency with the images presented, “WebSphere CloudBurst” is used throughout this article to refer to both products.

In other words, IBM Workload Deployer deploys the middleware systems and Deployit deploys applications to those middleware systems — complementary functionalities that form a perfect fit.

At XebiaLabs, we have been working on two exciting new integrations for Deployit. We created a Deployit plugin that enables you to deploy EAR files directly to virtual systems created by IBM Workload Deployer V3 or its predecessor, IBM WebSphere CloudBurst Appliance V2. We also created a WebSphere CloudBurst script package to deploy application artifacts and resources on newly created virtual systems.

This article explores two integrations between WebSphere CloudBurst and Deployit as a way of showing how you can leverage the WebSphere CloudBurst command line interface and script packages to integrate cloud deployment with your application deployment automation solution.


Deployit integrated with DPAdmin for heterogeneous deployments to IBM DataPower appliances

In a previous blog I talked about the integration we’ve achieved between XebiaLabs’ Deployit and IBM’s Workload Deployer (still called WebSphere CloudBurst Appliance at the time) to allow users to deploy Java EE packages straight to a private cloud environment managed by IBM Workload Deployer. An IBM developerWorks article with more details is in the publishing queue. When it’s been published, I’ll post a link here. In this blog, I’d like to discuss another integration we’ve been working on.

IBM’s WebSphere DataPower appliances are a family of appliances that provide valuable services for SOA architectures such as XML acceleration (XA35), XML security (XS40) and data integration/ESB (XI50 ). While the DataPower appliances provide a powerful web-based management GUI, they are not easy to automate. The only command line available is an interactive command line that requires you to telnet into the appliance and the other way to automate the system is a SOAP/XML based API that requires quite a lot of coding.


Deployit integrated with WebSphere CloudBurst Appliance for applications on demand

At XebiaLabs, we have recently been working on an exciting new integration for Deployit, our deployment automation product. We’ve created a Deployit plugin that allows you to deploy EAR files directly to virtual systems created by IBM’s WebSphere CloudBurst Appliance (WCA).

But a small piece of background first. Deployit and WebSphere CloudBurst Appliance both “deploy” things. But they deploy different things. Deployit deploys application artifacts and resources such as EAR files and data sources to middleware systems like WebSphere Application Server (but also HTML to web servers, MQ configuration to queue managers, etc.). The WebSphere CloudBurst Appliance on the other hand, deploys patterns (topologies) of virtual images to hypervisors. But not just any kind of virtual images. It is especially geared towards deploying middleware topologies. In other words, the software Deployit wants to deploy to! This means that the functionalities of WCA and Deployit are a perfect fit; have WCA deploy the middleware systems and have Deployit deploy applications to those middleware systems.

Deployment automation vs. server provisioning

In my two previous blogs I compared deployment automation to build automation and release management automation respectively. Build automation tools automate the building of software while deployment automation focuses on deploying the software after it has been built. In the other blog I explained that release management tools manage the release process of software but don’t do the actual work. In this blog I will compare deployment automation to server provisioning automation and here the distinction is harder to make. So please bear with me!

Let’s start by defining server provisioning. We can look at the ubiquitous Wikipedia definition or at the one from wordIQ. They tell a similar story; Server provisioning is about making a server ready for service. It usually involves activities such as:

Deployment automation vs. release management automation

In a previous blog, I compared deployment automation to build automation. I wrote about the differences between the build and the deployment process and I explained why different features are required from the respective automation tools. In this blog I will explain the difference between release management and deployment and why release management tools that claim they do deployment automation are actually doing something different. And why that is a good thing. 🙂

Let’s start by defining release management. While Wikipedia might define release management as a relatively new discipline in the application lifecycle management space, it has actually been a part of ITIL v2 since its release in 2000. It concerns itself with the management of software releases. Courtesy of the ITIL Open Guide, the key activities of release management are:


Deployment automation vs. build automation

Since make was introduced in 1977 to automatically build software, more areas of the software construction and release process have been automated. In fact, anybody building serious software without automating their builds, their tests and without using continuous integration is not considered to be a professional. A hot topic within the application lifecycle management (ALM) space is deployment automation. This is driven by middleware environments getting bigger and more complex, by the increasing number of application releases demanded by modern businesses, and by the fact that application deployment needs to happen reliably to not disrupt online services and businesses. Add to that the fact that cloud infrastructure is becoming more mainstream by the day, you can bet there is a lot happening in this space.

At XebiaLabs we have developed Deployit and that has given us a lot of insight into the deployment automation domain. This is the first blog in a series that will explore that domain by comparing deployment automation with a number of related topics.


Implementing Deployit, part 1: organizational aspects

Last month XebiaLabs released the Personal Edition of Deployit. Now that people have been able to experience in a simple environment how Deployit can work for them, you might wonder how to start using Deployit for real in your development and operations environments. In this blog and its sequel we will go over the things we’ve learned when starting to use Deployit. We will also be covering this subject (and a lot of other subjects!) in our upcoming Deployit webinar series.

There are organizational and technical consequences to introducing a deployment automation product. But let’s focus on the organizational aspects first. These pointers will help you get started with implementing Deployit in your organization in the right way.
Read more →


We’ve already been talking about Deployit, XebiaLabs’ deployment automation product, for some time. Now we are proud to announce that you can try Deployit for yourself by downloading the Personal Edition of Deployit!

If you don’t know what Deployit is yet, have a look at the movie below!

To summarize; Deployit will automate your Java EE application deployments and, because of the overview it offers and the history it keeps, it also allows you to manage and optimize your deployments.
Read more →