Techniques and tools abound for cloud app development. To get the most out of them, take your apps beyond scalability and into the realm of self-healing and statelessness.

At the opening keynote speech on the first day of Cloud Expo in a dreary, rainy New York, IBM's Michael Maximilien wasted no time in putting attendees on notice, reminding them that the goals of developing cloud applications must go beyond scalability to encompass other traits that include framework and cloud platform agnosticism, application self-healing and isolation.

Maximilien, who is IBM's chief architect for cloud innovations and often referred to as "Dr. Max," also discussed the 12 key characteristics that IT professionals developing cloud applications must consider.

Scalability, Maximilien said, should be automatic, allowing applications to allocate resources and replicate containerized microservices as necessary without administrative involvement. Those applications should also be self-healing, enabling them to automatically restart and recover after a crash, again, without IT staff intervention.

Finally, developing cloud applications should be framework-agnostic, allowing them to ultimately run anywhere -- on Amazon Web Services, Microsoft Azure, Google Cloud Platform or IBM's own SoftLayer infrastructure, which now forms the core of IBM's Bluemix platform. Isolation comes into play as a method of keeping application instances separate, ensuring a business's data cannot be accessed by competitors running instances of the same as-a-service application.

Twelve factors of developing cloud applications

The 12 factors of cloud-native, as-a-service application development were first published in 2012. Any developer building cloud-based applications, most of which run as a service, should familiar with the 12 factors, Maximilien said. Those factors are:

1. Codebase. Work from a single codebase that is tracked in revision control with multiple deployments.

2. Dependencies. Declare and isolate application dependencies.

3. Configuration. Store the configuration in the environment and not within the application.

Production for hundreds of thousands of users will reveal problems that don't show up in small-scale testing.
Michael Maximilienchief architect for cloud innovations, IBM

"If you keep states in an application and that application crashes, you lose those states when you restart the app," Maximilien said. The proper way to handle states, he said, is to store them in an external database. Doing so allows an application, when restarted after a crash, to pick up from exactly where it was when the crash occurred.

"Production for hundreds of thousands of users will reveal problems that don't show up in small-scale testing," he said. These problems are most likely to manifest themselves as bottlenecks that hinder performance, API calls that can't keep up with demand, network latency or outright crashes.

Another admonishment from Maximilien is "developers and test staff often fail to comprehend that test and production environments are very different -- even if they are configured identically."

Joel Shore is news writer for TechTarget's Business Applications and Architecture Media Group. Write to him at jshore@techtarget.com or follow @JshoreTTon Twitter.

Join the conversation

1 comment

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.