Which Cloud is right for you?

Deciding which cloud is right for your software engineering team isn’t as difficult as you would think. The big players getting all the attention in the media today are Google, Amazon, Microsoft, and Force.com. For most software engineering teams, however, none of them is the best option from a development perspective.

The big four are geared more to production environments than development. Although most of them provide the ability to extend their environments through local IDEs like Visual Studio and Eclipse, that’s hardly enough for a development team. They don’t address things like integration, testing, and demo environments.

A good example of the inadequacy of the big four as software engineering environments is the fact that Amazon deletes VMs when they are shut down. That’s clearly indicative of a public facing focus where shutting down a VM equates with shutting the doors on a business. Thus, Amazon, as well as Google, Microsoft and Force.com, are not options when moving “development” to the cloud

A more appropriate approach for cloud development environments are Infrastructure as a Service (IaaS) providers geared specifically towards development teams. They are lesser known but I assure you they are out there.

Under this structure, environments can be spooled up on demand. Costs are controlled by having VMs running during working hours and shut off during off hours. In addition to conventional application development, teams need temporary plug and play VM infrastructures to be used for an finite period of time to develop POCs, demo systems, troubleshooting specific issues, and many other one-off situations.

My firm’s application support service offering is an ideal function that is conducive for IaaS providers. Our development team has 40 VMs consisting of various client applications and project infrastructures. Putting all of them in the cloud with the ability to start and shutdown on demand based on client requests provides our team with the ability to focus on our core competency (software development) and offload those functions that aren’t our core competency (infrastructure engineering and management) to cloud providers.

IaaS providers aren’t for everyone either. They are ideal for organizations with lots of infrastructure needs. They are typically not suitable for public facing production environments nor are they ideal of a single demo VM or similarly smaller infrastructure.

In general, here are the rules of thumb:

1. Big Four: If you have a public facing product with a high hit rate, then one of the big four providers is likely to be the right choice.
2. Infrastructure as a Service (IaaS):
1. If  you are a software development team with many sophisticated infrastructures to support many projects and would like to offload the infrastructure supporting the SDLC, then an IaaS provide is the right choice.
2. If you are a startup product company and do not want to invest in infrastructure engineering resources, then an IaaS provider is worth considering.
3. Internal Resources: If you are a small application development team with few environments, your internal resources or that of your consulting vendor will be the most efficient solution.

Evolution of Software Development and Cloud Computing

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.