Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Roger Strukhoff, Liz McMillan, Stackify Blog, Pat Romanski

Related Topics: @DevOpsSummit, Microservices Expo, Linux Containers, Containers Expo Blog

@DevOpsSummit: Article

Taking Back IT - DevOps | @DevOpsSummit #DevOps #APM #Microservices

The Digital Transformation and the process that powers it

Part 1 - How do I get started making the transition to DevOps?

I am an ops guy. I have been in Ops since I started my career a long time ago. I still remember the glorious days of being the new guy on the Ops team and getting stuck with changing backup tapes. I remember moving servers in the wee small hours of the morning, upgrades that went horribly wrong with no prayer of reverting, and the joys and pains that went with being in operations, and really what we would call "Legacy IT" in general. It's like the opposite of "Cheers", because you want to be where NO ONE knows your name; if people know who you were in those days of IT, you were having a bad day.

It was around the year 2000 though that something finally broke lose. At the company I was at, Operations stopped just simply reacting to things that happened and decided to try and get in front of things. Not in a comprehensive, complex way, but through the simplest and most crucial tool for DevOps; we went and actually talked to the Dev team. It's not glamorous, or cool, it has no lights and fancy graphs and dashboards, and it most certainly isn't something you can buy, but your voice is the single most effective and powerful DevOps tool. As the lead of the server and operations team at the time, I went to the application team and asked them for a roadmap of what they were doing, and asked them if we could meet together and talk about upcoming stuff. Seems pretty simple, right? This was radical stuff though, back in prehistory, and while we didn't always get out of fire-fighting, we got a lot better and we made progress.

Fast forward 5 years and the company I am leading IT for is undergoing significant infrastructure changes to support increased Development of applications, and streamlined Operations. Sounds like DevOps! Except we had a problem; Dev and Ops were friends and we liked to talk and do great things. The problem is, we never bothered to tell anyone else in the company about all the great things we were doing. We had to fight the business to get approvals to make even minor changes because we had forgotten the most important tool for DevOps isn't just for Dev and Ops! So I did something "radical" again, and went and showed the business unit stakeholders (the head of the Peoplesoft team, the DBA group leads, the Finance department head, the head of HR) the data center, their equipment, and most importantly our plans for it and what they would get from it when we were done. Guess what? I never had to argue for downtime again and we were able to consolidate and optimize our datacenter and move to our new systems in record time. Why? I used the most important tool of DevOps and got the business to believe in what we were doing by showing them not just the what, but the WHY.

I am telling you this because as you embark on the journey to the Valhalla that awaits us in DevOps land, I want you to always remember the golden rule of DevOps: All the software, fancy hardware, unit and integration testing, performance monitoring, and overall execution metrics in the world mean exactly nothing to anyone if you don't talk about them first. That's not a small thing to ask of IT people; we shun the limelight and we tend to try and stay anonymous, but it will kill your DevOps initiatives faster than any outage ever could.

The steps to achieving DevOps are actually simple to map, but much harder to do:

1) Talk amongst IT and get them bought in to the shift to really being a DevOps shop, not just talking about, but DOING IT

2) Talk to the key business stakeholders and get them bought into the OUTCOME of the shift to DevOps in real terms (as an example, by us moving to virtualized infrastructure and systems, we could get Peoplesoft up and running in the event of a borked upgrade in under 30 minutes - that is a real and most importantly MEASURABLE outcome)

3) Go back to work and choose the tools and techniques that will make it the easiest to execute on the plan and achieve the agreed on outcomes

Notice how I didn't pick a tool until I got everyone to agree? That's because you can pick all the tools you want before you get the plan and the buy-in in place, but you are just wasting time; if the tools do not support the outcome, you are going to have to start over. So take the first step by talking and agreeing to the plan. Then like I have over the years, you will be ready to wade in and start thinking about the actual nuts and bolts of DevOps. Something we will be talking about in greater detail as we progress in this series of blogs.

Have any topics you want to know more about or see more on? Let me know either in the comments or via twitter: @charrold303

For the full series on IT Transformation and DevOps, visit my mini-series on LinkedIn.

More Stories By Christopher Harrold

As an Agent of IT Transformation, I have over 20 years experience in the field. Started off as the IT Ops guy and followed the trends of the DevOps movement wherever I went. I want to shake up accepted ways of thinking and develop new models and designs that push the boundaries of technology and of the accepted status quo. There is no greater reward for me than seeing something that was once dismissed as "impossible" become the new normal, and I have been richly rewarded throughout my career with this result. In my last role as CTO at EMC Corporation, I was working tirelessly with a small group of engineers and product managers to build a market leading, innovative platform for data analytics. Combining best of breed storage, analytics and visualization solutions that enables the Data as a Service model for enterprise and mid sized companies globally.

@DevOpsSummit Stories
Docker and Kubernetes are key elements of modern cloud native deployment automations. After building your microservices, common practice is to create docker images and create YAML files to automate the deployment with Docker and Kubernetes. Writing these YAMLs, Dockerfile descriptors are really painful and error prone.Ballerina is a new cloud-native programing language which understands the architecture around it - the compiler is environment aware of microservices directly deployable into infrastructures like Docker and Kubernetes.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throughout enterprises of all sizes.
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embracing the reality of Serverless architectures, which are critical to developing and operating real-time applications and services. Serverless is particularly important as enterprises of all sizes develop and deploy Internet of Things (IoT) initiatives.
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and controlling infrastructure. The rise of Site Reliability Engineering (SRE) is part of that redefinition of operations vs development roles in organizations.
When a company wants to develop an application, it must worry about many aspects: selecting the infrastructure, building the technical stack, defining the storage strategy, configuring networks, setting up monitoring and logging, and on top of that, the company needs to worry about high availability, flexibility, scalability, data processing, machine learning, etc. Going to the cloud infrastructure can help you solving these problems to a level, but what if we have a better way to do things. As a pioneer in serverless notion, Google Cloud offers a complete platform for each of those necessities letting users to just write code, send messages, assign jobs, build models, and gain insights without deploying a single machine. So cloud compute on its own is not enough, we need to think about all of the pieces we need to move architecture from the bottom, up towards the top of the stack. Wi...