ActiveBlog

DevOps: Self-Service
by Phil Whelan

Phil Whelan, February 17, 2014

Piggly Wiggly Have you ever strolled down the aisles of a grocery store, found the items you wanted, checked the prices, put them in your basket, then headed off to the checkout? Of course you have. This is what is known as "self-service". This is also a term that is becoming familiar to software developers. Providing self-service should be included in the mandate of modern IT Operations teams.

Piggly Wiggly

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.

Piggly Wiggly Store 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, continually redefined processes, iterated on those processes and he innovated. If he was in IT, he would encompass what we refer to as DevOps.

History Lessons

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?

Efficiency

Why is self-service a good thing?

Piggly Wiggly Store 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.

Cost

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.

[White Paper: PaaS —The Foundation of Enterprise DevOps]

Full-Service Ops

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?

Trust

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.

Complete Self-Service

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.

Innovation

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 PaaS

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.

Conclusion

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.

Share this post:


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,


View Comments

DevOps: Hero Culture

Firefighters are the ones who are often up at 3am frantically trying to keep systems online.

Sometimes they are too busy putting out fires to step back and look for preventative measures. Fire fighting is a noble job, a job for the brave, it saves companies from outage, from loss in revenue, from loss due to bad publicity. Yes, it is a job for heroes. And this is where the problem lies.

Read more...

This Is PaaS. Confused?

There is a lot of confusion about "PaaS" and what it means. The definitions are vast, vague and varying. The market and the media are understandably confused.

Read more...

And That Was DevOps Days Atlanta

Last week I was lucky enough to have ActiveState pay for me to travel to and attend DevOps Days Atlanta. I was also selected as a speaker. In this post I am going to summarize my experience and hopefully give others, who might be thinking of attending one of the many other DevOps Days that happen around the world, an idea of what they are in for.

Read more...

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

Phil Whelan has been a software developer at ActiveState since early 2012 and has been involved in many layers of the Stackato product, from the JavaScript-based web console right through to the Cloud Controller API. Phil has been the lead developer on kato, the command-line tool for administering Stackato. Phil's current role is a Technology Evangelist focused on Stackato. You will see Phil regularly on ActiveState's Blog. Prior to coming to ActiveState, Phil worked in London for BBC, helping build the iPlayer, and Cloudera in San Francisco, support Hadoop and HBase. He also spent time in Japan, where he worked for Livedoor.com and met his wife. Phil enjoys working with big data and has built several large-scale data processing applications including real-time search engines, log indexing and a global IP reputation network. You can find Phil on Twitter at @philwhln, where you can ask him any questions about Stackato. Alternatively, email at philw at activestate.com