March 5, 2015 | Written by: Thomas Andersen
Share this post:
Moving development to the cloud is similar to getting a new work location. The way you normally take to get to work has changed. You can still take the car, train, bike or whatever means of transportation you usually use, but you will drive a new route and encounter different traffic signs and stoplights, and maybe even one-way or dead-end roads.
The first few days you’ll likely experiment with different routes and possibly be frustrated at times, but eventually it will be as routine to get to and from work as it was before.
I have been doing development support for the past 19 years or so, with only three of them focused on cloud. Naturally, I still tend to look at the cloud with a support perspective. I have noticed a repeating pattern where development projects are moved to or integrated with the cloud and something goes wrong, causing the people running the projects to get a negative first impression of working with cloud. We all know that first impressions last, so let’s try to avoid a negative one.
The development you are doing today is likely done on your company’s own network, which is probably configured to allow most traffic from inside your company.
When you begin to move development to the cloud, you actually change the location where some or all of your work is done. While you might be in the same, and hopefully comfy, chair as before, the data that is part of your development is taking a new route in order to accomplish its task.
The new route the data is taking will most likely encounter different firewalls than before, and there might be other restrictions on which way the data can move. There could even be dead ends requiring changes to the setup of the development environment or the code being executed at the time.
Such changes in the infrastructure, if not anticipated prior to the move, will not make anyone happy. Here are a few ways people might become upset:
• The customer may become upset that their application is delayed
• The project manager may become upset because the customer is blaming them for the delay
• The developer may be upset because he or she has to solve this and has not been included in the planning (and the coffee is cold!)
My point is that when planning the move to cloud, the following issues should be considered:
• Which network ports need to be open in order to be able to develop?
• Will the security team allow for the required ports to be open in the firewall?
• Which way do we send or request data (network zones)?
These questions might seem pretty trivial, but they are very important if you are to ensure a successful move to the cloud, as they can help determine which workloads you can place on the cloud and where. They can also help determine which parts of the development might not be suited for cloud yet.
In an ideal world, this information would be documented, but I find that the developers—no offense, I’ve been one myself—prefer to write the code and not so much the documentation explaining exactly what the code does and why it was done this way. They often write it afterwards and forget to include the obvious (at least, obvious to them). As such, in the real world not everything is documented as well as it should be, and the developers probably have knowledge of the project that could be important to know before moving to cloud.
This is why I think that developers should always be included when planning to move development to the cloud. Do you agree?
Feel free to post here or catch me on Twitter @CloudyTHA.