Don’t forget the network….!

When I speak about the necessity to embrace engineering practices in complex IT programs, I am dead serious. Not so long ago I was trying to convince a group of executives in Amsterdam of the business case for including performance and availability engineering practices in cloud migration programs. I told them that nowadays every application that is migrated to the cloud is expected to be fast and always on. I explained to them that this does not come for free but has to be embedded in the application and infrastructure design. I wasn’t believed. They told me that there is no business case for performance and availability engineering in our small country; nobody wants to pay for it!

Shortly after this incident I was contacted by two architects who were working on a high profile cloud migration program for a client with head quarters in The Netherlands. I dialed in in the conference call with them and the conversation went roughly as follows : “Have you heard about the cloud migration program that we are doing for customer X?” “Yes I have. What about it?” “Well, we have been working on it for a couple of months now and we just found out…I mean we are a bit worried… the network bandwidth does not seem to be sufficient. Do you have a simple network model that we could use to calculate the transaction performance over the network?” “I may have something, but without any insight into the technical architecture I cannot guarantee that that is going to help you. What network bandwidth seems to be insufficient and when? Are problems expected during migration or after? And why does this come up so late in the program?”

The conversation ended with me sending them a performance handbook and some simple network performance models that we had harvested from a performance improvement program at a client in the oil and gas sector. The next time I heard from them was yesterday.

They told me that the high profile cloud migration program had stopped. One of the reasons to stop the program was the fact that the model showed that after migration of the applications to the cloud the transaction response times from several user locations were going to be unacceptable due to the low network bandwidth between these user locations and the cloud. That was an expensive finding! Several months of migration preparations lost and no prospect of any rapid remediation or move to the cloud! 

This was not the only reason for putting the program on hold; it was one of the reasons. But this could have been prevented if performance engineering practices had been applied in the early stages of program shaping!

The client in the oil and gas sector had a similar and yet different problem. In their case it wasn’t the network bandwidth that caused troubles, but the network latency. For them we developed an approach based on location differentiation. For remote locations with high latency or low bandwidth connectivity, we proposed different design patterns than for locations with low latency and high bandwidth. We educated project teams to recognize the different location types and to profile transactions with special focus on performance across the wide area network. We removed chatty interactions from application transactions. We introduced the use of network simulation tooling for test purposes. This approach did work very well and I see no reason why it couldn’t work in the cloud era.

This brings me back to my previous plea for embedding proven engineering practices into Agile, DevOps and Cloud migration methods. Time and again we see failing programs because insufficient information has been gathered and insufficient analysis has been carried out; issues that would not have arisen if proven engineering practices had been applied.