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.
Michael Maximilienchief architect for cloud innovations, IBM
4. Services. Treat services, such as databases, as attached external resources.
5. Executions. Keep build and run executions separate.
6. States. Execute an application as one or more stateless processes.
7. Port binding. Export services via flexible port binding.
8. Scalability. Scale horizontally -- replication of small containers -- and not vertically, with fewer bigger containers.
9. Execution. Start applications fast, but perform a graceful shutdown when failing.
10. Phases. Minimize differences among development, staging and production.
11. Logs. Treat all logs as a single event stream.
12. Admin tasks. Run admin and management tasks as one-off processes.
"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."
Are businesses being strong-armed into adopting containers and microservices?
Heal thyself: Can your cloud app do this?
Scalable apps require scalable management