Adventures in DevOps

Julian Fahrer is a software engineer with a systems administration and operations background. He currently works at Hover and is helping them move towards continuous delivery. 

Nell opens up the discussion by asking Julian to explain what continuous integration and continuous delivery are. He shares that continuous integration revolves around having testing and automation around the code being pushed to ensure that it works and conforms to standards. Continuous delivery feeds off of the concept of continuous integration and is the ability to deploy to any environment at any point in time. Chuck puts these ideas together by saying that continuous delivery and continuous deployment is about making sure that it’s possible to deploy at any time and actually doing so. 

The next topic covered by the Adventures in DevOps panelists is how to handle apprehension around having a continuous integration / continuous deployment (CI/CD) pipeline. Julian shares that big cultural changes are required to make CI/CD successful. They share that a lot of organizations are nervous about code with breaking changes immediately being deployed. One way to handle this vulnerability is by hiding features behind feature flags so that only certain people, for example the QA team, will have access to the feature.They share why an organization would want to change to a continuous delivery pipeline and some real world examples that they have experienced

Chuck asks what some prerequisites are for a CI/CD pipeline. Scott says that one thing that needs to happen is backfilling areas of the application that previously did not have tests and expanding the testing coverage of the system. Julian shares that these prerequisites depend on how changes are made and shares some specific examples of what that entails. 

Nell asks what it takes for an organization to be able to do continuous delivery. Julian shares that it is mostly process driven. They establish some rules such as shortening the lifetime of development branches and improving how they are deployed. They also have a discussion on how integration tests should come about and who should write them. Julian mentions that you want to empower people and give them the tools they need to succeed. They then cover some of the work that Julian has done with Hover and some of the details of the continuous delivery environment he is building and the steps they took to begin moving towards that workflow.

The topic then moves to dependency management. Nell asks Julian how he approached dependencies in his applications. Julian details how his usage of containers and specific tools helped him. For external environments he says that a database is required and that it would help to have standards for managing dependencies. 

They share how the current development culture is to give the QA team enough time to test a feature before it goes out. With a CI/CD environment, feature flags can be used to gradually roll out a changes and if a certain users needs a specific set of features then an individual environment can be spun up for their use case. The panelists share some thoughts on environments setup and production best practices and tooling.

Panelists

Nell Shamrell-Harrington

Charles Max Wood

Scott Nixon

Guest

Julian Fahrer

Sponsors

Adventures in .NET

Ruby Rogues

React Native Radio

Links

Hover

Launch Darkly

Split.io

Codefresh.io

Argo CD

Flux

12 factor

The Phoenix Project

Picks

Nell Shamrell-Harrington

Beef on Weck

Charles Max Wood

St. George Marathon

Marathon Training

Maxcoders.io

His electric smoker

3-2-1 method for ribs

The word delightful

Scott Nixon

Broccoli Rabe Philly Cheesesteak

Ultra Learning by Scott Young

Libby app 

Julian Fahrer

Accelerate

The State of DevOps

Walk in Balance

Special Guest: Julian Fahrer.

• Nell Shamrell-Harrington

• Dave McAllister

This episode of Adventures in Devops features Dave McAllister. Dave has an extensive background in open source starting in 1994 working with early versions of Linux. He thrives on the concepts of emerging technologies and being able to innovate things. He also loves understanding what people are doing with emerging technology. 

The discussion opens up by introducing the topic of multi-dimensional monitoring in RED. Dave gives us an introduction into RED as a subset of google’s SRE Golden signals. RED stands for rate, errors, and durations and is a concept that is designed for working with micro services. The DevOps panelists discuss concepts such as saturation and how to ensure correct results from their micro services using the RED concepts as well as some best practices for managing micro services.  

Nell asks about the scope of RED and whether it works with the big picture of what the micro service is doing. Dave shares that the scope of RED pertains to both. RED helps with observability and how to get the right signals out of all the noise and how to respond once the correct signals are found. He shares that RED should be a set of metrics in a dashboard that can be aggregated. He explains that RED gives the user a way of grouping data together and helping them to normalize functionality and find trends. 

The next topic covered by the DevOps experts is how to map the metrics seen in RED to the user experience. Dave explains how RED monitors the users activity and can put together metrics based on what they’re doing. Using RED to follow user metrics will help to identify trends in where users will have issues and identify problem areas. Using micro services with RED introduces a level of granularity that can be monitored to help improve the performance of the application and improve scaling. RED helps with these improvements most notably by improving reaction time once a problem is found to help correct it as soon as possible. The panelists discuss some real world examples and how real world activities and human tendencies can alter patterns seen in the monitoring. Dave points out that one of the strongest recommendations he can make about RED is its ability to start simple and scale upwards as needed. 

The panelists then go on to discuss the human aspect of RED, how a team would react to changing, and how RED really requires a true DevOps team to reach its full potential. The panelists then share experiences they faced earlier in their careers as developers and how RED could have helped them. Nell brings up the idea of service meshes and how RED applies to them. Dave starts by introducing some problems in micro services and service meshes and the opportunity that exists for RED to come in and help solve those problems. He explains how service meshes in micro services give you duration that you don’t have to implement. They finish with covering the usage of Kubernetes operators.

Panelists

Nell Shamrell-Harrington

Guest

Dave McAllister 

Sponsors

Elixir Mix

Adventures in Angular

iPhreaks

Links

RED

Google’s Golden Signals 

Kubernetes Operators

Picks

Nell Shamrell-Harrington

Fire Emblem: Three Houses

Dave McAllister

Membership card to Fulham football club

Special Guest: Dave McAllister .

• Charles Max Wood
• Scott Nixon

On this episode of Adventures in DevOps the panelists talk about how to containerize an app in a container using services such as Docker or Kubernetes. Charles mentions that he is wanting to host a Ruby on Rails application and Scott has experience with web deployments in Python and Django. They share that regardless of the languages and technologies used, the principles behind deploying a containerized application are the same.

The next topic covered by the DevOps panelists is how to create containerized instances using Docker. The discussion centers on creating the container instances on a network and best practices that can be used for managing and maintaining them. The DevOps panelists cover the difference between an internal network deployment and what is needed to push a containerized application to a cloud instance using Kubernetes, Docker, DigitalOcean, or another service. Scott asks Charles if he is using a good CI/CD (continuous integration/ continuous delivery) mechanism, to which Charles shares that he is using Cloud 66 for its ease of use. When it comes to storage, they discuss whether to use the cloud services storage option or using a container to run a Postgres engine. They also go over the best way to run the shell commands for configuring their environment.

The topic then moves to security and asset management when using Docker. Charles mentions that he tries to avoid putting API keys or other secrets into the Docker file and Scott shares how he uses a secrets management platform such as AWS Parameter Store, AWS Secrets Management, and others. They discuss the benefits that are provided by secrets management platforms. The DevOps panelists also talked about how a CI/CD platform can help with the portability of a containerized application

Charles asks Scott how to begin with helping someone who wants to take their existing application and containerize it using the Docker approach. Scott responds with describing how he would look at where there application is and help them configure their containerized instance and set it up on a container service such as Docker or Kubernetes. Scott mentions that the strength of moving an application to a container service helps the application to scale up and down as needed. The container model helps a team to locally replicate their CI/CD model and be able to test it locally before the application is pushed to the cloud instance.

The panelists talk about reverse proxies for pushing a Ruby on Rails app. Chuck prefers nginx and Scott emphasizes that it is important when pushing to production to spend some time verifying that the reverse proxy configuration is correct and won’t expose the application in a way that it shouldn’t be. Chuck shares that the use of a cloud platform such as GCP (Google Cloud Platform) of Microsoft Azure reduces the overhead with configuring containers and building images so that when he hands it off to the platform, it will take care of a large part of the setup including creation of the reverse proxy. 

Panelists

Charles Max Wood

Scott Nixon

Sponsors

Sustain Our Software

Views on Vue

Dev Ed

Links

Docker

Kubernetes

Ruby on Rails

Python

Django

Cloud 66

PostgreSQL

DigitalOcean

Bitbucket

Google Cloud Platform

Microsoft Azure

AWS Parameter Store

AWS Secrets Manager

Nginx

Picks

Charles Max Wood

Height Adjustable VESA Adapter

Velcro Strips

Scott Nixon

The Gymkhana Files

The Grand Tour

• Nell Shamrell-Harrington
• Scott Nixon

In this episode of the Adventures in DevOps podcast, the panelists talk about Agile. Nell starts the discussion by mentioning that Agile came out of the Scrum movement and gives a brief history of how it started. She reads out the Agile Manifesto, and Scott explains what it is. They agree that “move faster slowly” can be considered as a motto of Agile. Scott talks about the testing aspect of it from a philosophical perspective, and Nell chimes in with comparison to how things were being done in the past versus now.

They discuss the 12 principles behind the Agile manifesto. One - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Two - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage, basically valuing learning and improvements. Three - deliver working software frequently, from a couple of weeks to a couple of months with a preference for a shorter time scale, the focus being on the code being in a working state. Four - Business people and developers should collaborate daily through the project. Scott elaborates on the point further, and shares his experience where it was challenging to work with the business side of the project.

Five - Build projects around motivated individuals, give them the support they need and trust them to get the job done, trust being the most important factor here. Six - The most efficient method of conveying information is having a face-to-face conversation, here the panelists provide a counter-argument that in the era of online platforms and remote work, this is not necessarily essential. Seven - Working software is the primary measure of progress. Eight - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. ‘Sustainable’ is key here, avoiding overworking and burnout is important anyday. Nine - Continuous attention to technical excellence and good design enhances agility. This means doing the full set of code reviews and tests and still deploy software quickly and making sure that it doesn’t break things, if it does, it has to be rolled back.

Ten - Simplicity - the art of maximizing the amount of work not done - is essential. This highlights the need for focus in the product, and not writing a lot of code that could eventually be unusable. Eleven - The best architectures, requirements, and designs emerge from self-organizing teams. Panelists talk about people involved in open source projects as an example of such self-organizing teams, where they work on their own schedule and have great interest in what they are building. Twelve - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Retrospectives, reflecting where you are, how the team works together and documenting results as some sort of a learning exercise, are some of the practical examples of this.

Nell then talks about the three layers of Agile infrastructure by Patrick Debois - considered as the father of DevOps. These constitute of technical - the hardware and software, project - the process that introduces changes in the environment, and the operations - the process of keeping the environment working.

They state that we can build effective technology if we can relate to each other as humans, and discuss how Agile is perceived in certain controlled environments, if it’s possible in an Agile fashion and still have prescriptive solutions. They end the show with picks.

Nell Shamrell-Harrington

Scott Nixon

Adventures in Blockchain - Devchat.tv

React Round Up - Devchat.tv

Adventures in .NET

CacheFly

The Agile Manifesto

Principles behind the Agile Manifesto

Kubernetes co-founder Craig McLuckie is as tired of talking about Kubernetes as you are

Nell Shamrell-Harrington:

The Great British Baking Show

Kinesis Advantage2 Keyboard

Scott Nixon:

The Moment of Lift: How Empowering Women Changes the World

Gatesnotes books - The blog of Bill Gates

• Charles Max Wood

On this week's Adventures in DevOps, Chuck talks about the recent Twitter thread about 10x engineers. He goes through each of the points in the tweet and talks about each of them in turn. There are only two points he sort of agrees with, and believes the rest to be absolute garbage. One of the issues with this tweet is that it doesn’t define what a 10x engineer is.

Defining a 10x engineer is difficult because it is also impossible to measure a truly average engineer because there are many factors that play into measuring productivity. Chuck turns the discussion to what a 10x engineer is to him and how to find one. A 10x engineer is dependent on the organization that they are a part of, because they are not simply found, they are made.

When a 10x engineer is added to a team, the productivity of the entire team increases. Employers have to consider firstly what you need in your team and how a person would fit in. You want to avoid changing the entire culture of your organization. Consider also that a 10x engineer may be hired as a 2x engineer, but it is the employer that turns them into a 10x engineer.

Overall, Chuck believes these tweets are asinine because it’s impossible to measure what makes a 10x engineer in the first place, and hiring a person that fits the attributes in the list would be toxic to your company.

Charles Max Wood

iPhreaks - Devchat.tv

The Dev Rev - Devchat.tv

React Round Up - Devchat.tv

CacheFly

10x engineer Twitter thread

Follow DevChat on Facebook and Twitter

Charles Max Wood:

Copyhackers.com

Good to Great by Jim Collins

Keto diet

Podcast Movement

• Nell Shamrell-Harrington
• Lee Whalen
• Scott Nixon