The developer's checklist to prepare for the cloud

Like most people, you probably have two feet in your own infrastructure and one eye toward the cloud. It's pleasant to dream of the day when you'll pay for what you need when you need it -- rather than buying a bunch of hardware that's valueless virtually the moment it's pulled off the truck. I mean, cars have a better resale value.

So what should you be doing to prepare for the day when heading to the cloud is more than just talk?

The first thing you need to think about is maintaining your freedom to exit in the event your cloud vendor no longer serves your needs. You need to preserve your flexibility to scale, switch clouds, communicate between clouds, and generally change addresses. You must also ensure you can deploy your code on the cloud of your choice, and part of that is refactoring your code to give you a wide range of choices.

Cloud transition tip No. 1: Move toward HTML/JavaScript. It may be possible to remote your big, fat client to a cloud environment, but it's far from ideal. Even Netscape saw a future where the browser was the primary client. With tablets, Ultrabooks, and smartphones all competing for their share of the desk/lap/pocket/swiss laptop bag, the only thing you can depend on is HTML/JavaScript.

Cloud transition tip No. 2: Move to standards. Is your company standardized on IE6 or an equally retro platform? With a myriad of devices, this is probably a good time to start working toward more standard versions of HTML/CSS and such. You can still abuse your employees and users for your own sick purposes by forcing them to use a certain browser that merely sucks less than it used to. But if you move to Web standards you'll be future-proof and able to adopt more Internet and cloud-friendly security standards such as SAML, OAuth, and so on.

Cloud transition tip No. 3: Finally base your security on Web-oriented single-sign on. Right now you have either a bunch of incompatible disconnected authentication systems or some Active Directory Kerberos monster or NTLM or whatever. Now is the time to go Web with SAML, OAuth, or the others. This is the hub-and-spoke integration effort for all your systems, which beats the heck out of point-to-point integration or the feckless "let's lock ourselves into a vendor because that always works out well in the end" strategy. Authentication based on Web standards will ensure compatibility with numerous cloud vendors and give you the flexibility to change partners if your cloud provider doesn't work out.

Cloud transition tip No. 4: Go SOA. It's time at long last to go service-oriented. You'll be able to move services around in the cloud world, and your system will be more robust. Anytime your cloud vendor does something special for you -- say, create point-to-point pathways -- it locks you in and you lose flexibility to migrate or scale. A SOA strategy is the ultimate way to ensure that, even if you need something out of the ordinary, it won't trickle down throughout your infrastructure.

Cloud transition tip No. 5: Go REST/JSON. Sure, you can do this with Web Services, but SOAP has never achieved the level of interoperability that it promised. When you go cloud, you need to be able to move things around and not worry about what version of JAX-XX, WS-XX, or whatever you're using in an application. REST/JSON has ubiquitous client support and is an obvious convention for service location.

Cloud transition tip No. 6: Ditch Microsoft .Net. If you ever bought into it, that is. Oddly, whether it is Node.js or Ruby or Java, you enjoy a much wider level of support, lower expense, and more than with .Net. Even Microsoft's Windows Azure supports Java, but not everyone (to put it mildly) supports .Net. It really doesn't take long for a good developer to learn the basics of a new language with a little help.

Cloud transition tip No. 7: Upgrade your development methods. The shoddy way most companies develop software virtually ensures that applications will be vulnerable. "Let's hide behind the firewall and assume it's safe" is really a security antistrategy. "How cheap can I get those developers?" is plain silly. "I'm coding this in prod" is asking for disaster. Anonymous didn't do anything very sophisticated in most of its attacks; it used SQL injections, which are easy to prevent. Build your defense from the code up.

Cloud transition tip No. 8: Go HTTPS. We all love the idea of a VPN, but to have the maximum flexibility, our main form of encryption needs to be the most prominent method found on the Internet.

Cloud transition tip No. 9: If you are Java, go WAR file. Sure, everyone loves JavaEE's 20 layers of Zip files. It's so enjoyable to watch your code compile in five seconds, then take three minutes to package. Yet the cloud loves the WAR file. There certainly are vendors who support Java EE, but you'll have far more flexibility with WAR files.

Cloud transition tip No. 10: Deploy a private cloud that has a public version. If you're deploying a private cloud, make sure you have a public path. The great thing about plays like Cloud Foundry, OpenShift, and others is that you can think local and migrate global. This also may be a good way to start your cloud play while your company's lawyers catch up.

Cloud transition tip No. 11: Take baby steps. Your migration to the cloud won't happen in a day. Deploy less critical applications to the cloud first and see how it plays out.

Cloud transition tip No. 12: Do your homework. Research how you'll scale, what security standards are supported, and what SLAs are offered, along with the security certifications your provider must possess.

Ironically, when you move to the cloud, what you really need to do is what you should have been doing all along.

Greet all vendor claims with skepticism. When they tell you about their magic solution and that you shouldn't worry about a weird, proprietary non-HTTP protocol because their solution has the magic beans, ask them how well it works with autoscaling and how you'll connect it with your identity solution. Tell them you want standards. Consider whether secret-sauce software is secure and something you really want on your network.

A move to the cloud is like any other move: an opportunity to throw away stuff you don't need and clean up your act. In this case, doing so also ensures you won't end up stuck with a provider you wish you'd never met in the first place.

This article, "The developer's checklist to prepare for the cloud," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.