Originally Published in 2015
A consistent theme has been a push from my customers for faster turn around on requests, more flexibility and a push for more & more changes.
For example, during a face to face discussion with an existing customer, he quite forcefully stated that he wanted to build the most "reactive organization" possible. At the time this statement took me aback, especially in the middle of a conversation regarding better planning to get ahead of their requests.
How can you not plan and know what's going on ? How can you not know in plenty of time?
My reaction is VERY typical of traditional IT operations and specifically managed hosting service providers...after all our job is to keep our clients environments running smoothly. in order to meet our "3,4,&5 9" SLA's, change is planned and in an ideal world, avoided at all cost !!!
Back to the story, As we worked with this customer we were able to pin point specific causes of high volume changes. We worked together, made some simple infrastructure and operational changes and enabled the customer to use their existing Puppet infrastructure.
The net result, automated changes > reduced trouble ticket's > increased operational velocity > minimal impact.
Recently I was having a similar conversation with a new customer. He expressed the same desire for speed and flexibility and so we were able to build in these architectural elements from the start.
One example of a simple, but effective, change is to use port tagging or trunking from the network ports to the physical servers. This allows the operating system to manage the VLAN based on server role, rather than using access ports on the switches.
Note for those of you that are familiar with with virtualization and the virtual switches in VMware and Xen, this is nothing new, however in the physical rather than virtual world this was a step forward.
On an related but unrelated note, a friend and I were recently talking about the struggle between and Agile development methodology and typical IT Operations. He introduced me to the term "DevOps". After a little reading, these recent discussions with customers started to make a lot more sense.
Wikipedia has a decent Primer here.
There were some key phrases that jumped out at me.
"Flickr supporting 10 deployments per day"
Continuous deployments
Lean startup methodology (Rapid Prototyping)
Reduced Change Scope / More Frequent Changes
Increased release co-ordination
Automation
These statements tied back the customer conversations I'd been having for a year but no-one had used the term DevOps.
Since coming across DevOps I have spent some time digging into the concept and thinking about how I would have to modify our operations and technical architecture to really meet customers demanding this level of agility.
In part's II - VI I'll dig into the details.