11 Things Every Developer Should Know About the Cloud
Cloud computing opens a world of possibilities for software and developers, but coding for the cloud isn’t necessarily as straightforward as you might think.
The learning curve for developers can be tricky—especially for web developers unused to working with concepts such as threading and concurrency, latency, asynchronicity and failure tolerance.
Here are 11 things you need to watch out for when you start developing for the cloud.
Compliance & Governance
Legal and operational requirements often dictate the location of your data storage and hosting, and in the cloud it’s no different. While the abstraction of the infrastructure layer is a huge boon to scalable development, you need to be aware of how your instances and services are provisioned, or you may end up inadvertently sending your data to a country or state that breaches your local privacy laws.
A cloud service may be supported by multiple data centers in various locations, and there is often no way of knowing where an instance will physically be spawned. This is easily overlooked given that the whole point of the cloud is to be to some degree location and infrastructure independent, but it can be critical for governance.
With the potential for so many instances and distributed services, you introduce many more possible points of failure than in a traditional data center hosted application. Particularly for developers used to runtime interpreted languages like PHP, ASP or ColdFusion, the necessary leap to failure tolerance and asynchronous data can present a difficult learning curve.
In particular, your application must be architected from the outset to anticipate failure—an instance failing to start, data not arriving in a timely manner or perhaps not arriving at all. Both your service layers and your UI must cater to this, and provide appropriate mechanisms and user feedback.
For example, let’s say you have an application that allows a user to upload a video file for conversion, and you spawn an instance to manage it. If you code synchronously your application will break should the instance fail to start or a storage mechanism temporarily loses connection. If on the other hand you architect with queuing and distribution in mind, your app can alert the user to a delay or gracefully failover and allow operation even though the data required may not yet be ready.
The nature of the cloud and elastic computing means that unlike the traditional hosting model of fixed network addresses for various services, you won’t know the IP address of an instance in advance, and so your application must be able to work at a high level without being slaved to a physical (or logical) location.
This is not so different from proper load balancing or clustering, and can present the same sorts of issues, but those unused to architecting for such environments must take this learning curve into account when moving into the cloud.
Scalability and State
Horizontal scalability is one of the primary reasons to move to cloud architecture, but it is important to realise that not every application suits this environment. With no ability to predict instance usage or continuous connection, each request a user makes may potentially be served by a separate instance, and so you must manage the state accordingly.
Cloud specific languages are still in their infancy, and developing in familiar languages on a cloud infrastructure can present unique problems. You may not be able to rely on your IDE as much as you used to—debuggers especially can be problematic, and in some cases non-existent.
To those with experience of low level languages or development before the prevalence of high quality tooling this won’t be a new thing, but if you have never debugged an application the “old fashioned way”, now is the time to learn.
This isn’t a problem for everyone, and varies wildly based on the services you use and the nature of your application, but you may find that—once developed for a given cloud infrastructure—your system is no longer portable. Abstraction is the key here, bearing in mind that the relative infancy of cloud platforms makes adherence to standards even more important.
You may discover that various standards are unsupported or partially implemented by your provider, and in such a case developing against this environment will make things difficult should you need to migrate to another service due to pricing, governance or reliability issues.
Traditional software development relies on file and relational data storage more often than not, but these solutions do not scale well in the cloud. Developers are required to learn new technologies such as NoSQL solutions, big data services and proprietary Platform as a Service (PaaS) APIs. These new technologies require a fundamental shift in thinking, and present new coding problems traditional software developers may not yet be aware of.
Before you begin architecting for the cloud, make sure you’re up to speed on the use of non relational data storage, big data concepts like Hadoop, HBase, Cassandra and Hypertable, to name a few. It’s also worth looking into techniques for developing against PaaS services like SalesForce.com, where you rely on an API for data storage rather than directly managing your data.
Remember that at any given time, a user or service request will be served from an unknown instance, so localized storage is no longer possible.
In traditional development, it’s not a big deal if you leave the test server running, or run multiple local load tests. In the cloud however, every CPU cycle potentially costs money, and you need to take this into account with everything you do. Development processes need to bear in mind CPU hours, bandwidth usages and storage allocation, and so new forms of efficiency are required.
Of course these requirements aren’t necessarily new, but those used to developing on heavy duty servers, high bandwidth connections and local environments can easily become lax in fine tuning things like message size, connection pooling and temporary file writing. When coding for the cloud, it’s time to dot the i’s and cross the t’s: take care of all the details.
The usual best practice is to test apps on an identical platform to the one that will run in production (or as close to it as you can manage)—but cloud infrastructure makes that exceedingly difficult, and it’s very possible for situations to arise in production that you cannot replicate locally. Even taking a snapshot of an application at the time of a system event can be problematic, so along with learning new ways to debug you need to be constantly aware that things can work differently in the cloud.
Take this into account when providing estimates and allocating time for functional or user testing—and especially when attempting to debug and resolve a live issue.
Never make assumptions about the nature of deployment licenses in the cloud—they may surprise you. More than one development house has been caught short after developing apps and suddenly discovering that the licenses they own for libraries and software entities don’t scale in the cloud, and may produce hidden costs.
Documentation and Community
Because everything is still so new, you won’t be able to initially find the same level of community help, blogs, documentation and solutions that you’re used to Googling for. In many cases you may find yourself pioneering even simple functionality in a specific use case, so ensure that you document your work and share as much as possible.
The body of knowledge available on the net is growing, but it still has a long way to go, and these resources are a valid and important part of what makes up your usefulness as a developer—so don’t underestimate it.
Altogether, cloud computing is full of promise.
Applications can be built to scale on demand and use only the resources they require, while still being able to compete on the world stage with the same kind of assurance that once only came with deep pockets and big data centers.
As technologies, languages and developer experience grows, new ways of doing things will emerge in the cloud, and it’s up to you as a developer to seek them out and turn them to your advantage.