Miracles: An Epic of Transformation

copyright 2001, Rex Ballard

Taking the Virtual office Global

Even as a child, I had imagined a day when people could work from anywhere they wanted, and be part of a big team of people, all working together. Some might even stay home and work in a recliner chair, while others might actually like getting away from home. Others might just like the atmosphere of a bar, that served only coffee. It was like I was remembering the future.

Creating the 24 hour work-day

My experience on the IBM BTCIO project, with a team of 150 people collaborating from all over the United States and the United Kingdom, quickly led me to my next engagement. This time an IBM client, an Insurance company, wanted us to implement a Message Broker project with most of the labor for the team coming from India. We had set up a small team of about 30 people in Bangalore India to do the ESQL coding. A core team of about 10 people in the United States worked closely with the client, making sure that we captured the clients needs and requirements and communicated them to the team in India.

One important issue was connectivity. IBM had previously done Cobol projects connected to clients using 3270 terminal emulation, but this project had a significantly different bandwidth requirement. To test code on the client's environment, it was necessary to deploy the compiled broker code to the client's AIX system. These transfers were bursts of up to 4 megabytes of compiled broker code and objects. Attempting to send them via high-speed dedicated lines would have been too expensive. Since this team was working from an IBM office, they had access to the IBM network, which was very fast, but we needed a way to get from the IBM network to the client's network.

The client also had some security concerns. They didn't want administrators at IBM to be able to decode the traffic going through the IBM network. I pretty quickly found ways to put a couple of Linux servers into service, and soon we had IPSEC connections using the ssh stunnel utility. In addition, we have each member of the team help installing cygwin, effectively putting Linux on their Windows workstations. This made it possible for them securely generate their own private keys, transfer the public keys to the target servers, and this encrypted traffic was further encrypted using a second stunnel between the two Linux servers.

At first, we used the same remote access software that we used to connect Windows workstations to the IBM VPN to connect the client. The only problem was that every night, between 2 AM and 3 AM, the VPN servers were recycled, and someone had to manually reconnect the the networks. Eventually, this connection was replaced with a connection via IPSEC between a CISCO router at IBM and the Linux server at the client's site. The Linux server assured the client that only one "hole" was needed in their firewall, and that only specific servers were accessed through that gateway. This "reverse proxy" eventually became a critical element of the IBM security model.

Appearantly my work caught somebody's interest because after that engagement I was tapped to work on a government project. I can't say anything about that project, other than "It's classified". For personal reasons, I opted not to accept a permanent transfer to the government sector.

Clusters and Grids and Clouds, Oh my!