DevOps Days Podcast

Full title: Confessions of a social engineer: Why developers are my favorite target

Social engineers use a dangerous combination of technology and old fashioned con artistry to infiltrate organizations every day. In this talk we'll walk through the social engineering process including research, target selection, attack selection, and attack execution. Learn to see the world through the eyes of a social engineer and prevent yourself from being a victim.

In this talk, Sam will discuss some common and some not-so-common tools for debugging code, systems, and anything in between. He will take strace, valgrind, gdb to the next level.

All organizations face challenges in changing their culture and adopting DevOps philosophies. This is especially true in many federal government agencies. Through well-intentioned policies and procedures many agencies have created extremely silo’d environments where change is slow and difficult. Finishing the last leg of large scale software development project acquisitions can be particularly challenging and expensive. Barriers often impede getting hardware and software systems system fully tested, transitioned, and up and running in production on schedule.

Through our experience as a passionately DevOps focused software development group within Carnegie University's Software Engineering Institute, a federally funded research and development center, creating, delivering and transitioning cutting edge software solutions to government organizations, we have struggled with and overcame challenges in helping government to adopt DevOps principles. Learn how we have conquered these challenges in shifting our government stakeholders' thinking by coaching and initiating DevOps in their operational and development environments.

Several attendees give spontaneous talks...having never seen the slides and the slides have almost nothing to do with each other. A hilarious exercise in non-sequitur and impromptu absurdity. We all need a little ridiculousity in our lives!

• Jason Hand (VictorOps) - ChatOps• Leon Frayer - What is devops NOT?• Lewis (Delphic) - Data as a service• Chris Corriere

How to take an app from your laptop to production utilizing the future of container orchestration. It’s difficult to say with confidence that your app will work in production without testing it, many people today have very complex scripts which out outline deployment, testing and validation, and often rely on late night pager calls and very brittle rollback scenarios. Additionally, developers struggle with developing software on different platforms and SDK versions that are hard to make consistent which results in different builds and exceptions which are hard to resolve. We can finally stop saying, 'it works on my machine' phrase since it will work the same on every machine. Other processes in the past have attempted to solve the problem but are brittle and take time to build out environments.

This talk will outline the process of how to deploy an app locally in docker-compose, then scale it out to multiple servers running Kubernetes. From there, the audience will see how to scale the app to achieve performance, manage failures, debug, and understand best practices.

Containers are a great way to package, build, run and deploy apps and Docker has make that practice very simple, however, it’s only really works well on a single host. With the learnings from Google, Kubernetes is the open source container orchestration offering which builds on Google's current infrastructure learnings that we all can use in an Open Source model.

There are many stakeholders involved when you are creating or assembling a security toolchain. How do you satisfy the different, and sometimes conflicting, needs of these stakeholders in a responsive way?

We can use some of the concepts developed in the user experience domain to create better security tooling. User personas allow us to map out different roles that must interact with security to get their work done. These personas are living and provide a fast feedback loop when paired with user interviews. Giving direction while allowing freedom is a key tenet to integrating security into different parts of your organization.

Operating Systems. Where did they come from? Did your customer ask for one? Why do you bother with them at all?

Operating systems have traditionally played an enormous part in software development and operations. Most of us would find it difficult to imagine computing without one. They are certainly a source of religious contention.

Operating systems represent a maintenance and security burden; they have long been viewed by many as a necessary evil. They often bring more bulk and complexity than the systems we are producing; particularly in the case of microservices. They complicate security, greatly increasing the attack surface, and they require a significant expense and effort to maintain. But generally, operating systems are assumed to be required and we seldom consider a service environment without them. How well do you really even know what you're deploying when an OS is involved?

Operating systems introduce variation into a development workflow that can be difficult to manage. On a dev team, each individual's computing environment tends to stray apart. This divergence is a primary cause of Works-on-my-box syndrome. Things such as VM, libraries and general configuration are a source of drift.

Unless your product is, itself, an operating system, your customer is not generally concerned about your OS. A great deal of effort and expense goes to the operating system, without any direct ROI.

We will take a look at the ways emerging technologies will help you to reduce the liability of operating systems. We will consider how the minimization, or even elimination, of the operating system impacts development workflow; for better or worse. What would a CD pipeline look like? In particular, we would like to consider ways in which containers and unikernels or anykernels complement and can be used in combination.