devopsy.kinsta.cloud

Category: Blogs

Webinar: Scaling Web Applications with NGINX Load Balancing and Caching
Building out a web server is easy, but things get much more complicated as you add the load balancers and caching servers. Optimal configuration for these require considerable expertise in the area and ensuring high performance as the site grow is increasingly complicated. In this webinar, Datadog and NGINX will show you:
- How to configure the optimal load balancer and caching server
- What are the key metrics to watch to ensure optimal performance
- Where to find help when you need it
Join Rick Nelson, Technical Solutions Architect at NGINX and Matt Williams, Evangelist at Datadog to learn how to create a robust web environment to keep it running at full speed.

Event Recorded Wednesday, May 27th, 2015

VIDEO

SLIDES

[seoslides embed_id=”115e9ad4f5ea” script_src=”https://devopsy.kinsta.cloud/embed-script/scaling-web-applications-with-nginx-load-balancing-and-caching-3/7485/” overview_src=”https://devopsy.kinsta.cloud/slides/scaling-web-applications-with-nginx-load-balancing-and-caching-3/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Scaling web applications with NGINX load balancing and caching” /]

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Rick Nelson is an industry expert in hosting and server services and joins NGINX as the lead Technical Solutions Architect. Rick helps clients large and small manage load balancing and optimize for web performance in today’s quickly evolving digital and mobile age.

Matt Williamss the DevOps Evangelist at Datadog. He is passionate about the power of monitoring and metrics to make large-scale systems stable and manageable. He tours the country speaking and writing about monitoring with Datadog and when he’s not on the road, he’s coding. You can find Matt on Twitter at @technovangelist.
April 30, 2015
Webinar: IT Decentralization: How to speed up your organization safely
New technology developments like DevOps, IaaS, and SaaS allow organizations to do more and make faster decisions with fewer staff and less budget. But, allowing anyone within an organization to deploy the technology they want with virtually no centralized oversight is a recipe for disaster. In this webinar DevOps evangelist and author Gene Kim and JumpCloud CEO, Rajat Bhargava, discuss how modern IT teams build decentralization into their organization while maximizing the security that their IT team needs to keep their organization safe.

In this webinar, you will learn how to leverage decentralization safely to increase the pace that your business operates. Gene and Rajat will discuss actionable steps and controls for the following areas:
- Hybrid Infrastructures
- DevOps culture
- BYOD workplaces
- SaaS Apps
- Remote workers
- Wifi access points
- Software Applications
Recorded: Wednesday, July 1st, 2015

[seoslides embed_id=”8f9a76b5e74b” script_src=”https://devopsy.kinsta.cloud/embed-script/it-decentralization-how-to-speed-up-your-organization-safely/8416/” overview_src=”https://devopsy.kinsta.cloud/slides/it-decentralization-how-to-speed-up-your-organization-safely/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”IT Decentralization: How to speed up your organization safely” /]

Post-Webinar Q&A:

Q. If an IT organization is supporting software development but it is not Agile, does DevOps methodologies make a difference?

A: Yes, as we mentioned previously, you’ll want to adjust your DevOps methodology to match your particular situation. Some organizations use Kanban instead of DevOps. The key here, though, is to build a process that is iterative and works to drive value on an incremental basis. – RB

Q. I can see how Web Services, SPAs, and APIs can be done easily this way, but do you do ‘legacy style’ stateful web apps this way as well? If so, how do you deal with deploying mid process blowing up the user’s application state?

A: Yes, of course, DevOps can be leveraged for ‘legacy applications’. You will alter your test / release process to ensure that you don’t ‘blow up a user’s application state’. DevOps is a methodology and not a prescriptive process. You’ll adjust the process to match your particular situation, and, of course, that can include how you deploy more ‘thick’ applications. – RB

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Gene Kim is a multiple award-winning entrepreneur, the founder and former CTO of Tripwire and a researcher. He is passionate about IT operations, security and compliance, and how IT organizations successfully transform from “good to great.”

Rajat Bhargava is co-founder and CEO of JumpCloud, a provider of Directory-as-a-Service solutions. An MIT graduate with two decades of experience in industries including cloud, security, networking and IT, Rajat is an eight-time entrepreneur with five exits including two IPOs, three trade sales and three companies still private.
April 30, 2015
Why I’m Happy To Have DevOps Engineer In My Job Title

A recurring argument in the DevOps community is whether the word DevOps should exist within a job title. Most people close to DevOps think it’s a potentially harmful anti-pattern which indicates a misunderstanding of what DevOps is all about. A few years ago I agreed with this, but I’ve now changed my mind.

Yes, DevOps is a culture, a mindset and all of those good things. It is about how people work together much more than automation. I also appreciate the argument that labelling individuals and teams with DevOps potentially introduces a silo where we are trying to solve a problem of siloes.

With all of that recognised, I’m still more than happy to now call myself a DevOps Engineer.

There were lots of job titles that didn’t exist 10 years ago. Agile Coaches, Social Media Managers, Data Scientists and Mobile App Developers for instance. Those fields evolved and there are now recognised experts in those fields who know how to apply the tools and help organisations be successful with them.

DevOps is the same. It is maturing as a movement and there is now enough specialist knowledge in the niche that people can build significant niche expertise, work within it full time, and even build long term careers as DevOps Engineers.

Definition Of A DevOps Engineer

DevOps Engineers are the people who sit between or within Development and Operations and use automation across the SDLC to reduce the cycle time from development to production.

These Engineers will bring knowledge across Development, Testing and Operations and help with gluing those areas together to ease the transition of code across them.

They will have deep technical skills in tools such as Puppet, Chef, Ansible, Vagrant and Docker, and use these tools to help their organisations deliver better software, faster and more reliably. They will also likely understand cloud and how to use infrastructure automation to leverage this to best effect.

As important as the technical knowledge is what we call the ‘DevOps Mindset’ – a personality type and approach that can help the IT organisation move from traditional ways of working, break down siloes, and collaborate more effectively. Technical skills alone do not make an effective DevOps Engineer.

Why This Matters

To me, this all sounds meaty enough to be a full time role and a career path. Therefore, why shouldn’t it also have it’s own name to identify it by?

I’ve always been pragmatic about this, but my main interest in this is how accepting DevOps Engineers as a job title might help to overcome the DevOps skills crisis – the huge shortage of people in industry who have this skill set and the fact that as an industry, we have still have no sustainable path to creating these people.

By accepting DevOps Engineers as a job and a career path, I think the definition of one would become more concrete. There would be more of a shared understanding over what it means, rather than savvy build and release engineers or system administrators re-badging themselves.

More people could align themselves to DevOps Engineering and work towards obtaining this recognised skill set.

Visibility of DevOps activities within the business would grow, and budgets would be created to support DevOps rather than it being an under the radar activity happening under other functional siloes.

Training for DevOps Engineers might emerge, and one day, it might even end up as a University Level course.

All of these things would help DevOps expand as a movement and practice in industry, which is ultimately a good thing for the sponsoring organisations and anyone who works in IT. Here at Contino, the more we interact with customers around DevOps, the more I realize this is the path things should take.

April 30, 2015
Webinar: Ship Faster without Breaking Everything

There’s a lot of noise in the market about what DevOps is and how to do it. Some might say that it’s more easily defined by what hasn’t been said about it. If you’re not interested in arbitrary definitions or doing something just for the sake of doing it, this webinar is for you.

You have critical business goals to achieve: to ship software faster without breaking things in the process. But manual, error-prone infrastructure and environments, plus an increasingly complex end-to-end process of getting code from development to production, present serious challenges.

Join SaltStack and XebiaLabs on May 21^st, 1pm EST for a 45-minute session that will examine these challenges and show how the combination of XL Release, XL Test and Salt accelerates software cycles. Learn how XL Release, XL Test and SaltStack deliver advanced automation capabilities, enable data-driven improvement and provide continuous insight into your end-to-end software release process in a way other tools simply cannot.

Event Recorded Tuesday, May 21st, 2015

VIDEO

SLIDES

[seoslides embed_id=”fe7164f6785f” script_src=”https://devopsy.kinsta.cloud/embed-script/6942/6983/” overview_src=”https://devopsy.kinsta.cloud/slides/6942/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=” ” /]

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Andrew Phillips heads up product management at XebiaLabs. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

Matt Meservey, Director, Product Management, SaltStack

Matt began his career in information technology as a systems and support engineer for Legato. With hands-on experience managing large-scale IT infrastructures, Matt transitioned to product management overseeing the development of systems management products for Altiris and Symantec. Matt brings more than 15 years of experience to SaltStack where he is responsible for all SaltStack Enterprise product management functions. Matt works with the SaltStack engineering team and the massive Salt developer community to deliver next-generation systems management software.

April 29, 2015
If you “code” your apps, why do you still “configure” your IT infrastructure?
Industry studies and market indicators show the exploding growth of the DevOps movement, and it’s for one simple reason – in today’s application driven economy, DevOps teams have proven that they can build, test and ship applications faster than the traditional IT approach.

Businesses compete on the efficiency of delivering applications to meet the demands of the critical mass. Enterprises need the latest business applications to meet new service demands of their customers, accessed in new ways such as over mobile devices. In an application-driven economy, apps are developed and delivered via the cloud more rapidly than ever before; fast time to market is key for success and staying a step ahead of the competition.

As a result of this incredibly dynamic environment, IT teams have adopted new processes such as “continuous integration, continuous development” (CI/CD) – a radical departure from the waterfall model of application development that’s been around for decades. These people and groups within organizations that are leading the charge on CICD or agile development – to meet economic demands for the exploding cloud and mobile market place – are called “DevOps”.

However there are three big barriers that are still slowing down the time to market for apps. Unfortunately, there’s not much the DevOps folks can do since the problem lies in how underlying enterprise IT infrastructure, and specifically the networking products such as application delivery controllers (ADCs), have not kept pace with this evolution.

The reasons application delivery to market is still too slow, as well as recommended solutions, include:
1. Network admin “Human Latency”: ADCs are usually purchased by the network admins that sit within the CIO–led IT teams. As a result, the DevOps and application developers don’t have access to ADC devices. Since app developers need ADCs to test the efficacy of the apps they are building, they have to connect with the networking teams and request access to ADCs…and wait for permissions. This typically takes weeks because of the complexity involved with setting up a custom environment per app developer per app!
In a world where it takes 20 seconds to fire up a server, the human latency (measured in weeks) associated with provisioning an ADC is simply unacceptable.

The solution: A fully programmable , self-service ADC that the app developer/DevOps folks can themselves setup within seconds using RESTful API and scripting tools. DevOps needs an ADC that has zero touch provisioning, is able to auto-discover the compute/app environment, and can auto-create and auto-scale.
1. Distributed Microservices-based app architectures: Microservices have fundamentally changed how apps are built, maintained and scaled. Instead of a monolithic “black box” app that sits in one location with a “reusable or even disposable lego-block” architecture, Microservices can be written in different programing languages, loaded on various hardware and hypervisor platforms, and, most importantly, deployed across various on-premise and cloud locations.With this heterogeneity comes complexity in managing all these different environments which leads to cost and delays associated with rolling out a new application.
The solution: An application delivery architecture that can span, serve and scale all locations, while remaining one device to manage from a management perspective.
1. Geographically dispersed Dev, Test and Production teams: Many companies have the development and testing of apps done in a public cloud, but because of data sensitivity issues (or compliance) they have to run production copy of the app on on-prem data centers or private clouds.Imagine for a minute what this means – completely different environments across various cloud/on-prem locations!When doing development or testing, a certain ADC can be used on-prem – but it’s a different ADC for the real world. There can be unexpected surprises in terms of how the app actually behaves, performs and scales in a real deployment.
Solution: DevOps teams need the same consistent environment across public, private and on-prem data centers. More importantly, if the setup and operations of ADCs across environments is identical, it saves a lot of complexity and costs.

The goal of the DevOps group is to make the organization successful by increasing IT performance and delivery. It aims to make life of an app developer and tester simpler, allowing enterprises to develop and roll out their own apps faster than the competition. From a recent study by Puppet Labs, analysts noted: “We wanted to test the hypothesis that IT performance actually does make a difference to organizational performance. We found that IT performance strongly correlates with well-known DevOps practices such as use of version control and continuous delivery. The longer an organization has implemented — and continues to improve upon — DevOps practices, the better it performs. Companies with high IT performance are twice as likely to exceed their profitability, market share and productivity goals, giving them a strong competitive edge. “

Now more than ever, companies need to be committed to the DevOps model to keep up with the constantly changing business landscape. New approaches to DevOps addressing the challenges of today’s dynamic environment are available for companies to leverage for the benefit of their customers. The timing could not be better – it is now. However, an evolution of the underlying IT infrastructure such as the application delivery controllers (ADC) is not just desirable but mandatory.

About the Author/Ranga Rajagopalan

Ranga Rajagopalan, CTO and Co-Founder of Avi Networks. Over the last 15 years prior to co-founding Avi Networks, Ranga has been an architect and developer of several high-performance distributed operating systems as well as networking and storage data center products. Before his current role as CTO, he was the Senior Director at Cisco’s Data Center business unit, responsible for platform software on the Nexus 7000 product line. Joining Cisco through the acquisition of Andiamo where he was one of the lead architects for the SAN-OS operating system, Ranga began his career at SGI as an IRIX kernel engineer for the Origin series of ccNUMA servers. Beginning his journey with a Master of Science degree in electrical engineering from Stanford University and a Bachelor of Engineering in EEE from BITS, Pilani, India, he now has several patents in networking and storage.
April 29, 2015
Webinar: Canada Mortgage Housing Corporation breaks down IT silos and speeds up mainframe development

DevOps encourages adoption of lean and agile development practices irrespective of platforms. However in most organizations mainframe and mobile/web development teams are functioning in siloes, resulting in a plethora of technology platforms and tools, fragmented or manual processes, skills shortage causing unnecessary delays, rework and friction among teams, impacting organizations ability to respond to the business needs.

Join Jeff Blackadar, Application Development Manager at Canada Mortgage and Housing Corporation, Alan Shimel and IBM experts as they explore the various DevOps strategies, practices and solutions to increase collaboration, streamline processes and leverage modern tooling to attract next generation of mainframe developers to speed mainframe application development and maintenance.

Event recorded Wednesday April 22^nd, 2015

VIDEO

SLIDES

[seoslides embed_id=”24772d7de05d” script_src=”https://devopsy.kinsta.cloud/embed-script/variable-speed-devops-ibm-chmc/6919/” overview_src=”https://devopsy.kinsta.cloud/slides/variable-speed-devops-ibm-chmc/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Variable Speed DevOps-IBM-CHMC” /]

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Jeff Blackadar, Application Development Manager, Canada Mortgage and Housing Corporation

A veteran at application development, Jeff leads a team that programs COBOL, VB.Net, Java and Enterprise Generation Language applications. He is dedicated towards implementing and upgrading of tools and practices to improve productivity and reduce the risks of making changes to mission critical mainframe applications.

Venkat Balabhadrapatruni, Senior Technical Staff Member, Chief Architect, Enterprise Modernization, IBM

Powered by extensive knowledge of z Systems, software design, development, delivery and enterprise modernization, Venkat is responsible for technical architecture and direction of Rational Developer for System z (RDz) and understanding requirements, emerging technologies, market trends and translating them into a technical strategy

April 28, 2015
How machine learning could head off security quality failure

With so many players in the mix from operations to developers, from PMs to technical leads, to Q&A, most of their activities are automated. Systems record all their email, Wiki, and chat conversations and other notations about these activities. This gives the devops community the opportunity to learn from that data in order to improve future projects.

“We have access to a massive amount of data that can in total define what the process is that’s going on and define it in-flight in real-time,” says Aaron Cois, Researcher, CERT Division, Software Engineering Institute, Carnegie Mellon University. Through exploratory research, Cois is learning that by using machine learning tools, enterprises can analyze security activities in the development process based on data from issue trackers and commit logs.

Valleys in Topic Density Point to Software Development That is Missing the Mark

Natural Language Processing, a subset of machine learning, uses systems to process text in unstructured data and to perform topic detection, determining whether or not a portion of the text belongs to a given topic category. “In our work, we’ve taken text from issue trackers and used machine learning to classify each issue as security-related or not security-related,” says Cois.

This has practical applications for detecting the course of a project and steering it in the right direction. If the PM expects the developers to raise the quality of security for an iteration of the software package, he can monitor the chatter among developers about the issues they are adding to the issue tracker or he can monitor the comments on the code.

“By using machine learning to classify issue tracking or source code commit messages as security-related, we can see a reasonable measure of the amount of work that’s being done to ensure the security of the software system,” says Cois.

If the PM can determine based on a shortage of security chatter that in actuality not much security work is going on, he can ask why, what is the challenge? “Is the security stuff more difficult? Did we do our due diligence to allow our developers to adequately address security?” asks Cois. Then the PM and the teams can work together to remove any roadblocks before any more scope creep or veering off course occurs.

Machine Learning for Physical Modeling and Trends Analysis

If the industry can build statistical models of what a healthy software project looks like as it progresses, then it should be able to determine whether a given project is on track and what risks it may face along the way.

Issue tracking data, commit logs, wikis, chat server logs, build/deployment logs—every type of data that can lead to a full picture of project activities—would form the basis of these models, according to Cois.

Through Natural Language Processing, machine learning can help determine from this data what the rates of creation and resolution of issues are and what the rates of commits and overall progress are for the software project.

Machine learning can help PMs look at how their project’s rates in these areas compare with rates of similar projects, which developed certain problems or turned out in certain ways. If there is a strong correlation between rates of projects that had known outcomes and rates in your project, then you might want to use that information to make corrections early on, in cases where the outcomes of the other projects were undesirable.

Over time, the models become stronger and their predictive value increases, leading to some strong correlations between current projects and the models collected. With the increasing density of the data available in models as they grow, even the weakest numbers in early models can become stronger, giving the model strong correlative value in areas where strong correlations did not appear at first.

“If I have collected both activity and outcome data on thousands of projects, and a large number of them are highly similar to the current project, I’ll have much more confidence in my predictions about the potential outcomes of the current project given the behaviors I am observing,” says Cois.

April 28, 2015
Successful Failure

In software development, success is all about failure.

That may sound as if we are carrying the “fail fast, fail hard” philosophy a little too far, but which would you rather have — a quick, definite failure that you can identify, repeat, and analyze, or a series of semi-failures and partial recoveries that leave your application and your data in a corrupt and unstable state? Anybody who’s spent much time testing or debugging software should know the answer: errors that are masked by near-recovery are almost as hard to trace as intermittent errors — and all too often, there’s no real difference between the two. Slow failures masked by partial recovery show up as on-again, off-again bugs.

(more…)

April 28, 2015
Chevy and DevOps: What the Wi-Fi?
In DevOps: Rapid Feedback, Rapid Repair

I’m sure you have seen it too. Chevy cars now come with wi-fi. How cool. I want that (and so would my kids). I can only imagine the possibilities.

But, this is not all about my needs. Chevy and every other vehicle maker wants this too. And not for the reasons that you might first consider. Quickly, let me introduce you to the recalls of today:
The glitches were related to cars losing power, erroneously deploying airbags, and other defects. This is just a small glimpse of the software recalls that have happened over the past year.

But more troubling is this form of software “recall” from BMW showing a security flaw that could allow cyber criminals to unlock doors on 2.1M vehicles. Because every one of the 2.1M vehicles has the same defective software part, criminals effectively had access to a skeleton key to every one of them.

In DevOps: Rule Your Supply Chain

The reality is, that your new car has more software in it than you can image — about 100 million lines of code. And, as we know, all software has flaws. But who wants to go to a dealer to get a software update? If my car can connect to the internet and update itself, that would save me an unscheduled trip to the dealer for a repair.

While software updates to cars models in the past were would take 5 years to feed themselves onto the production line, that is now all changing. For decades, large automakers like Toyota have been applying excellent management process for their entire supply chain. And with the introduction of wi-fi in vehicles, they are expanding their highly-tuned practices to include their software supply chains. They know where every piece and version of their software is and who owns it. If a flaw is detected (be it quality, safety, security, or another attribute), they will now be able to automatically update that vehicle. Not only can they remove defects, automakers like Telsa are even making their cars faster.

While many of us outside the auto industry think of these large industrialists as slow moving organizations, the introduction of wi-fi in cars is allowing them to now apply a core principle from the agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

In DevOps: Version Everything

For those of you in the software industry, this kind of evolution is at the heart of many DevOps and continuous delivery efforts. Automate everything you can. Version everything you can. Deliver fast, improve visibility, and change fast. In many ways, the addition of 4G LTE Wi-Fi in Chevy Trucks means that DevOps has entered into our auto and software supply chains.

If you imagine an even broader perspective of this wi-fi feature and software supply chain management, the auto makers are now leading the way to expectations of quality improvements in the Internet of Things (IoT). There is not much difference between an internet enabled truck, thermostat or fitness bracelet when it comes to rapidly improving and updating quality, features, performance, etc. (I’ll cover this topic more in future posts.)

In DevOps: Optimize Your Software Supply Chain

What have the auto makers learned from the software industry? And perhaps more importantly — when it comes to software supply chain management and continuous delivery — what can we learn from them?

A final note on software and auto safety: I am the Cavalry (@iamthecavalry) is encouraging the automotive industry to commit to cyber safety. The movement recently published a Five Star Automotive Cyber Safety Framework (PDF download) and calls for Automotive Industry adoption. Media outlets from across the US and Europe praised the effort and joined in calling for automakers and security researchers to work together to ensure a safe future.
April 28, 2015
DevOps-in-Name-Only? Don’t do DOINO
Let’s not be ‘that’ guy. And let’s not be ‘that’ organization.

You know, the one where “DevOps” is some magic pixie dust that we can sprinkle around, and then pat ourselves on the back for being forward-thinking, modern IT managers. It’s actually harder than that. Harder but simpler. Harder because DevOps involves humans. Simpler because pixie dust doesn’t actually exist. (I prefer software instead.)

There is thankfully a lot of good “devops” software out there. We are pretty proud of ours too but we fully admit that paying closer attention to human factors of DevOps helps ensure that you get the most from your software whether you buy it or build it.

Respect

Any “DevOps” organization worthy of that title needs respect and understanding between Dev and Ops. Each brings their own talents, mindsets and constraints. Those other guys generally aren’t trying to make your life difficult just because they can, or because they don’t care. They are making your life difficult because they may not fully understand your environment, your pressures, your management and even the metrics that define ‘your side’. Or maybe they have pressures and constraints of their own. This isn’t a matter of touchy-feely kumbaya. Getting to know and respect each other is actually just good business.

Communication

A DevOps organization should also have good communication. Note that I didn’t say lengthy communication or countless tedious meetings. Just good communication. I also didn’t specify whether that should be verbal or written. It just needs to be good and it needs to fit your organization and your environment. Whether you are a multi-national organization with datacenters across the globe or if your entire IT department can fit in one room,
1. Focus on sharing what is important for your colleagues to get their jobs done.
2. Make clear what you need or what you need to know from them so that you can do your job well.
3. Don’t hide that key nugget or even that bit of bad news under mountains of data. Over-sharing is as destructive as withholding key info.
4. Say ‘thanks’, ‘good job’ and ‘sorry’ every now and then to your colleagues in Dev/Ops.
Process

A) People learn by doing, more than being talked at. B) What gets measured, gets done. So find something that works for your organization and your culture to nudge the DevOps mindset that you are seeking. Maybe it’s a job rotation program (even for a couple of hours per week). Maybe it’s paid company lunches. Or working in the same physical area. Perhaps it’s having Dev report on traditional Ops metrics and vice versa. Or maybe it’s sharing the risk and rewards of holding Dev and Ops accountable for combined DevOps metrics. The point is to foster team performance in a we’re-in-this-together mindset.

DOINO

The bad news is that #DOINO (DevOps-in-name-only) is worse than useless. DOINO can cheapen and make a joke of a pretty good concept that should be helping IT teams accomplish more and enjoy their jobs while doing so.

The good news is that you don’t have to be perfect at all of the human factors of DevOps to make real progress. Your improvements may be sparked by formal cross-functional meetings, informal sharing of more beers or even (my favorite) by clever new software that automates the hell out of tasks you had previously taken for granted. The important thing is to just get started.
April 27, 2015