Deploy is the new run

Here at AppZero, I've helped many of our customers deploy their applications to numerous compute clouds. All of this deployment has gotten me thinking about the changing state of today's application lifecycle.

The essence of my thinking is that I see deployment as the evolution of run in an engineer's development cycle.

The reusable components available to a software engineer has included, from smaller to larger: subroutines (e.g., threadsafe hash table), class, and library (Btree library, O/R mapping). Recent years have seen the advent of more coarse-grained units of reusability, such as database servers (e.g., mysql), web servers (apache), and language stacks (python, php, ruby/rails).

I argue that these coarse-grained reuse components are analogous to subroutines and libraries. Both abstract functionality behind crisp interfaces. Both significantly improve the reliability and agility of application construction. As an example, the widespread availability of apache and mysql has revolutionized the agility of web application development.

Even more, in the last two years, units of reuse that are even more coarse-grained have become available to application developers and architects. A good example is the LAMPP stack (Linux, Apache, Mysql, Php, Perl) where an architect can treat these component sets as a single reusable block of functionality that an application can take for granted.

The trend continues with the advent of elastic machine provisioning. Now application architects can treat Amazon AWS AMI machine images such as Ubuntu + LAMPP + Ruby + Rails + Hardware as a component that, once created, is completely repeatable (like a sort subroutine), down to performance and bandwidth characteristics.

Here's where it gets interesting.

In the world of smaller reuse components, deployment was simple. If I included a sophisticated implementation of a threadsafe dictionary in my code and wished to run and test it, I simply compiled and ran the resulting binary.

To gain greater benefits, I increase the granularity of the reuse-components I use to build my application. I move from reusing just a threadsafe dictionary or a btree library to a set of database servers, set of cache servers, application servers, web servers, and a set of machine instances running optimized machine images.  

Now, to test the application, I wish I could just run it, but because of complexity, I use the word deploy to convey that I've lost the agility I used to have when I simply ran the application.

But now, we are at the cusp of a revolution: we can now make deploy as simple, as agile, as run. With elastic machine provisioning as a key enabler, deploy is moving back from the IT groups domain to the engineering group. In this environment, agile deploy expands the developer power from write, run, test locally, hand off to IT to develop, stage, certify, deploy.

I think this development is hugely exciting. The efficiency gains made possible by these events will be similar to what we experienced with the advent of the microcomputer --- developers no longer need to depend on others to deploy applications. A dramatic shift in innovation will result.

Here at AppZero,  our VAA technology virtualizes away many of the differences between the developer's desk and the deployment server. We are excited to be part of an ecosystem that will realize this potential, making deploy as easy as run.