Cloud computing is a relatively new term for what has been around for a decade – leveraging virtual environments within the firewall and beyond it. For many software engineering teams, we’ve been in the cloud since its inception and will likely be drivers for it’s adoption going forward.
HOW DID WE GET HERE?
Previous to virtual environments, the infrastructure to support development efforts were physical. Thus, software engineers had their development tools loaded on their respective workstations and integration, test and production environments were made up of servers on the network. Thus, for every new infrastructure came the procurement of hardware. Not to mention how much of a corrupting affect development tools and projects have on a developer’s workstation.
If you subscribe to the definition of a cloud environment as being any that is virtual – even those behind the firewall – then the first iteration of a private cloud for software development came with the emergence of using virtual environments for development workstations. This had a mammoth effect on development efficiencies and IT governance.
As an example, in 2001, I was hired as a consultant to help a client develop the next generation of their commercial e-Discovery product. The suite of applications were complex with many moving parts and technologies. It took the average developer 1-2 weeks to get their development environment up and running. There were limited environments to promote code, and continuous integration wasn’t even a dream.
After about 9 months I left, as consultants often do, but by 2005 I was hired back again for yet another next generation development effort. This time, the developer workstations were based off of a base VM. Getting up in running as a developer took hours instead of weeks. The fact that developer tools were loaded on the VM instead of the host machine was a dramatic improvement for IT. At last, a software engineer’s machine was like everyone else's in the organization.
In addition to developer workstations, the integration and test environments were also virtualized. This allowed the release engineers to revert environments to their base snapshots in preparation for new releases. When we needed to branch testing, we would spool up another virtual environment. Our only limitation was the hardware on which those environments were deployed.
WHERE ARE WE GOING?
The last several years have seen virtual environments that exist beyond the firewall. The current front runners are Google App Engine, Amazon Web Services (AWS), Force.com by SalesForce and Microsoft’s Azure platform.
Consulting companies like mine that have an environment per client, and sometimes per client application, use up space on the network very quickly. Using cloud providers offers relief to the internal pressures related to providing developers with environments, storing them in various states of running, upgrading VM technologies, and expanding the network for the ever growing number of VMs.
Software Engineering teams interested in using cloud providers need to decide which flavor of Internet-based cloud infrastructure is appropriate for them; extending a developers workspace and “being” the developers workspace.
Each of the big four allow developers to use existing IDEs to extend their development environment. Here are the major IDEs and the providers support.
- Visual Studio: Azure
- Eclipse: Google App Engine, AWS, Force.com, Azure
- NetBeans: Google App Engine, AWS
Each of the big four support one or more programming languages. This list below is not comprehensive but provides the major languages:
- Azure: C#, Java, PHP, Python
- Google App Engine: Java, Python
- AWS: C++, C#, Java, Python
- Force.com: Active Script, Apex, Visual Force
As you can see above, which platform you choose is dependent on your internal expertise. Force.com is the only one that does not provide support for the major languages. However, after using it myself, it’s a more rapid development environment – somewhat like a 4 GL – than the others and will be a player for the long haul.
The appropriate infrastructure associated with the decision to move to a cloud provider is a decision to think through carefully. The various configurations are virtually (pun intended) unlimited, e.g. have the entirety of your virtual environments either behind or in front of the firewall, split environments between behind and in front of the firewall, and deciding which, if any, segments of the infrastructure are public.
The adoption of cloud providers is a non-trivial decision as is the design of the appropriate infrastructure. However, as a manager, software engineer, and consultant, the cloud is likely to be a catalyst for a trend that offers developers an opportunity to think more about development and less about infrastructure. Which is as it should be.