Me.Tech()

Programming has come many a mile since the 70’s. A wide array of languages, methodologies, frameworks and other similar artifacts have made the life of a programmer really simple. These artifacts have incrementally solved problems faced by programmers and slowly, but steadily, wrapped the programmers view of a program into a set of abstractions. One of the first abstractions that was built, looking at the history of programming languages, was the ability to hide the underlying differences in hardware, system software and present a unified way of programing and manipulating the system. This is what we call modern day high level programming language.

If the programming language, an abstraction of the real machine code, ever helped solve a problem, it was that of uncertainty. Take an example of the piece of code given below.

    // sample code to add two numbers  
    int a=10,b=20,c=0;
     c= a+b;
     Console.WriteLine(c.toString());

When I run this code on any machine, I am assured to get the value of c to be equal to be 30. I know when I access the variable “c” the next time, I will find it contains the value of 30. I know that two instructions from now, variables a,b,c will be available for further manipulation.

My recent attempts at programming on the cloud has taught me several lessons, the most important one being, programming to deploy on a cloud is almost like writing programs that you can never be certain about. You can never maintain application state. This means no static variables, no relational datastore, no freedom to write into the filesystem etc. Think about it for a second and it will make sense why these seemingly harmless actions are prohibited. Filesystem access is a big no-no anywhere, but as for static variables, persistent classes, singletons etc, running this on many actual/virtual machines means, all these entities with their values have to be moved/replicated across the cloud. This becomes a non trivial problem especially when the state keeps constantly changing. I could live with all these restrictions by coding, painful but effective, workarounds. What I can’t do is, work with uncertainty. Here is an example :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

  from google.appengine.api import memcache
 
def get_greetings(self):
  """get_greetings()
 
  Checks the cache to see if there are cached greetings.
  If not, call render_greetings and set the cache
 
  Returns:
    A string of HTML containing greetings.
  """
  greetings = memcache.get("greetings")
  if greetings is not None:
    return greetings
  else:
    greetings = self.render_greetings()
    if not memcache.add("greetings", greetings, 10):
      logging.error("Memcache set failed.")
    return greetings

The code is an example on using the built in caching mechanism on appengine. Notice the line of code given below; its supposed to return the value of the item in the cache with the key greetings

greetings = memcache.get("greetings")

Here’s the question: what is the guarantee that the value, which I inserted into the cache with a large timeout, is actually available. Whenever I write this line of code, do I have to write the failsafe code also(line 15,19) ? I am trying to model state using variables in the cache, mainly because its the next best thing to persistent classes and is less expensive (computationally and financially) than the key/value datastore. How do I reliably do this ? I cant trust that the cache will be available and have to keep on constantly updating the failsafe mechanism ( in case of appengine, the datastore) which is inefficient and highly taxing on the application. What has given rise to this situation is the environment of the cloud. Its not a new problem by any means. With the introduction of new languages, language constructs and other programmatic abstractions, this kind of uncertainty in programming has always reared its ugly head. The lochness of the programming world. And it will continue to do so; which is why we will have constructs like the assert(). My greatest worry is that I don’t see an elegant solution in the foreseeable future.