Welcome!

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

Related Topics: @DevOpsSummit, Microservices Expo, Containers Expo Blog, Agile Computing, SDN Journal

@DevOpsSummit: Blog Post

Four Essential Hacks for Newbies By @Aruna13 | @DevOpsSummit [#DevOps]

So congratulations, somehow you've managed to wangle your way onto DevOps Summit at Cloud Expo

Four Essential Cultural Hacks for DevOps Newbies

So congratulations, somehow you've managed to wangle your way onto one of the many DevOps conferences being held around the world. Why not you might say? DevOps is not only hot it's the approach many enterprises are now exploring as the means to help accelerate the delivery of high quality software.  And with 2014 marking the 5th year for DevOps, maybe that's double cause for celebration; you're once again hooked on an new exciting trend (well newish) and its tailor made for your organization, right?

Now you're ready to rock and roll; eager to impress your boss, colleagues (and really anyone who cares listen) on how DevOps is the next best thing for IT and the business since sliced bread. And, just like any five year old, you're ready to charm your way into conversations; using funky terms like anti-fragile, anti-patterns, feedback loops, learning from failure, Lean IT, Kanban boards and continuous delivery.

But there's a problem. Back at castle enterprise you hit a brick wall. Perhaps folks will politely listen, but you really suspect that they're just paying lip-service to your fresh-faced ideas. Worse still some of your suggestions are greeted with stony silence or gasps of incredulity, or in extreme cases (and just like many five year olds) you're scolded and admonished for your new found dash. So it's off to the micro-management naughty room or back to putting covers on your TPS reports (ala Office Space) - how dare you question a culture based on "when it's not broken, we don't fix it."

So with your youthful hand firmly slapped for daring to approach the parental enterprise cultural cookie jar, is there really anything you can do to infuse the organization with a DevOps vision?

Perhaps, but it won't be easy. Organizational culture and workforce transformation are major initiatives usually mandated and driven from the very top, meaning there's probably no immediate magic pill. Especially if your enterprise structure is swamped with senior managers whose job titles should really reflect the atmosphere of friction prevailing within the organization - like VP of Insidious Bureaucracy or Senior Director of B.O.G.S. (Blaming the Other Guy and Saving the Day).

But rather than immediately throwing a tantrum, collecting your toys and leaving the organization, what practical steps can you take and what should you avoid when trying to endear the value of DevOps upon the business?

Here are four examples, which like those in early development are based on taking small but important steps:

Speak slowly and take that food out of your mouth - Ok, so you know lots of DevOps, Lean and Agile terms, like Value Stream analysis, cycle times, retrospective and continuous improvement. You might even be bold enough to "Genba walk" your way into another team's processes; pointing out all the wasteful activities and casually proposing some practical improvements. Of course this might be fine if your language and actions represent standard vernacular of the business (e.g. lean manufacturing), or if agile is used in development - but be careful.

Terms like Minimum Viable Product, Failing Fast and Technical Debt might connote something really bad and unpalatable to business users, so my advice is to be prepared moderate all the DevOps jargon by demonstrating value with user-centric stories.

You show me yours and I'll show you mine - we're taught to share our toys at an early age, so why do we crave ownership of the toys in the workplace - toolsets? Sadly, some have been architected that way to singularly support functional silos and technology fiefdoms. Now, however, tools and methods are being designed to support and stimulate cross-functional collaboration and feedback. Like for example modern application performance management, which when established within non-functional testing can help development meet both speed and quality objectives.

Hold some parties and play nice - you don't have to wait for the next DevOps conference to convince like-minded colleagues on the value of DevOps - you can start your own. With a smattering of management sponsorship you can perhaps develop internal mini-conferences or cross-team hacks. Failing that if you work in operations go ahead and crash the next agile stand-up meeting or retrospective. Remember too you'll most likely work in a "multi-cultural" setting, so don't decry any established best practices like ITIL, COBIT, CMMI and balanced scorecard. At best you'll just tick off a number of folks and at worst you'll be on your way to establishing a separate, siloed thought practice - that's an anti-pattern and not what you should be striving for - collaboration and co-existence.

Show off all those awesome gold stars - it's easy to get carried away with impressive sounding metrics like time-to-value and market share, but I'd caution anyone against initially setting your goals too high. A better approach is to look for performance indicators that drive change and incentivise behaviors, especially those that can be shared across teams. These can include metrics to demonstrate service quality (e.g. deployment success rates), service velocity (e.g. deployment frequency/cycle times), and customer value (e.g. response times, lead times and netpromoter scores).

Once you've had some wins don't rest on your laurels. Start tracking immediately to demonstrate the value of DevOps behaviors, tools and processes, never forgetting to share the credit and celebrate any successes, however minor they might be.

Influencing organizational culture is a tough nut to track, but not impossible since it's based on sets of behaviour -- which can be influenced. This may start with small baby steps in collaboration and DevOps style experiments or with executive sponsorship. Never forget, however, that there will be setbacks, so start honing the next "C" word in your DevOps dictionary - Courage!

More Stories By Aruna Ravichandran

Aruna Ravichandran has over 20 years of experience in building and marketing products in various markets such as IT Operations Management (APM, Infrastructure management, Service Management, Cloud Management, Analytics, Log Management, and Data Center Infrastructure Management), Continuous Delivery, Test Automation, Security and SDN. In her current role, she leads the product and solutions marketing, strategy, market segmentation, messaging, positioning, competitive and sales enablement across CA's DevOps portfolio.

Prior to CA, Aruna worked at Juniper Networks and Hewlett Packard where-in she led executive leadership roles in marketing and engineering.

Aruna is co-author of the book, "DevOps for Digital Leaders", which was published in 2016 and was named one of Top 100 The Most Influential Women in Silicon Valley by the San Jose Business Journal as well as 2016 Most Powerful and Influential Woman Award by the National Diversity Council.

Aruna holds a Masters in Computer Engineering and a MBA from Santa Clara University.

@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...