Over the past 12 months my team has been wrestling with the challenge of introducing a plethora of technologies into a cloud environment. Using the NetFlix technical blog as our inspiration we have sought to architect and engineer an approach where a small team can support a large technology footprint and develop 24/7/265 applications. The main public cloud providers have a good range of self-maintaining services (including database as a service) that help towards this goal.
Beyond these services we have learnt that pre-cloud technologies start to run into problems. Put simply there is a world of difference between technology originating in or designed for the cloud and technology that predates but can run in the cloud. Applications that are well suited to the cloud have certain characteristics
- Installation can be fully automated.
- Configuration and change after install can be fully automated
- The architecture of the application is simple
Applications that originate in the cloud often satisfy all three by their nature and increasingly by intended design.
In the cloud we are told to expect and design for system failure hence the importance of fully automated deployment and configuration of infrastructure and application in the event of that failure. Ideally that failure should be unnoticed by consumers whether they are people or applications.
Although many applications do have a silent install facility these are not always well documented. They seem to be aimed at achieving a one-time basic install ready for a human to take over and finish the job. Basically they are providing a scripted version of a static machine image. They are not aimed at updating a configuration once an installation has taken place.
Tools such as Puppet, and Chef help to plug the gap. Puppet in particular has thousands of open source Puppet modules covering much of the technology you can expect to use.
Ultimately these tools are ingenious not magic. A cursory look at some of the scripts shows where someone has discovered that an application has a readable settings file and put in place a process to detect whether it contains the desired settings and if not enact the stop, replace, start process to achieve a fully scripted configuration.
So to summarise the top 5 things I have learnt that steer me when designing applications is as follows:
- Design simplicity is of paramount importance (it always has been)
- Design to make automation simple
- Design to provide a rich instrumentation and monitoring capability.
- Design so the install is linear in operation. An application should not have to ping-pong responsibility back and forth to other applications.
- Design to expect failure or at least highly variable service
