This morning I came across the article published over at InfoWorld regarding developing applications in the cloud. The author, Paul Krill, pulled together various snippets from a variety of players in the cloud, citing a word of caution as to what the developer had to now think about when looking to the cloud for their infrastructure requirements.

While a little light on actual detail, he did highlight a couple of big areas that are worth pulling out.

• "Databases aren't the same in the cloud"

  In our experience as a company helping move projects to the cloud this is the number one concern. Scaling traditional databases such as MySQL is not a trivial manner no matter how easy some would lead you to believe. Transactional data running over a large range of machines in a fault redundant, high performance manner is the data utopia most DBA's can only but dream about.

  

  Our advice in this, is to look at how you are managing and storing your data and ask yourself do you really need a row-column type of structure? If all you know is a hammer, then every problem looks like a nail.

  Relational databases have their place, but they are not the only way to store and manage data and there are a large number of alternatives available both as stand alone projects and as integrated services from cloud providers.

  That's not to say you can't run a traditional relational database in the cloud, you have to have mindful of the consequences and management.

• "Get used to rapid change in the cloud"

  I smiled reading this one because while its true for most things in the Internet / Computing space, you can forgiven for feeling always a little behind at all the news and hype around the cloud computing space.

  Things do change, and already we have the likes of Amazon talking of deprecating services (some of the SimpleDB API is changing after 2010). But should we worry? Should be we be concerned that we are developing for something that may not be here tomorrow? Will the developer always be upgrade mode?

  Any deployment manager will preach to you, if it ain't broke don't fix it and they are always the last resistant to any unnecessary upgrading of components. As developers we just want the latest'n'greatest.

  So when a new cloud service pops out, its very tempting for us to get seduced into thinking its going to be the saviour of a troublesome area, and for some reason, the way you've been doing it suddenly feels dated or just wrong!

  Don't be seduced. Give the services time to bake and keep an eye on the forums and let others flesh out all the pain points.

• "let go of most plumbing concerns in the cloud"

  For most developers comfortable with the principals of good object design this shouldn't be a big problem. A good cloud provider will do much of the heavy lifting of a particular service, leaving the developer to get on with developing the business logic of the application.

  

  Think of the cloud provider as an additional member on your team. Traditionally you would assign a task to them, like "Manage the storage of a file", and you want that person to make sure they cover all use cases including backing up, security and the management of that file. From your side, you need to rely on that team member to deliver that service as your logic relies on it.

  Providers are starting to move up the service stack in the breadth of services they are beginning to offer. These services abstract a lot of the complexity associated with the offering giving you what looks to be a very trivial API to simple trigger the service.

  For the cloud providers this is a two prong approach. Firstly, they get an opportunity to offer you a richer platform and therefore by charge you more. Secondly, they get the chance to lock-in you into a given service. While you may read about transparency and openness and easy of movement between vendors, it is still by-in-large difficult. Moving a few TB's of data from S3 to another provider is not a trivial task!

  The best advice we tell our clients is to start, if not already, looking at web services to start tying pieces of the system together. Keep things pluggable, so should you have to say move away from a given provider, all your application code has to do is to change end points. In other words, no vendor specific logic permitted in your code!

The world of clouds has definitely opened up the possibilities for developers as they look to build the next generation of applications and port their current generation applications over to this new on-demand model.

At the end of the month, we are in New York, hosting a full day, Cloud Boot Camp at Cloud Computing Expo. We've got a packed schedule, which I'll be going over in detail many of the concerns and issues highlighted here.