Posted by Vincent Partington in the early evening: July 6th, 2011
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.
Posted by Mark Bakker at around evening time: June 22nd, 2011
In my current position as Performance Engineer and in my past position as a Middleware Architect I did quite some work with closed source performance monitoring and analysis tools (i.g. CA Wily and later AppDynamics).
These tools are both expensive but also do quite a good job most of the times. In the same field there are more tools, but all in the same price range for as far as I know.
To name some: Foglight, Dynatrace, Newrelic, JXInsight, Tivoli Performance Viewer, Compuware Gomez.
Around 2006 several initiatives to create open source performance monitoring tools for java production environments started to appear.
This was mainly because AOP (Aspect Oriented Programming), the technology used in most of these products, was getting attention in the market and there were quite some developments in that area at the time.
I am interested to see how the open source community around these kind of products is evolving. The outcome is quite surprising…
Posted by Andrew Phillips late at night: June 16th, 2011
Earlier this year, I was invited to present a talk at Devopsdays Boston about deployment as the new build: how deployments are carried out now, how they will need to adapt in a more virtualized, on-demand application landscape and what fundamental improvements will need to come before deployment matures into the invisible, it just works™ experience build is today.
In the previous post, we looked at how Reusable commands, Models and Conventions++ helped turn build from a “black box” process into the “just works” experience we know today.
We then shifted back to deployment and identified Develop a common model, (Re)discover vanilla and Support a “clean build” as three key steps required to achieve a similar transition.
(more…)
Posted by Andrew Phillips in the wee hours: May 21st, 2011
Earlier this year, I was invited to present a talk at Devopsdays Boston about deployment as the new build: how deployments are carried out now, how they will need to adapt in a more virtualized, on-demand application landscape and what fundamental improvements will need to come before deployment matures into the invisible, it just works™ experience build is today.
In the previous post, we compared deployment to another key process in the application lifecycle – build – and asked which key developments turned it from a magical “black box” into the “just works” process it is today.
We identified Reusable commands, Models and Conventions++ as three key steps, which we’ll look into in more detail in this post. Then, we’ll shift back to deployment and ask which improvements will be essential to getting to “just works” here.
(more…)
Posted by Vincent Partington mid-afternoon: May 8th, 2011
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.
(more…)
Posted by Andrew Phillips at around evening time: May 3rd, 2011
Earlier this year, I was invited to present a talk at Devopsdays Boston about deployment as the new build: how deployments are carried out now, how they will need to adapt in a more virtualized, on-demand application landscape and what fundamental improvements will need to come before deployment matures into the invisible, it just works™ experience build is today.
In this first post, we’ll focus on some of the changes and trends across the industry that have brought such increased business attention to the area of release, deployment and management of applications.
(more…)
Posted by Mark Bakker mid-afternoon: March 15th, 2011
Last week I got a presentation for a security device I had never heard about.
Most times this means it is something which is not commodity, or has no real use-case.
But this time I was really impressed. The device is a possible replacement for IBM Datapower XML Security Gateway. But the way they designed the device is totally different.
What CrossCheck networks did was creating a device with just security as main use case. First of all it was an XML gateway, nowadays is does support HTML, XML, SOAP, FTP, JMS and others.
It also translates different flavors of JMS to each other, it can even convert from IBM MQ to JBoss MQ directly.
Posted by Vincent Partington at around evening time: December 20th, 2010
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:
(more…)
Posted by Andrew Phillips late at night: December 8th, 2010
A couple of weeks ago, my ever-active colleagues Marco Mulder and Serge Beaumont organised an nlscrum meetup about “Combining Scrum and Operations”, with presentations by Jeroen Bekaert and devopsdays organiser Patrick Debois.
Unfortunately, I was late and only managed to catch the tail end of Patrick’s well-delivered talk explaining how Dev/ops can become Devops. Thankfully, the lively open space discussions that followed provided plenty of interesting insights, comments and general food for thought.
One recurring theme that particularly struck me was the comment, uttered with regret by many in Operations, that they would very much like to help and coordinate with the development teams but inevitably were always too busy keeping the production environment up and running.
In other words, helping prepare for new releases might be desirable, but achieving the five nines, or whatever SLA Operations has committed to1, will always be paramount.
This is a fallacy! Indeed, one of the core realisations of the “Devops mindset”, to me, is that 99.999…% uptime is not an end in itself, but a means to an end: delivering the greatest business value possible. And aiming for the highest possible availability may not be the best way to go about it!2
Posted by Vincent Partington in the early afternoon: November 25th, 2010
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: