Assessing the risk of cloud application and services failures is a first step in evaluating cloud providers, but the cloud application architect's responsibility doesn't end with being assured enough to buy. Building in an off-switch for red-alert situations, like data loss, poor performance and other application and server problems, can give cloud customers some control over apps placed in the hands of third-party cloud providers.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In this column, I explore the practice of building resiliency, particularly the so-called "off buttons," into cloud services and applications . I'll also report on developers' views about the skills they need to land cloud jobs, the topic of my previous column.
Companies' fear of losing control of their applications has shown up as a reason not to adopt the cloud in TechTarget surveys for the past few years. Loss of control over security and performance was a barrier cited in the 2011 and 2012 TheServerSide.com Java Developer Survey, for example. In the new 2013 TechTarget Cloud Pulse Survey, which had 1,497 respondents, 61% use cloud services now and 39% do not. Of that 39%, 80% won't use cloud for at least a year, and 45% plan not to use cloud at all. These non-adopters' top concerns are loss of control over security and their applications in the cloud environment.
Making a cloud application an at-your-option service calls for attention to how the service is accessed and orchestrated in a workflow sense.
Gaining control starts in the application evaluation phase in both development and cloud service selection, software engineer Tom Thompson told me. What services are so essential that an organization could not function, or would suffer great damages, if it lost the cloud or had to turn it off? Typical examples are financial and stock-trading applications. Keep those mission-critical functions outside of the cloud. On the other hand, it wouldn't be risky to put some analytics and advertising services in the cloud, and then switch them off as required.
Thompson points to losses an online sales company would incur if it lost or had to switch off cloud services. The company should build in some resiliency measures, such as being able to display and sell the most popular items, while less popular items would generate a diplomatically phrased error message. "Being able to handle some orders would be a better place to be than being unable to take orders at all," said Thompson.
Splitting apps between more than one service provider can work in some situations. "That might work if, say, the service can be broken into discrete components that can be easily managed," said Thompson. "For example, you might have one provider serve up the ads, and other handle the analytics." Take care to establish which provider provides technical assistance with specific issues.
Complexity is the challenge when using multiple third-party service providers. "The problem is that each provider has their own API, and so you're increasing the coding effort to write to two or more different APIs," said Thompson.
Making a cloud application an at-your-option service calls for attention to how the service is accessed and orchestrated in a workflow sense, according to Tom Nolle, president of CIMI Corp., a software, data and telecommunications consulting firm. Here's a snapshot of what's involved:
- When a service is called by another component, a software architect or manager who wants to make that service optional and provide what's effectively an on-off switch has to be able to intercept the request. Then, the architect prepares a dummy response that won't cause the application that called your optional service to fail.
- In most cases, this means designing the application around an "adapter" object that will sit between the on-demand app and the rest of the application and will either call that on-demand app or bypass it on request.
- The dummy response is a means of insuring that when an application uses the adapter, the software architect understands what it would accept as a response if it's called partner were out of service, and then generate that response in the adapter if the component is turned off.
- Now, by controlling the adapter, the service can be turned off.
If the service is not mission-critical, there are workarounds that make the turning off the service process less necessary. "An example would be that if an ad-placement-by-demography service were taking too long, you could substitute a simple banner ad," said Nolle. "In that case, the dummy response would be the banner ad."
More tips on ways to gain control over cloud services' and applications' resilience will be coming soon on SearchCloudApplications.com. Let me know what advice and background information would be valuable to you.
Meanwhile, back on the cloud developer jobs front: Following up on my last column on that topic, TheServerSide.com Site Editor Cameron McKenzie asked readers: "What does an enterprise Java developer, who lived through the evolution from Servlets to Struts and to Spring, have to do to keep current?"
Older universal tools, like Ant, are fading away, Fuenzalida said, so developers have to be knowledgeable about Maven and private repositions.
Another reader stressed the importance of integration tool mastery, naming IBM WebSphere MG, MQ and Data Power, as well as Oracle's SOA Suite and Oracle Service Bus for enterprise-level integrations.
Which new skills have helped you remain valuable in today's development market? Let me know at firstname.lastname@example.org.
Follow us on Twitter at @CloudAppsTT.