Join the DZone community and get the full member experience.Join For Free
Prior to 1916, if you went into a grocery store, you would have to present a list of the things that you wanted to buy to a store employee. The store employee would then escort you around the store and gather the required items for you.
In 1916, Clarence Saunders changed all this when he invited his customers to gather the items they wanted themselves and present them to a cashier. This was so revolutionary that in 1917 the US patent office awarded him a patent for his "self-service store". This spawned a chain of now 600 Piggly Wiggly self-service grocery stores.
Piggly Wiggly was also the first store to provide checkout stands, price labeling and shopping carts. Clarence Saunders was an innovator that did not just follow the status quo. He looked at the bigger picture, constantly redefined processes, iterated on those processes and he innovated. If he was in IT, he would encompass what we refer to as DevOps.
It is hard to imagine life before self-service in grocery stores. For developers and young startups growing up with cloud solutions like Amazon Web Services, Heroku and Engine Yard, self-service is already becoming the norm. Some of these folks probably cannot even imagine a world before this.
When we look back at the past, we tend to chuckle at the folly of our ancestors, doing things in a way that, to us, seem obviously inefficient. Hindsight is a wonderful thing. Rarely do we have the foresight and mental capacity to project into the future and see that what we are doing is probably just as archaic to our future selves as bashing two stones together seems to us.
What insights can Clarence Saunders give us into what we are doing wrong in our future's past?
Why is self-service a good thing?
Maybe you like the idea of a store assistant leading you around the store, collecting your groceries and placing them on the counter. We all like to be pampered - occasionally. This is why they invented spas.
Unfortunately, it is very inefficient for you and for the store.
When you are in a rush, this is going to be less desirable. You would have to wait for the next available store assistant to guide you around the store and collect things at their pace. As you navigate the store, the assistant will tell you all the latest products and ask you if your Uncle Frank has made it out of the hospital yet. Popping to the store just for a pint of milk, starts to make the prospect of buying a cow seem rather appealing.
Full-service is not cheap. Clarence Saunders realized that he could dramatically decrease his workforce by not escorting customers around the store. He could focus a much smaller work-force on the more important tasks of accepting money from the customer and packing their groceries. These savings he could then be passed on to his customers.
He probably also freed up his own time to work on the further innovations that followed, such as the price labeling, shopping carts and checkout stands.
The current state of developing and deploying applications is much like the full-service grocery stores of the early 20th century. In most large organizations, developers still rely heavily on Operations for too much of their infrastructure needs. When a developer decides he or she needs resources for running their application, they need to wait for the next available Operations team member to help them. This is usually via a ticketing systems, and may not be a one-to-one relationship, but the effect is the same.
Once the Operations engineer has the list of requirements from developer, they will navigate the existing resources and select appropriate solutions for the developer, configure them, secure them and ready them for the developer you use. All the time the developer waits.
What if developers had the capacity to gather their own resources themselves? What if the processes around gathering resources were such that developers could see the cost of resources, try different resources and checkout resources against their available credit? What if they could also easily return resources that were no longer required?
We see some Operations engineers not wanting to lose control of their environment. This often leads to a complete dismissal of self-service solutions that empower developers. In 1918, when word began to spread of Clarence Saunders' self-service stores, I am sure that many other store owners thought he was a little foolish in his endeavours. They might have scoffed that he did not really understand the business he was in; "We cannot have people just wandering around the store and touching merchandise. What if someone damages something? What if someone steals something?!". Yes, people steal and things break, but the net gain of self-service greatly outweighs these costs. To take this leap of faith, Clarence Saunders ultimately had to trust his customers in aggregate.
Fast-forward to the 21st century and stores now have video surveillance, resident security guards, RFID tags, one-way doors and store layouts designed to make shoplifting more difficult. Where is the trust now?
Trust has been replaced by process and better technology.
It took another 100 years, but grocery stores are once again going through another big change. Self-service is now available for the checkout process, too. Some might say that they are moving more to NoOps than DevOps. Some would disagree.
Even with these additional innovations, we still see store assistants assisting. They still stack shelves and ensure the smooth running of the store. Although, once again, we will see a drop in the number of store assistants. Will also potentially see lower prices passed on to the customer.
I would like to imagine that all those redundant employees were somehow reinvested into the company. They could be taken to the Innovation Department, where they brainstormed new ways to make the store operate more efficiently. Maybe this would reduce the 100 year innovation cycle.
In technology, we are innovative in our nature. If we improve our processes and free up our time, we generally look for the next source of innovation. Although, some of us are more innovative than others.
There are many definitions of "DevOps". I think it can be a term that distinguishes the more innovative Operations Engineers from less innovative Operations engineers. Those who are constantly trying to improve processes, rather than simply be an actuator of existing processes.
You only have to visit a DevOps Days event to see these folks are hungry for change and better ways. Those that encounter DevOps for the first time, and engage with others, are inspired to be just as innovative. It is contagious.
What happens to those that do not innovate? Mark R. White addressed this at DevOps Days Atlanta, in his talk "Don't Fear the DevOps!". You have to keep up with innovation if you want to survive. I am sure Clarence Saunders put a few of his more stubborn competitors out of business.
Self-service for developers is central to PaaS. It is an application platform managed by Operations teams and used primarily by developers. It is way to empower developers to get what they need to support their applications quickly, with a simple checkout system.
We are seeing tremendous flexibility in the PaaS offerings becoming available on the market. This flexibility comes at the Operations level and the developer level. We need this flexibility to support legacy applications, while also promoting the new paradigms the era of cloud offers us.
It is inefficient for Operations teams to manage the individual needs of developers and applications. Developers should be able to select and provision their own needs.
The Clarence Saunders' of DevOps are already out there. They are deploying solutions like OpenStack and Stackato. These early adopters see the benefit of self-service. They are already reaping the benefits and getting the same head start that Clarence did.
If you are looking for more information about Platform-as-a-Service, what it is and how it differs from other cloud orchestration software, view the recording of ActiveState's webinar from February 12th 2014.
Published at DZone with permission of Phil Whelan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.