I am a firm believer in taking a cross-discipline-based approach to technology — taking something learned in one subject area and applying it to a problem in our everyday work. The political philosopher John Rawls, in his seminal work A Theory of Justice, provides a construct that (surprisingly) has a place in specific stages of application development. When building systems, we are constantly held back to some degree by technical debt (the time wasted by repetitive tasks, and the bug fixes required to keep systems up and running). Not only is this time costly, but it is also typically less interesting than designing and constructing new systems (naturally).
In A Theory of Justice, Rawls turns the concept of a blank slate or tabula rasa into a thought experiment, which he refers to as a “veil of ignorance.” While the concept of a blank slate (or in the case of technology, what we’re more likely to call a “green field" design is appealing, it can have its shortcomings. It does not take into account the needs of other applications. It can lack fundamental requirements that are only observed after the app has been designed. It is all too easy to default to “Wouldn’t it be great if … ” rather than remembering that an application is maintained (and not just launched). Partnering a maintenance mindset with a new approach helps avoid creating more technical debt from the outset.
What kind of environment would you design for your app?
In Rawls’ thought experiment, the reader is asked to construct a new society, but is placed behind a “veil of ignorance” that prevents the reader from knowing anything about him or herself or his or her future place in that new society, and Rawls asks the reader how he or she would like the society to be developed. Now, how does this apply to application development? With a shift in thinking, you can put it to use. Imagine that you are the application owner and you know nothing about yourself. You could own the core line-of-business application for your organization, or you may own a low-visibility application. At this point in your thought process, ask yourself what kind of environment you would design for your app to live in. You might think about the underlying infrastructure requirements first — the schools, roads, and hospitals of your deployment environment. How do you address logging and auditing? Where does the security get baked in? How do you ensure that your application has sufficient access to compute cycles and storage IOPS? How do you ensure your application is accessible to your customer when it is needed? With no knowledge of where the application will land, how can you make sure it is operating well?
The answers may present themselves in a few different ways:
As an environment that allows the application to scale in a way that grows without becoming a noisy neighbor
As an infrastructure that treats all workloads fairly, regardless of their purpose
In security controls, logging, and a long-running service manager included (standard)
Most importantly, the app should not be changed once it enters the production environment. By answering some fundamental infrastructure questions, we can ensure, no matter where the application lands, that it can be happy and healthy. Eric Jeanes is a recovering systems administrator with a passion for cloud tools and services. He likes people, but thinks organizations are more interesting. He currently develops cloud technologies for Internet2, a higher education community organization, and can be found on Twitter @emjeanes.
