The unexpected reality of deployment

This is an archive of blog post I wrote during my second venture (Sybil).

The task🔗

Three months ago, another company interested in Sybil accepted to be a pilot. Very quickly, the question of installation came, and we had to plan it. First of all, we met with the company again in order to learn about their technical environment. We had even already tested some configurations in the application itself, such as the connection to the repository. We decided with the customer that the best option was to provide them a full VM, to be independent of any local circumstances. As first list of constraints, we had then:

  • no access from outside, even through aVPN,
  • the deployment of Sybil made thanks to a VM,
  • an old server with Microsoft Windows 2003 as host for the VM, and
  • a machine with access to this server.

We then planned a visit to really install Sybil.

The run🔗

On paper, the VM was ready. I was confident, but from my experience I knew that everything could happen. Indeed, our first knowledge of the technical environment was incomplete as we discovered when installing Sybil.

First of all, we tested the VM on my laptop. We bumped into several problems due to the fact that Internet access was only possible through a proxy. We asked the necessary information to use the proxy and we quickly adapted, well to be correct Martin hacked the application to play with the proxy. We ran the first analysis. We then met other minor problems, we investigated and fixed them. After about 1 hour, we collected a list of bugs and other issues allowing us to go further.

A this point, the VM was ready to be deployed. I needed to copy the VM on the server. That took me a zillion of seconds. Yes, the LAN wasn't a top notch one. After 30 minutes of data transfer, we installed Virtual Box, configured the network and the port forwarding, and ran the VM.

We then checked the application. Everything seemed ok. We reset the data and ran the indexing and analyses. We waited a few minutes to check if everything seemed ok. During this time we showed how to access the application and how to use it. At the end, we left the office after 2 hours and half.

A priori information are never complete🔗

It wasn't so easy even if we had the hand on the VM. At the end, the technical environment wasn't the one expected according our first visit. Indeed, we discovered the following other constraints during the installation:

  • access to Internet only through a secured proxy,
  • access to the server only thanks to Remote Desktop,
  • data transfer to the server through a shared network drive, and
  • a very low LAN bandwidth.

We expected some problems with the deployment into a customer infrastructure, but we were anyway surprised by the nature of them. Even if we prepared the installation with a previous meeting, we only got the details that our contact knew about. It is simply due to the fact that the person didn't know our application, so he couldn't figure out exactly which details we needed.

You can always argue that we knew and we couldn't ask correct question. But an application is developed in a controlled environment. It's not put in a situation that allows to learn what are its exacts requirements. Yes, we knew it in someway, but it was not enough explicit in our mind, not enough to be communicated to our contact when we needed the details about the infrastructure. This is simply due that a today application involves a lot of implicit requirements. No amount of preparation can make it appear out of nowhere.

Reality is an opportunity to improve🔗

From my point of view, it's not a fatality, it's reality. It's an opportunity to build a rigorous approach to deploy our application and control all its requirements. I can also develop a better understanding of what I need to take care of. If I take care, I can improve the application but also my development. As system administrator, I always try to replicate the kind of environments I've met in order to test the deployment and the integration of the application. It allows to underline the weaknesses in the application, especially the ones built on top of strong assumptions. I can then make it workable, probably the most important for us.

Where your application really exists🔗

English: a human brain in a jar

Beyond those considerations, what I think is interesting is that the development of an application it's not just developing it, but also running it in an environment. Even if I can control it, there will always be some parts, for instance an user directory, beyond my control. Those parts will be in someone else's hands. With or without their help, I'll need to find a way to run the application in their environment, not in my warm and comfy development one. The production is the only place where the application really exists.

That's why I think it's so important to build load tests, and to mimic production environment, based on my assumptions, but also my learning when deploying and running the application in production. It's different, it has to be managed differently.

For the final words, it makes me think to my analogy of the architect and general contractors. The application is built and run. The reality in my mind is not the real one.

If you have any comment, question, or feedback, please share them with me.

Atom feed icon Subscribe to the blog!