Different Approaches to Infrastructure as Code (IAC) by Devs and Ops
Over my 35 year IT career, I have predominantly been in Ops roles, however I have performed some development work in the past. During the last 10 years as IaC has become more prominent, the title of this article has become an interesting topic and I believe highlights some substantial differences in approach and mentality between these 2 groups of engineers in a typical organisation.
For developers used to designing and coding applications, designing and coding IaC is different and many developers struggle with this very different task. Surely code is code, why is it such a difficult challenge? The priorities are very different, user interface, user experience all typically are very low on the list of requirements for IaC and often reliability and above all integration into an existing ops world are the higher priorities. Typically IaC has to fit in to an extensive already existing Operations eco system and this is where I see many application developers struggle. It takes an open mind and often years of experience to grasp the operations mindset. In an ideal world if code and design is perfect then the typical what if scenarios ops encounter on a daily basis shouldn't happen, but that isn't the realistic world we live in.
So what is the Ideal Solution?
Ideally any IaC should be a collaboration between resources. It should be fairly straight forward:
What Actually Happens?
Typically one of 2 methods will take place:
Recommended by LinkedIn
Developers will design and code a solution without regard for Operational requirements.
Developers not understanding operational practices can place a huge operational burden on staff. A spinup takes minutes often to run, but a non ephemeral asset may be around for years. For non ephemeral instances, operational requirements are the most important aspect. Not understanding and accepting operational requirements, especially for non ephemeral instances can have a lasting effect for years to come in terms of staff required and cost.
Operations will design and code a solution without the skills of Developers.
Although Ops are experts in Operations, often they lack any formal training in terms of application design and coding. Operational experience is varied, some staff know many languages, whilst others have never really coded, in some rare cases some operational staff have not even scripted. Having said this, many operational staff have scripting and coding skills similar to application developers but sometimes lack the formal training and experience. Typically however this option does result in often sub standard code. It may not be elegant, may be a bit "rough and ready" and may even not be reliable in places.
Conclusion
Obviously the ideal solution is for collaboration to take place, but in my personal experience this is harder than it seems, sometimes individuals, teams and even management are not open minded enough for this to work. But often in the more common outcomes I tend to find that Ops staff can adapt to IaC coding easier than application developers. It appears to be easier for Operations to learn a language to a sufficient level than for developers to learn and understand the operational mindset.
What is your experience?
You are absolutely right. My personal experience about what is causing the most issues on software integration in enterprise environments where tasks are split over too much internal and external ressources: project managment thinks it's duty stops where integration starts. The consequence is a lack of collaboration as people with a non project managment mind and too much daily business duties need to deal with people management.
I really like what you have to say here Richard, from my experience I have yet to see the full "nirvana" of IaC emerge because it's usually thwarted by the human aspect - power and ego, Software thinks Ops is living in the past century, Ops thinks Software has no clue on how to run and operate code - these are fundamentally different disciplines with different perspectives, neither of which is absolutely true, or wrong for that matter. I think this may also speak to a larger issue within Tech, as if we don't have enough, but for as many Comp Sci programs and courses there have not been nearly as many focused on technology operations which means as a discipline there is much to be desired.I think the assumption is Ops is sort of like a utility service which on one level undermines the important of the service they provide. Whereas Software is looked at as some sort of coding sweat factory, just churn out code and deliver whatever we think will make money which has its own set of issues all together included code that is never used or tested. One thing is for certain, put the right leader in the mix and you won't have attrition, you will hit your deliverables, and most importantly team morale will be at an all-time high 😎