Cloud computing is a relatively new term for what has been around for a decade – leveraging virtual environments within the firewall and beyond it. Many software engineering teams have been in the cloud since its inception and will likely be drivers for its adoption going forward.
HOW DID WE GET HERE?
Prior to virtual environments, the infrastructure to support development efforts was 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. Coupled with the expense of physical hardware for every required infrastructure environment, installing development tools and custom applications on workstations and servers often had a corrupting effect on those machines.
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. Because of the expense associated with physical infrastructures there were limited environments to promote code, and continuous integration wasn’t even a dream.
I was hired back again in 2005 for yet another next generation development effort. This time, the developer workstations were based off of a base VM. Getting up in running 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 ‘big four’ front runners are Google App Engine, Amazon Web Services (AWS), Force.com by SalesForce, and Microsoft’s Azure platform. These providers offer scalability for large volume web-based applications with built-in clustering and load balancing.
However, the big four aren’t inherently development environments with sophisticated processes for building and testing applications and maintaining source code control, build scripts, and other requirements of complex projects. For these types of projects, you would use Infrastructure as a Service (IaaS) providers. IaaS providers allow teams to customize virtual server and workstation configurations in a plug and play fashion that’s conducive to on-going development.
A complete cloud solution would be to combine an IaaS provider with one of the big four. The IaaS provider would be the infrastructure for the development and test environments. Releases would be published from the IaaS provider to one of the big four for your high traffic web app.
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 platform that does not provide support for the major languages. However, it’s a more rapid development environment than the others – somewhat like a 4 GL – and I anticipate that it 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 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.
Posts
No comments:
Post a Comment