I\u2019m Lee Gardiner, I\u2019m currently the Head of Infrastructure & Service for the Collinson Group and I adore technology transformations, cloud migrations, and being a leader.<\/p>\n
Over the years, I\u2019ve seen many differing opinions as to \u201cWhat is DevOps?\u201d<\/em> and typically when I ask the question in interviews, I\u2019m given differing answers. In this article, I\u2019d love to describe what DevOps is to me as well as my observations.<\/p>\n I\u2019ve been fortunate to see DevOps transformations at scale as well as false starts. When I initially started looking at DevOps, it scared the life out of me \u2013 \u201cEngineers with version control, ChatOps and being friendly with Developers, madness!\u201d – \u00a0Developers were the enemy, they force change with no regard to our wonderful running systems that we barely monitor!<\/p>\n So what changed?\u00a0 <\/em>For me, it was seeing a business I loved close and 500 people out of a job, literally the worst-case scenario of the Phoenix Project (if you haven\u2019t read it, please do). This was one of the worst experiences of my professional career and, in hindsight, it was already in motion well before I joined.<\/p>\n The realisation that my goal is fundamentally the same as a Developers put me onto a DevOps path, working closely with Developers for shared goals and my personal favorite bit of DevOps \u2013 shared wins.<\/p>\n In digital transformations, businesses typically upskill SysAdmins into DevOps Engineers (I\u2019m not a fan of the title, but it\u2019s one I\u2019ll not fight for now), businesses throw brand new tools at engineers, send them on training courses, and Voila:\u00a0<\/em>DevOps Engineer, still in an infrastructure team and not really providing any major benefits to the business, we refer to this as DevOps as a function and in my opinion, it’s missing the point entirely.<\/p>\n DevOps to me is about that shared win, about providing velocity to the business, its processes, and its staff, and it’s why I\u2019m a fan of the scaled agile framework. There are clear and concise ways of implementing DevOps into your organization.<\/p>\n Medium to long term DevOps Engineers run in a chapter, embedded in development squads, and evangelise all things DevOps while embracing shared goals and shared wins. Which is wonderful and will return immense value and lower time to markets, but what next?<\/p>\n Consider the abstractions that we\u2019ve made from a SysAdmin to DevOps engineer<\/p>\n Network Layer \u2013 Abstracted due to Cloud<\/em><\/strong><\/p>\n Server Hardware Layer \u2013 Abstracted due to cloud<\/em><\/strong><\/p>\n Operating System Layer \u2013 Abstracted due to containerisation<\/em><\/strong><\/p>\n Monitoring \u2013 Now as code, shared by all<\/em><\/strong><\/p>\n CICD \u2013 Now as code, shared by all<\/em>\u00a0<\/strong><\/p>\n While it\u2019s amazing to go down this journey, the leap I mentioned before means we are now closer to being a Developer than a SysAdmin! We continue to abstract these layers and make it less and less complicated to run applications in a scaled, safe, reliable fashion.<\/p>\n The end goal and the aim is to transition away from DevOps Engineers into Developers, and we will no doubt get there while continuing to embrace and evangelise further abstractions away from infrastructure. DevOps just becomes something we in technology do and we\u2019ll see other specialisms absorbed into this view with the likes of QA\u2019s and DBA\u2019s not being too far down the track.<\/p>\n I hope I\u2019ve not bored you too much with my personal idealistic view of DevOps and I welcome any and all feedback you\u2019d like to send my way.<\/p>\n <\/p>\n When I started as a Jnr SysAdmin many moons ago, the first sign of an issue was generally an angry customer at the other side of a ticket, monitoring was done in a black box manner (basically checking if a port was open or not) and the only true monitoring was done around bandwidth consumption to ensure correct billing.<\/p>\n Over the years, the way we monitor systems and the amount of logging we do out of the box has changed dramatically. We now find ourselves with the reverse problem in that we\u2019re swamped with alerts and logs.<\/p>\n As a leader, my role is made considerably less complicated by being data-centric, the metrics that are important to me are shared, transparent and on my part, memorised for usage throughout the week.<\/p>\n As an engineer, my role was made considerably easier having accurate chaos engineered data, simulating environment failures, and having predictability, typically while we may <\/em>log data \u2013 are we actually <\/em>putting it to work?<\/p>\n Data logged must be of use to someone, somewhere, otherwise, there is little to no point in storing it let alone triggering alerts or actions off it, the fight to reduce noise is not a straightforward one to win and will take true collaboration to achieve.<\/p>\n It is therefore vital to have well-defined guardrails or operational acceptance tests to ensure prior to a service going live we define how it should log and on what events we need to be alerted upon. Services that are live prior to these processes should be reviewed and improved as part of the application\/platform lifecycle.<\/p>\n \u201cIsn\u2019t this where SRE\u2019s come into play?\u201d<\/em> \u2013 this is a shared goal and a shared win, something we as engineers should be focussing on to improve the customer experience.<\/p>\n Put your data to work, be transparent on it, and be critical with it if it\u2019s not providing value, like anything else this is another area of constant change, constant advancements, and more importantly constant learning.<\/p>\n <\/p>\n Written by Lee Gardiner, Head of Infrastructure & Service at Collinson<\/strong><\/em><\/p>\n","protected":false},"excerpt":{"rendered":" I\u2019m Lee Gardiner, I\u2019m currently the Head of Infrastructure & Service for the Collinson Group and I adore technology transformations, cloud migrations, and being a leader. Over the years, I\u2019ve seen many differing opinions as to \u201cWhat is DevOps?\u201d and typically when I ask the question in interviews, I\u2019m given differing answers. In this article,…<\/p>\n","protected":false},"author":123458,"featured_media":24014,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","pmpro_default_level":"","footnotes":""},"categories":[3490,3480,2],"tags":[284,448,67],"yoast_head":"\n<\/h3>\n
Part I – What is DevOps?<\/strong><\/h3>\n
Part II \u2013 Data at your fingertips<\/strong><\/h3>\n