Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Virtual Panel: Adjusting to Development in the Cloud

Virtual Panel: Adjusting to Development in the Cloud

Developers are steadily building experience with an array of diverse cloud environments. How should developers change their thinking when working in the cloud? Are some clouds better than others for developers who are getting started? How can those who are not currently doing cloud development build skills in this area?

To answer these questions, InfoQ spoke with three thoughts leaders about the state of cloud development, recommended tools, and anti-patterns. Our panelists were:

  • Adron Hall, a polyglot coder and developer evangelist.
  • Magnus Mårtensson, a Microsoft MVP and Cloud Architect for Sweden-based consultancy Active Solution.
  • Andy Piper, a Developer Advocate for Cloud Foundry

InfoQ: Is the cloud developer’s toolbox much different than a “regular” developer’s toolbox? If so, what tools do you see cloud developers relying on that traditional web developers may not use?

Hall: First off I'll define what I think of when I hear the term "cloud developer". A cloud developer is someone responsible for coding solutions based on horizontally scaled, distributed, idempotent and asynchronous processing in conjunction with scalable, distributed, highly available and resilient storage.

With that defined, I say in answer to the question, absolutely. A regular developer is often building something on a traditional RDBMS data store, with a framework or other tooling stacked on top of that, with a vertical scaling limit. This isn't a bad way to develop, but it is extremely inefficient to build application and services this way for the cloud or any horizontally scaled environment. In addition vertical scaling provides a finite limitation on performance. Once the peak physical limit is reached, the developer is done, there is nowhere else to go to increase performance in any reasonable way.

A cloud developer builds application across a wide spectrum of resources, is often found breaking the divisions of functionality in an application apart into more specific services or modules. The cloud developer also generally needs to step into a more polyglot toolset, ranging from JavaScript to C# to Ruby to other languages. This is often done out of necessity but also in large part done to provide a match between the best tool for a specific job.

So in summary, yes, the cloud developers toolset is absolutely different.

Mårtensson: The Cloud Developer needs to arm himself with some different thinking than you would in non-Cloud Development. There are things you can very easily achieve when your deployment environment is a Cloud Platform compared to other hosting options. A good Cloud Platform offers a toolbox that is quite different from what you might be used to. It can contain 'infinite' storage spaces with automated backups, a built in cache function, a high powered Service Bus and much more.

To be fair you don't have to buy into Cloud Computing to 100% just to reach into this toolbox. It is completely OK to use only one service from a Cloud Platform like the Service Bus for instance, if that is your requirement. There are more 'tools' in the box that differ from any type of non-Cloud hosting such as rapid elasticity, built in fault tolerance and fail over and a completely measured service where you can optimize cost for exactly what you need at any given moment. These Cloud traits are often referred to as the NIST Cloud Computing definition. I believe they are very much tools a Cloud Developer needs to understand and learn to wield. Properly wielded they enable you to build solutions that were near to impossible, or at least very expensive, to build before. If these features are abused a Cloud Developer risks missing out of the promise of great power and may even risk building a more expensive solution. As always with great power comes great responsibility.

Finally if we're talking more traditional developer tools they are very much the same for Cloud Developers as they are for every other kind of developer. It's my experience though that a lot of gain can be made in the Cloud by using PowerShell with the Windows Azure Platform and also automate build and deployment scenarios. It is true that this would be the same for most hosting scenarios. It just feels like it comes very natural to an inherently distributed environment like the Cloud. My advice to any developer that wants to Cloud enable him- or herself is to learn and understand the powers of Cloud Computing. They are your new tools which will empower you as a developer to reach goals as a cloud developer that you had a hard time even envisioning before!

Piper: Great question, and one I'm thinking carefully about. Adron is absolutely right that one thing that the cloud brings is scale - whether that is in the sense of data (the amount arriving at once, or the amount being stored) and in terms of how you go about scaling apps on the cloud with multiple instances across geographic regions for availability, for example. That said, while the tools and technologies that have emerged (such as Riak and other distributed data stores) are built for this new era and "different tools in the box" to what were there before, I'm also inclined to think that one of the things that developers need to do with the new cloud platforms is forget their previous assumptions - think differently about how an app will be deployed.

One of the goals of building an operating system to support cloud applications is to provide a consistent experience for developers. We'd like to make it just as easy to write a simple web app in Ruby or node.js or whatever, and run it locally, run it on your own single server, or run it on a scalable elastic cloud environment. So we build an abstraction layer to hide away the differences between cloud infrastructure (AWS, OpenStack or whatever) and enable developers to deploy apps easily. This does mean that they have to be aware that they cannot depend on the location of their app, hard-coded IP addresses or other config are bad, and code should be written in a way that decouples it from data stores (which may change) where possible. So the thinking and architecture is different, but at least some of the tools and code can remain the same.

InfoQ: What IDEs do you find most cloud friendly? Anything that developers should add into them to "super charge" it for the cloud? Do you have an interest in cloud-based IDEs?

Piper: So personally I'm potentially biased (as an Eclipse Committer)! I really like Eclipse and I'm also a fan of IntelliJ and RubyMine. Most of the established IDEs have nice plugins now for interacting with cloud services, be that something as low level as an AWS Explorer or something which provides a smoother build/test/deploy experience like the Cloud Foundry Integration for Eclipse.

I've tried cloud-based IDEs and editors like Eclipse Orion and Cloud9 and they are very convenient. They are also rapidly evolving to take advantage of new web features, which is great to see.

Of course, it's probably ironic that my developer toolset is not IDE-centric at all. I spend most of my day in Sublime Text and at the command line, and I'm also a huge fan of Ubuntu's package management and the homebrew open source package manager for OS X :-)

Mårtensson: It was fun to listen read Andy's input because I have a similar background - only the opposite. I'm a Microsoft/C#/Windows Azure guy and that makes me very biased toward that IDE environment and development experience. The amount of effort Microsoft has put into Visual Studio recently to enable seamless Cloud Development experiences is unmatched anything I have ever seen in Visual Studio. They are really making a BIG effort here to support powerful and fast Cloud development. The Server Explorer in Visual Studio can reach into any Cloud account and interact with the services running there. You can manage them, monitor them and run things like IntelliTrace and performance monitoring in the Cloud. Then you download the result and analyze it inside Visual Studio. Naturally you can build and test any Cloud Application locally, including the very late addition of a non-admin mode Compute Emulator (the Express version). Then you push it to your Web Sites and Cloud Services in Windows Azure in a snap. What I am seeing in the Visual Studio IDE for Cloud Development (read: Windows Azure Development) is unparalleled by far in Visual Studio history! Drinking the Kool-Aid? Yup! In big gulps and enjoying it!

Hall: There's the obvious top pick of:  Cloud9IDE.

Beyond that though, in many situations these days it seems that an IDE just gets in the way. When one has to switch between various environments with tons of polyglot languages and tooling it is often easiest just to grab Sublime or something of that type and run with it.

In the heavy weight class there are IDEs like Visual Studio, Eclipse, IntelliJ, WebStorm and other application tools. These are all great and provide certain hooks into one or maybe a few languages to help in the daily operational coding efforts. But at the end of the day, the second a language comes up that is outside of the IDE that kind of ruins one's day.

On the flip side, if a team is able to stick specifically to a particular IDE, have it loaded on anything and everything that they're using to do dev against and it works with their preferred cloud, then Visual Studio and some of the other IDEs kind of stand out. A great example is AWS's .NET Plugin for Visual Studio. This specific plugin for Visual Studio is the only tooling integration I've seen that doesn't also tightly couple the developers to the actual cloud. It just dramatically simplifies deployment and viewing what is going on with the cloud services without needing to leave Visual Studio. For .NET developers that is huge, since they're often encouraged and used to staying inside of a single IDE during the course of development.

In most web dev and cloud environments though, you'll be pushing things and using tools like SSH. This is were Visual Studio and Windows in general is just a non-starter. The amount of time wasted to get Windows and Visual Studio to work with SSH and other Linux or related environments can be super frustrating. It's dramatically easier to grab a terminal, learn how to wield that terminal, SSH into those instances and actually go to work. Even when using Windows Azure, if you're not intending to host on Windows or use the proprietary hooks of Visual Studio into Azure, then toss the Windows based development tools and go with something form JetBrains running on Linux or OS-X. Get good at those tools and your development team will end up thanking you. The cloud after all came out of the Unix way and continues to evolve based on most of the ideals that have been in that part of the tech world for ages.

InfoQ: What are some anti-patterns for developers to avoid when building an application for cloud scale? How do cloud providers keep you from making those mistakes, or conversely, allow you to do bad things?

Hall: There are a number of huge traps that developers fall into working on cloud - distributed applications.

One of the biggest problems I've seen over and over is the tendency to build in a single data center (in the case of AWS, a region, etc). Building an app with the framework stack and all fail-over being limited to one data center tends to still cause a number of downtime scenarios such as the "East 1 AWS Failure", also nicknamed the Easter failure.

Another huge problem is that a lot of providers - ok, so maybe ALL the providers - still have tons of SPOFs (Single Points of Failure). Windows Azure broke the record for mass data center failure with their certificates problem a number of months ago. AWS has had failures because of single pieces of network equipment in data centers. Rackspace has also had similar issues and also encourages people to run in-rack equipment that creates more SPOFs on top of the other failures points that are already in place. The entire idea is to make cloud architecture resilient, and these situations turn that notion on its head.

From a purely developer point of view, the largest mistake that is easy to make is to simply build a traditionally vertical stack application directly onto compute and storage within the cloud. This is expensive and inefficient to utilize application built under traditional architectural guidelines in a cloud environment. Time and time again however, I've seen people re-implement a vertical designed application; SharePoint, WebSphere and others come to mind. They often have a single RDBMS, with a data layer on top, and a single or maybe a few application nodes on top with SPOF cache tiers.

Overall there are a ton of anti-patterns in the cloud and they're readily implemented by ops and dev all the time.

Mårtensson: A really common anti-pattern is to apply old thinking to a new paradigm. For instance authentication; "We want to enable our customers to use their existing Google, Yahoo!, Facebook and Microsoft account to authenticate with our service. And of course we also want the standard username/password login." Find the flaw! Basically they are saying they want to go through some lengths to be very hipster and then retract it by bringing their grandma to the party. Sure you can run and handle your own username/password authentication service if that is really something you want to focus your development and maintenance efforts on. But if you're going all the way with externalizing authentication from your application you have to take it all the way home by moving you own hosting of authentication service (a term often used is Security Token Service STS) separate from your application. In short your application should not concern itself with authentications. It should however have trusted Identity Providers that handle this separate concern for you. If you do not store passwords you don't have to have that responsibility at all. The initial statement is made from fear of losing customers because they don't offer the standard username/password option. This will only add to your work load and you will miss the benefit of externalizing authentication using a Cloud service. If you don't do the new pattern justice you will end up hurting your business more than just doing it completely wrong in the first place.

Piper: Well, this time going last it is really hard to add to the common anti-patterns that Adron and Magnus identify - I've seen all of those. There's a definite tendency to think in traditional terms and build for scale-up not scale-out. In that sense I'm always surprised when a developer "discovers" asynchronous messaging like RabbitMQ and in-memory data structure services like Redis and thinks - wow - this is *whole new way* of doing things. No, they really are not, these concepts have been around for a long while, and cloud platforms make idempotent, eventually consistent service patterns more important than ever.

In terms of how cloud providers help you to avoid mistakes - mine, Cloud Foundry, does its best to provide as much useful configuration information as part of the environment as possible, so you can code to values looked up from there rather than hard-coding ports, database settings etc. There's no stopping you from hard-coding things, but that has never really been a good idea!

InfoQ: Stephen O'Grady of Redmonk once said that "the most important feature of cloud computing: a low barrier to entry." Which clouds do you think have some of the easiest on ramps for developers? Who does a good job of not just getting developers signed up, but also showing them how to start deploying things? What barriers to entry remain for developers?

Mårtensson: In Sweden we say 'tala i egen sak' meaning you are voicing an opinion in things where you are clearly biased. Again, I am a .NET/Visual Studio/C# devout. And of course also toward the Windows Azure Cloud. Still - WOW! Without disclosing my age, I have a good decade+ in this game, and I have never seen anything like this, continuous fire hosing, come out from Microsoft. Perhaps coincidental that the Cloud in Microsoft flavor arrived to match the times? Perhaps just because it was the right thing to do? But I have never seen such a devotion to enable a technology shift before from Microsoft. And it's not only VB and C# .NET any more. Microsoft builds and maintains tooling and SDKs for a multitude of platforms and IDEs for Windows Azure today. PHP, Java, Node.js, Ruby, Python & Visual Studio, Eclipse & the ability to develop once and send messages to many different types of devices; iOS, Android, Windows Phone and Windows 8. Pick your poison! Which company is the biggest open source contributor to Linux today? Yeah that's right, but who would have known? For those who have followed this space and who know Microsoft - this is a very BIG deal! This is a new Microsoft that embraces pluralism and realizes that companies will use a multitude of services and platforms to build their own reality for day to day operations. This is where we are today and Microsoft is here. What other stack/platform can match this?

Hall: With any PaaS, the barrier to entry is about as low as you can go. Which makes for some odd comparisons when we dig into that. Windows Azure is purportedly a PaaS first and IaaS second, it started that way and pushed it hard. AWS won't even mention the word PaaS even though they have tons of services and features that provide the PaaS style single command line (click in some cases) deployment. For environments that don't have a clear PaaS story, the barrier is excessive, cumbersome and in my humble opinion barely worth mentioning. So those that don't have a legitimate PaaS story I'll leave to discuss in another day.

This bring up another crux, what about all the PaaS services that actually run on AWS. Heroku, EngineYard, AppHarbor, AppFog and almost every Cloud Foundry or OpenShift PaaS service is setup on AWS. So clearly, if one includes AWS's services and AWS's customers that provide PaaS Service then it clearly has a substantial lead in usability over anybody else. Even if we step back and just look at the setup and use of a first time AWS customer that is using Beanstalk, EC2 or S3 it is still extremely easy to do so. Sign up, check against an auth mechanism or token like a code sent to your phone of via email and then setup one of the above mentioned items and boom, you're running an app.

Arguably Heroku, EngineYard, Cloud Foundry and OpenShift based PaaSes and others are where serious barriers are removed though. Setup, use and deployment of applications into PaaS environments like these, which happen to be on AWS, is as easy as it gets.

But stepping into the world of Windows Azure again, the team and efforts with Windows Azure have moved this cloud option from a "absolutely no" to a "hey this is pretty easy and feature rich". Windows Azure, which I won't speak about the past again for this answer, has dramatically redefined how it approaches deployment and actively provides more deployment options and capabilities then pretty much every other provider of PaaS or IaaS services. In addition it has gone polyglot in a way that AWS is actually starting to arrive late to the game for some things. Take for example the AWS Node Beanstalk capabilities. They arrived almost a year after Windows Azure made it extremely easy, elegant and beautiful to deploy a Node.js based application in AWS. In addition the pricing around Node.js, .NET, PHP and other applications have gone to zero for small shared cloud hosting models. This of course is great for development, testing and debugging most apps before going live.

Overall, that pretty much covers the bases of the key providers that I personally use and have been watching. Windows Azure, AWS, Cloud Foundry, OpenShift, Heroku, EngineYard are the key companies to watch right now, they're doing the grunt work on innovation in the space and moving things forward to remove barriers to entry.

Piper: I love the Redmonk guys! Very smart people and I recommend anyone unfamiliar with their opinions go seek them out. Developers are the new kingmakers!

So yes, I agree completely that low barrier to entry is key to the rapid developer adoption of the cloud technologies we've been discussing. In fact, it was one of the "aha moments" that led me to move from my previous role at IBM to Cloud Foundry at (then) VMware - the ability to code an app locally, push it to the cloud without making any changes, and then scale it within seconds. Given my role it is a no-brainer to say, well, obviously, Cloud Foundry has low barriers to entry... but as Adron says, I think that applies to many of the similar PaaS offerings like Heroku. I'm also really impressed with the tooling integration that I've seen demonstrated between Visual Studio and Azure - clearly developers in that environment are being made to feel comfortable with the journey to the cloud. I should point out that many of the cloud providers, particularly the PaaS providers, also have IDE plugins that work well. For really low barrier to entry though, I still like the clone from Github at command line, build and test locally, and then push from command line to cloud experience that Cloud Foundry and several other cloud offerings provide - even more lightweight than requiring an IDE.

InfoQ: What is something that used to be hard for developers to do in the past, that's easier now because of the cloud? Moreover, are there things that developers simply ignored or didn't do in the past that has now become straightforward?

Mårtensson: This is the question of the bigger picture. What is it that is important when we develop? Will we one day look back to the "dark ages" before the Cloud and ask ourselves how we ever got anything to run back in those times? Building globally scalable solutions with tens or even hundreds of millions users is honestly not something that most of us will ever do. But we *can* do it. And if our business is smaller than building our own datacenters like Facebook, will we ever see any limits to what we can do? With a decent architect who understands the powers of the cloud platforms I would venture to say it's not even difficult to develop these solutions any more. No startup today will say "OK so we got some venture capital here - let's go out and buys some servers". If we look into the future to try to see the environment we will develop for in I believe that CPU power, amount of RAM and storage capacity, even Internet Speed, will be something less and less significant for the way we build our applications. Instead we will come to rely on there being enough capacity for what ever it is we are doing and what ever usage pattern we have in the demand for our service. Naturally things will still break in the future and some times services will be out of order. It's not going to be the case that we have to run out on the town in a state of panic and buy a new hard drive. Our service will self heal. In the bigger picture we will develop with new patterns that take all of this into account from the start and we will never ask if we have enough compute power.

Hall: What I'd proffer are the top 3 things:

1. The biggest impact that has also impacted how developers can develop is the ability, with the mere click of a few options and a script here or there to spool up ENTIRE OPERATIONAL DEVELOPMENT ENVIRONMENTS. Servers, test servers, UAT servers and more. This is something that even under simple virtualization was limited in so many ways before. But now, with cloud computing abilities at AWS, Azure and others it is no limit at all. In minutes what took hours or days or months before can be done and working in a way that can move forward entire efforts in ways that just 6-7 years ago we couldn't even imagine doing then.

2. The ability to distribute systems in a way, across geographic boundaries, that just 6-7 years ago would have cost hundreds of thousands, if not outright millions of dollars in capital investment. Now, with merely a few hundred to a few thousand dollars a month a massive distributed system across widely dispersed, multinational zones can be setup and running in minutes. Ready for use.

3. Distributed systems are becoming the common practice, versus the vertical stack ‘em high approach. With that change, the idea behind idempotent, resilient, self healing, asynchronous, scalable, highly available systems came within reach of the vast majority of programmers at all sizes of companies. The extremely limited design behind vertical scaling is slowly falling to the wayside as more and more developers are moving toward the horizontal ideas. With that follows a whole array of languages and frameworks that increase the ability to harness these capabilities. This change in mindset and approach is continuing and is increasing the capabilities of cloud computing every day.

...and that's just the top 3 big ones that come to mind immediately. There have been so many change and advances that one could write a book on the topic.

Piper: What does cloud make easier for developers?

1. On-demand, potentially disposable environments. Actually, local tools like Vagrant are friends to developers in the same way, but the ability to rapidly provision and cookie-cutter clone environments and run them for an often trivial cost is extremely valuable. This is what has been a massive impetus to the devops movement - developers are no longer subject to the whims of the gatekeepers in ops, to whom they used to have to go to provision new environments. That is not to knock the operations team - they have also been given a lot more agility by the new cloud tools and environments. "as a Service" is the KEY part of the *aaS acronym soup.

2. Scalability, availability, elasticity. I think Magnus and Adron cover this one well, there's not a lot more for me to add other than to "boil it down" to these three principles.

3. I'd argue that two things - "big data" and "the Internet of Things" - are very largely enabled by cloud availability. Large datastores vertically scaled have been possible for many years, but distributed datastores with massive storage capabilities, replication, MapReduce etc tend to be more cloud-related. Connectivity of sensors and collection of and response to data feeds has always been possible on a point basis, but developers now have the ability to build sophisticated systems that implement these ideas with zero or few points of failure using the flexibility of a cloud fabric.

That's just a quick summary. This is an area of technology evolution with far-reaching implications.

InfoQ: While many developers are starting to spend significant time developing cloud applications, the fact remains that a good portion of developers have no reason to touch the cloud in their day jobs. Assuming that these developers don't have unlimited free time to experiment with cloud environments, what do you recommend they do to stay up on the latest cloud services and strategies? How do you yourself keep up with this fluid cloud space?

Hall: Two ways I find super useful are key for those not using cloud/public cloud or with no private cloud on the horizon.

1. Learn about distributed systems in general. This can be distributed databases, distributed compute (mesh networks, etc), network management across distributed environments via automation or a host of other options. There are books coming out these days too that can help with this, since a lot of the work has been heavily academic (re: not really useful to the coder or operations person actually trying to make use of distributed systems) a lot of the material has been fairly useless in day to day operational and development use.

2. Try to work these in smaller scale into the daily development process when useful. Even though the *cloud* isn't being used it doesn't preclude the power, usefulness and robust nature of building a system from a distributed perspective instead of going straight vertical. This is the core of one of my staunchly urged suggestions these days: Please drop making purely vertical applications unless it is a throw away application. If an application has more than a year life span expectation, build it in a horizontally designed, scalable architecture that can be used well within a distributed systems environment.

Mårtensson: It is really easy to get started with the first steps to the Cloud. First I want to note that the BIG question here is where we are in terms of broad and general adoption of Cloud Computing? I'm a proponent and great believer of Cloud Computing and I really want to believe we're gearing up for a bang here. That said most if not all the signs are pointing in this direction; training companies are showing a significant increase in interest, consultants note more chatter about cloudiness, more customers are stirring up interest and market shares are growing for the vendors. I really can't see many indicators against a rapidly growing adoption. Traditional hosting options will fight for their survival and do what they can to show alternatives but this will in my mind only slow down the inevitable. Especially if you consider the hybrid scenario as a true Cloud scenario and I think we should we will see a rapid uptake in demand. If we talk technology adoption lifecycle I think we have the early adopters on board and stand on the brink of the chasm that separates that group for the early majority group.

The Cloud Platform Vendors are making sure to enable easy adoption and a smooth onramp to their respective offerings. Microsoft for instance recently removed the credit card requirement for some trial scenarios. To answer the question it will be and already is very easy to get going with Cloud Computing. You don't need a lot of time to start up. You can simply in a matter of minutes sign up and get a trial running. In fact each person who has an MSDN subscription assigned to them already has a personal Dev/Test environment in the Cloud. All that is required is to activate Windows Azure benefits on the MSDN Subscription, which takes about 2 minutes. To deploy your first applications to the Platform there is lots of guidance online. For instance my set of video demos on my blog. Literally if you have 15 minutes I bet you can put your first application into live production on the Windows Azure Cloud. It will be a simple maybe trivial thing but it will feel really cool and refreshing.

Piper: I think any of the PaaS offerings out there are aiming to provide a frictionless deployment surface - be that AppEngine, Cloud Foundry, Heroku, OpenShift, the more PaaS aspects of Azure, etc. If you don't find the platform you choose to try out provides a simple way of getting a straightforward application deployed it probably isn't doing things right. When you start to look into some of the scalability and data access aspects of your app, there may be more of a learning curve.

Personally while I find good language and programming reference books from publishers like O'Reilly often have a lifespan of several years, "cloud" texts have not aged so well given the rapid innovation in this space. Wait a month and AWS will have introduced a new API or dropped price, and one of the PaaS vendors will announce a new partner, plugin, or feature! This means it is much more useful to dip in and out of blogs and follow folks on Twitter who can recommend good links. I find two particular sources are valuable. The Github activity feed lets me follow new projects, apps and libraries that my contacts are starring or creating. The DevOps Weekly newsletter (a weekly email rounding up the cloud and devops space) is also a useful way of getting a digest of the latest advances, too.

About the Panelists

Adron Hall is a software architect, engineer, code monkey, coder, and distributed systems advocate. He is a prolific open source contributor who actively uses GitHub to contribute to projects. You can read his thoughts at and follow him on Twitter at @adron.


Magnus Mårtensson is a Cloud Architect/Developer at a consultancy called Active Solution in Sweden. He is a Windows Azure MVP,  Windows Azure Insider, and a Windows Azure Advisor. You can read his writings at and follow him on Twitter at @noopman.


 Andy Piper is a Developer Advocate for Cloud Foundry. That means his days are a fun mix of technical marketing, business development, talking to developers, public speaking at conferences, writing docs and samples, complaining to engineers when they break things, blogging and tweeting, and organising events. Read more from Andy here and follow him on Twitter at @andypiper.

Rate this Article