We've been doing lots of infrastructure at work lately. A couple basic apps have been added to our internal system -- a login app, and an admin app. The login app logs you in. That's all it does -- it takes your username and password, sets a cookie, and redirects you to your destination. That's an application, with all the infrastructure an application implies. The admin application reads a common config file, finds all your admin tools (which are often embedded in other applications) and gives you a summary. That's all it does, one page.

It took me a little while to really commit to making these applications. They are so small, it didn't make sense. And yet it does; it's manageable and maintainable, the apps works, they do their function.

This has been a kind of vaguely defined goal of paste.deploy all along, though now that the tools are there I'm starting to see more of the potential and what it can mean. I wanted applications to be easy to install, upgrade, and compose, so that it would be reasonable to make really little applications. The quintessential application in my mind was the modest formmail script, that just emails all the fields off to someone. This classic application remains useful today, but I sure as heck wasn't going to set up a new Webware app server instance to do it. And sometimes I'd find myself writing to a database just to justify the infrastructure. Bad stuff.

The login and admin apps take it a bit further -- not only are they small, they are also useless on their own. But even though their utility is predicated on the existence of other apps, their functionality needn't be. And designing around that I find the applications have utility even in the context of a heterogeneous environment. I don't need to commit to Rewriting Everything In My Framework Of Choice.

We all know frameworks are a pain in the ass. A lot of people have approached this cloud-of-apps problem as a framework problem. Sometimes that framework takes the form of a "CMS". These are often not what Python people would think of as a CMS -- it's more like PostNuke. Other times you have to do really funky things to add in abstraction. Like Acquisition, or many of the "component" systems. I admit I've made such frameworks and plugins. It ain't pretty.

Applications are the new framework! This is kind of what REST implies, but those are high-minded ideas around some potentially very simple things, and there's still a lot of room in the simple end of things, with ad hoc communication on as as-needed basis, and complete decoupling whenever possible.

I personally really hope to see future tools emerge in this form. I don't mind a heterogeneous system. If someone makes a really great admin interface for SQLObject classes (something I'd like to see happen), I don't care if they write it in Myghty or CherryPy or Zope 3 if I can install and manage it easily. If it's done right (which to me means "Paste-Deploy enabled") then I should even be able to embed that application in my own and create a seemingly unified whole.

So far there's been very little app sharing in Python. We share frameworks (sometimes), but frameworks incur loathing. No wonder we reimplement all the time. Applications are a good alternative.