DevOps Days Podcast: Recent Episodes
DevOpsDays.org
When building reliable services unexpected user behavior can prove deadly. Yet few engineering teams make use of talent from their product and design orgs if they are working on something internal. This talk will demonstrate how a product mindset and design thinking can super charge technical discussions and build stronger systems. Don't rely on the user to be "smart!" It can trap you in an impossible architecture.
All your tech is old. Even your new stuff is already old: somebody's already building something that's better. And they're probably going to give it away for free! So, what can you do about that? I have thoughts.
We all spend a lot of energy trying to discover tech debt, and eliminate it. Fat chance! In this talk, I will convince you that all tech is debt, and that it's futile to try to live debt-free. Why? Because none of your tech is an asset; it's all liability. From the minute it's created, it's already old. It has security vulnerabilities. It's not idiomatic to whatever the latest trends are. It's eating you from the inside! So what can you do about it? Throw away as much as you can. Let someone else build the rest. And most importantly, focus on your real assets: your people, your culture, your brand. Your customers! Technologists are an asset. But tech? That's debt.
I'm a software engineer who spends her time writing code and developing apps. I have a pretty good grasp of the vocabulary and technologies relevant to my job. But what happens when another facet of engineering, one that is gaining a lot of traction and has a large footprint of its own starts becoming more and more relevant to my day to day tasks? Well, that's exactly what happened to me last year when DevOps became a big part of my role. This is my attempt to impart all of that knowledge onto you.
Taking advantage of AWS Parameter Store and some automation magic to make secret change management a problem of the past. We will talk about:
- The importance of secrets management
- Use Cases
- Parameter Store vs. Secret Manager
- Secret Vault and Application Integration points
- OSS Tools for Automation
Resilience Engineering (RE) is both multidisciplinary field of study as well as a community of practitioner-researchers from multiple high-tempo, high-consequence domains such as aviation, medicine, power distribution, space operations, and critical infrastructure. In recent years, the world of software engineering and operations has become involved and more acquainted with this almost 20 year-old field and community. This talk will give a “lay of the land” on what RE is, what it is not, what efforts are relevant to the DevOps community, what attendees can do to learn more.
As developers, we take great pains to make our applications accessible to users on a range of devices and browsers. There are more adults with disabilities in the US than there are users of Internet Explorer. So why do we spend more time worrying about polyfills for out-dated browsers than we do on ensuring the accessibility of our applications for users of all ability levels? This talk will emphasize the importance of incorporating accessibility best practices throughout our design and development workflow. Simulated experiences of engaging with inaccessible software will provide insight into the realities that millions of users face day to day. Drawing on recommendations from the Department of Justice, we will discuss action steps for evaluating and improving the accessibility of software.
Meg is a science and technology educator turned software engineer working in Washington, DC. She approaches new technologies with curiosity and confidence, building on her interdisciplinary education and experiences. These range from making technology decisions in the non-profit and education sectors to engineering full-stack solutions in a number of programming languages and frameworks. Her interest in accessible development begin with work as a blended learning instructor developing original digital content for a diverse youth audience. Kim is an attorney and disability rights advocate. Her interest in accessible technology stems from her own vision impairment and her use of assistive software on a daily basis. In her career she has worked in various disability policy areas including housing rights and access to reasonable accommodations in employment. Kim has dedicated her career to the full inclusion of people with all types of disabilities.
Today--Incorporating AI into applications is as easy as a single API call. Once imbued with AI, these transformed applications can improve over time as they learn from user interactions. How do we manage these new learning systems to ensure that they take advantage of all available information while maintaining accuracy and minimizing bias? This talk will discuss common problems encountered when designing and implementing AI systems and how DevOps practices can be used to address these issues. DevOps practitioners will learn the relevance of their skillset and practices to the rapidly evolving AI domain. The problem of properly managing AI applications and their underlying models is not trivial.
Michael Flores is an Architect on the Strategy and Technology Team in IBM’s Federal Chief Technology Office. He has helped numerous agencies use Cloud, Artificial Intelligence(AI), Robotics, and DevOps through the adoption of open standards such as Cloud Foundry, Docker, and OpenWhisk. Michael represents IBM in The Open Group as chair of the Open Platform 3.0™ Forum, where he collaborates with other industry leaders to develop standards for modern technologies to support global interoperability and boundaryless information flow. Michael has extensive development, design, and architecture experience across a variety of technologies and has implemented numerous chatbots and AI driven solutions through various channels including web, SMS, and robots.
Michael received an undergraduate degree in Bioinformatics from Baylor University and holds a patent for dynamic customization of reference architectures. His capstone project at Baylor focused on crawling heterogenous data sources to create knowledge graphs to aid PTSD research.
Working technology for a political campaign involves the shortest timelines, tightest deadlines, and highest stakes you will likely ever encounter in a technology career. Come hear a tale of two political campaigns - a state measure campaign and a presidential campaign - and the application of both DevOps technologies and culture to move fast, pivot quickly, and hopefully win. One of the key challenges of politics - as well as DevOps in general - is harnessing automation without losing the critical human touch which moves hearts and changes minds. Learn how to find the line where too much automation (yes, there is such a thing) is counterproductive and you need to pull back to maintain a personal connection with voters, customers, employees, and more. You will also walk away knowing how to take the lessons and experience learned to future campaigns and projects - especially when your candidate, product, etc. does not end up winning. There is value - sometimes more value - in a loss as well as a win. Learn how to take what you can, iterate, and refine it for a future application.
Nell Shamrell-Harrington is a Software Development Engineer at Chef, focusing on the Habitat open source product. She is also CTO of Operation Code - a non-profit dedicated to teaching software engineer skills to Veterans that heavily creates and uses open source. Additionally, she is a technology volunteer for multiple political campaigns. She specializes in Chef, Ruby, Rails, Rust, DevOps, and Regular Expressions and has traveled the world speaking on these topics. Prior to entering the world of software development, she studied and worked in the field of Theatre.
GDPR is upon us, along with new requirements for protecting user data. Many of us in the DC ecosystem are no strangers to compliance! We have expertise in HIPAA, SOC, PCI, and of course the stringencies associated with government work. But GDPR's new requirements are taking effect at the same time that many users are demanding increased privacy and transparency about their data (as a backlash to the Cambridge Analytica scandal) regardless of regulation. We'll look at best practices for DevOps teams to respond to this increased need for privacy, transparency and security around user data.
In addition to best practices, we'll explore the following questions:
What does the current regulatory landscape look like, and how does that impact DevOps?
How do we design our applications and our architecture (especially containers) to optimize for security and privacy?
And are the current regulations helpful as guidelines, or will they become another set of checkboxes?
Elissa is a successful serial entrepreneur that helped launch Geekcorps (acquired), Everyday Health (IPO) and the Brave browser. Elissa also cofounded Glimpse, an end to end encrypted photo sharing app and is the Editor of “Lean Out: The Struggle for Gender Equality in Tech and Startup Culture.”
Learn how we established a service providing development teams with a continuous integration, build, test, source code management, and an issue tracking environment for building mobile apps for a large Federal Agency. Mobile phones are the world's greatest surveillance tool, containing all our private information that we willingly carry in our pocket everywhere we go. How do we develop and operationalize applications for mobile phones in a safe and secure way? Our system performs iterative tests on apps to provide insights on mobile app security and privacy, in compliance with several Federal Agencies standard operating procedures for deployments. Learn the history of the service, how it's currently working, and how you can build this service for your organization.
One of the more unique and complicated areas of devops is dealing with database updates, especially those for databases with pre-defined schemas like relational databases. Databases generally:
- Need to stay online during updates
- Should not be destroyed and re-created
- Frequently have changes that can be long running and have impacts to the running application code
- Have implied or explicit dependencies between the database schema and application code or across shards in a sharded database
- Still have the same requirements as application code for being traceably updated
- And should be updated in an automated fashion as part of your devops strategy
This talk will cover tools and strategies the speaker has identified in over 15 years of working with automated database migrations for making sure your persistence stores are smoothly integrated into your devops workflow. We will cover:
- Handling database updates via database migration tools: how to get started and what in the speaker's experience is and is not important in a good migration tool
- Patterns, and tips and tricks, for addressing common issues with database migrations
- Workflow processes for developers, DBAs, and operations teams that enable a smooth, controlled database migration process as part of devops
- How automating your database migrations benefits database administrators
The cornerstone of bringing together "development" and "operations" is collaboration. Collaboration sounds great on paper, but when the scales tip, you may end up with anarchy, or a dictatorship. How do you balance all of that while still managing to get things done? Enter: improv. Learn from theatre artist Melanie Harker and artist/developer Sean Paul Ellis how to taking a more fluid and fun approach to your DevOps work will allow you to build empathy, a common language, and ultimately, an environment for innovation to cultivate.
This is a deeply personal talk where I share my experiences as a woman in tech. Even though I'd worked for NASA and co-founded my own successful company, rampant sexism in IT and bad experiences speaking in public nearly destroyed my career. That continued to have ripples in my life until I found the DevOps community and the safe spaces it creates. I will examine common constructs about diversity and propose ideas to bring productive change to continue to build upon the solid foundation of inclusion we have created.
The standard approach for web application security over the last decade and beyond has focused heavily on slow gatekeeping controls like static analysis and dynamic scanning. However, these controls was originally designed in a world of Waterfall development and their heavy weight nature often cause more problems than they solve in today’s world of agile, DevOps, and CI/CD.
This talk will share practical lessons learned at Etsy on the most effective application security techniques in todays increasingly rapid world of application creation and delivery. Specifically, it will cover how to: 1) Adapt traditionally heavyweight controls like static analysis and dynamic scanning to lightweight efforts that work in modern development and deployment practices
2) Obtain visibility to enable, rather than hinder, development and DevOps teams ability to iterate quickly
3) Measure maturity of your organizations security efforts in an attack-driven defense model
For the past two years my team and I worked with a large federal agency to deploy & migrate to a new container-as-a-service platform based on Docker. The migration has enabled development teams to isolate components of their code for faster, more reliable development. But, we also saw that the additional tooling - such as monitoring technology - supporting these services doesn’t yet map to the model that developers need to efficiently monitor their own services. In essence, the Develop->Test->Monitor loop is still broken for modern environments. So how do you fix it?
This presentation is based on my real-world experience with container platforms. Based on this work, I’ll address: How do you effectively instrument your systems, without pushing too much burden on to developers?How do you isolate data, dashboards, and alerts in a way that improves security while simplifying analysis? What can you do to give developers deep information when troubleshooting, without giving them the keys to the kingdom?How do you facilitate data-driven conversations among your developers and ops teams?
If you attend this talk, you’ll walk away with tested, practical ideas that will help your teams become more self-sufficient, improve data-driven conversations among your teams, and evolve your monitoring infrastructure to work more effectively with your CaaS platform.
In Greek Mythology, the Gods cursed Sisyphus to spend eternity rolling a large boulder to the top of a mountain, where it would fall back of its own weight. In DevOps, we're forever rolling boulders uphill. We're making deploys faster, cheaper, smoother, and quicker. And once the boulder reaches the mountain top, the engineers rearchitect the application and the the process begins again.
At Upside Travel, Slack is our central command hub. We run our full operations through Slack ChatOps. Engineers request code reviews, product managers examine tickets, and the Slack-integrated NOC works slack-alerted events. We also manage our full continuous integration and deployment process through a custom Slackbot named, aptly, for the DevOps Greek hero, Sisyphus.
Sisyphus's simple promotecommand hides a complex dance of builds, tests, promotion, deployment and management. Upside combines Github, CircleCI, Artifactory, Terraform, Docker, Kubernetes and AWS to deploy code from nothing to something in 3 minutes and it takes deployment/promotion 100% away from DevOps and Engineering to place the power into the hands of Product Managers.
In 1982, the city of Detroit saw 15,000 vehicles roll of its production lines every day. To achieve this goal, Detroit's line workers were being measured on velocity, often at the expense of quality. At the same time, auto workers in Japan -- applying lessons from W. Edwards Deming -- were implementing new supply chain management practices which enabled them to manufacture higher quality vehicles, for less cost, at higher velocity. As a result, from 1962 to 1982, the Detroit auto industry lost 20% of its domestic market to Japan.
The parallels between the auto industry of 35 years ago and software development practices in place today are remarkable. DevOps teams around the world are consuming billions of open source components and containerized applications to improve productivity at a massive scale. The good news: they are accelerating time to market. The bad news: many of the components and containers they are using are fraught with defects including critical security vulnerabilities.
This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 2017 State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis. The presentation will also reveal findings from the 2017 DevSecOps Community survey where over 2,000 professionals shared their experiences blending DevOps and security practices together. Throughout the discussion, I will share lessons that Deming employed decades ago to help us accelerate adoption of the right DevSecOps culture, practices, and measures today.
Attendees in this session will learn:
- What our analysis of 60,000 applications reveals about the quality and security of software built with open source components
- How organizations like PayPal, Intuit, Fannie Mae and the Department of Defense are utilizing the DevOps principles of software supply chain automation
- Why avoiding open source components and containers over 3 years old might be a really good idea
- How to balance the need for speed with quality and security -- early in the development lifecycle
Attend this session and leverage the insights to understand how your organization's application DevOpsSec practices compare to others. We'll share the industry benchmarks to take back and discuss with your DevOps, development and security teams.
• Daniel Willis - Putting the R in Sports
• Mark Morris - You, Me & StatsD
• Sara Cowles - If you want to have an impact, Devops is not enough
• Jason Hand - The Emergence of ChatOps
• Matt Stratton - DevOps in the Machine
I hate computers. How many times have you heard those words? Or said them yourself. Systems crash and go boom all the time. The easiest thing to do is to blame the person touching the keyboard when it happens. Especially when that person touching the keyboard is you. But how do we build safer systems? How do we build humane systems, systems that actually engage and even delight the user? Sidney Dekker says "Safety improvements come from organizations monitoring the gap between procedures and practice". How can you build a system for safety if the way the system is designed isn't actually how it's used. Of course it doesn't work, you were doing it wrong. We have to stop shoving users into systems with procedures that aren't based on reality.
In this talk I address these questions through my experience building tools for developers. Every tool works in an ideal world and on my machine. But the hard part is building tools that "work" even when they don't. Understanding the gap between procedure and practice can be a real challenge, and if you don't approach that problem with a big dose of empathy you won't have much luck closing that gap.
It's an oft-quoted adage that too many cooks spoil the soup. But is this always true? At Etsy, we have roughly 40 Ops and Developers making upwards of 20 or 30 Chef changes per day.
In this talk, I'll look at the tools, techniques and workflows we leverage to enable tens of people spread across teams, timezones and even countries to work together to continuously deliver Chef changes with nearly the same frequency we ship code. Although the specific tooling discussed in this talk is designed to work with Chef, many of the techniques and practices I'll talk about are applicable to many other engineering disciplines - the importance of communication and visibility in a Continuously Delivered world, the importance of testing and metrics, and optimising your workflows to remove friction and enable agility while also satisfying the requirements of your stakeholders.
This talk will break down roughly as follows:
• A quick summary of Chef at Etsy - what we use it for, a quick guide to our workflow, and how we think about Chef changes internally
• Tooling & Workflows - the tools and practices we use to deliver our Chef changes, and how we monitor and test our changes.
• The roadbumps we've encountered along the way as we've scaled and evolved our usage of Chef and what we've done to solve those problems
• What next? We're not perfect, and we never stop iterating and improving our workflows. What are the pain points we're experiencing currently, and how are we looking to solve them?
• Jenna Pederson - Stop Blogging About Women In Tech
• Michael Lanyon - Effortless WebPerf Monitoring
• Larye Pohlman - Vulnerability
• Jason Clifford - GameOps
• Jason Walker - Empathy, Fairness, and Contentment
I'm a developer. I barely know what Nagios is, let alone how to set it up or configure new alerts. But I do know a lot about the application I'm working on, and I know how to code. By building a framework for easily adding new monitoring rules, the operations team at Swiftype has opened up application-level monitoring for the whole development team. I'll talk about the tools we wrote and explain how they allow developers to easily add new monitoring checks that probe our application (including web services, queues, and database) and alert the team by email, chat, or phone.
I'll show how to use the monitoring framework we wrote, but I'll also use this collaboration as a jumping off point to discuss how I think developers and operations can work together to build software faster and keep it reliable, based on our experiences at Swiftype.
At Bloom Health, we're operating in a highly regulated environment (including HIPAA & PII) while at the same time running our infrastructure in public cloud. This leads to a number of considerations and tradeoffs when choosing the various parts of our stack. I'll detail the considerations we've undertaken, the compromises and winding paths towards workable solutions, and the specific technologies we've found work better for us as in-house solutions versus those where we've found SaaS to be the optimal (or at least acceptable) choice.
The IT community in the public sector has a sizeable, but frequently forgotten influence on peoples lives. Have you tried to renew a license plate online recently? How about navigated https://www.healthcare.gov/ to get health insurance? Used online learning tools for a public educational institution? Have any of these experiences been pleasant, or what you would expect from a well run modern website? These websites are your tax dollars at work. Are there reasons why we maybe aren't seeing the cultural ideas of DevOps reaching public sector IT shops as quickly?
Public sector organizations differ greatly from private sector organizations with regards to structure, motivations and funding. Other factors such as government mandates for the existence of these organizations, tenured employees and reliance on antiquated domain specific applications can exacerbate the issues caused by these differences.
In the past year or so, we've seen how the discussions around DevOps in enterprise organizations have opened up discussion of many of these cultural ideas to more traditional corporate settings. For DevOps ideas to gain influence the thousands of public sector IT workers, we need to recognize that they too have a separate subset of problems and challenges and start a conversation about how to tackle these issues. This talk will seek to begin that conversation, explain some of the cultural differences between the public and private sectors, explain some of the challenges the public sector faces when trying to break down silos and explain why and how we should evangelize to public sector employees.
Devops has come a long way in the 5+ years since its inception. From simply breaking down silos and automating/measuring all the things, we’ve grown and started talking recently about complexity and inclusivity, burnout and empathy. We started trying to make people's professional lives better in the fields of development and operations; this expanded in two dimensions: both including more teams (QA! Databases! Even security!) and outside of the office, encouraging people to think about burnout and work-life balance.
What’s missing from this picture? Or rather, what’s next for devops? I’d like to propose that, as the lines between the “online” world and the “real” world blur and fade away to nothing, we expand our view of devops to cover this whole new world. Let’s expand our empathy beyond just the tech industry, following the examples of B Corporations who work towards social and environmental good. And let’s talk about how we can make the world better, more empathetic, and safer for everyone, online and off.
• How to make a shift from traditional model to DevOps? (Namrata Rao)
• Repository as an deployment artifact (Inny So)
• Developer Happiness at RedMart (Surya Dharma Tio)
• DevOps and the CFO (Benjamin Henshall)
This is a story of an Infrastructure team at Zalora that implemented DevOps using Haskell and Nix.
The story is about:
• drowning in inherent complexity of existing Puppet configuration
• establishing a functional programming community inside the company
• implementing configuration management using purely-functional language and package manager Nix and using NixOS as the base OS
• challenges of using new tools at scale
• building cloud infrastructure tools using Haskell
• building a code-driven deployment platform borrowing design practices from Erlang/OTP, Mesos and other successful distributed system frameworks, accommodating engineering team growth
• overcoming adoption failures and finally reaching operational happiness
This presentation covers the current state of the Devops movement as presented by one of the original "Core Organizers" of the movement. The presentation will look at some of the taxonomies that have been used to describe Devops such as CAMS and ICE. It will also cover the recent 2015 Devops Survey and we will end up with a discussion about how Devops is being adopted in the enterprise.
At Viki, we run a number of micro services that process thousands of requests per second in various geographical regions. Micro service architecture helps us break down the complexity of building a large distributed system, but also introduces the complexity of debugging an issue.
This talk is about log processing at scale - building an Elasticsearch cluster that can handle tens of thousands of events per second from all levels of a micro-service container based architecture.
My first exposure to a DevOps Days was in 2010. I was an early adopter of most of the tools, took part in the heated iClassify debate, was contributing to Chef before it had a name, back when it was still a pet project at HJK Solutions.. As things evolved, we tried the offshoots that we hoped would fill the gaps.. MCollective, opscode-agent, but really we were just trading one problem for another..
DevOps Days was started in this gap, and over the years I have seen more and more vendor and product encroachment, and fewer people (especially outside of SF) who grasp the roots and the spirit out of which this event was born.
I will be talking about the original spirit of DevOps Days, which i feel started in 1942, and has mutated into a flavor specific to our modern world. I will not be discussing any vendor products, and this is not a sales pitch for anything.
• Sustainable Innovation - the Business Mantra for DevOps in Enterprise (Anoop Kumar Bhat)
• The Power of Personal Influence (Kimble Ngo)
• Agile: Break it down (Yue Lin Choong)
• #noprojects (Evan Leybourn)
• Crawl before you Run, Implementing DevOps (Jason Man)
• Automated Docker Image Builds with Jenkins, Packer, and Kubernetes (Oyvind Roti)
We will share our success stories and lessons learned on working toward Continuous Delivery on a public facing web application for a popular website. This will cover Infrastructure Engineering, Build and Release Engineering, End to End Auditability and Tracability, 1 Click Application Deployments, and Security from the Infrastructure to the Application Workflow.
As service providers(Telco's) begin to transform their business to embrace Virtualization & Cloud ( ie SDN & NFV) their network operations/service delivery teams needs to evolve. While Virtualization & Cloud make it easy to rapidly expand the size of infrastructure, but the habits and practices they used in the past with hardware-based infrastructure don't keep up. The Network operations teams need to adopt IT’s DevOps practices to maximize the potential benefits of the evolving software-defined infrastructure. This includes adopting new tools that enhance agility, implementing agile operational and organizational models and procedures, and in some cases adopting a new culture. The benefits of such an approach are compelling: lower costs and increased agility, including the ability to implement new services in days rather than weeks or months
In this session, we will look at how to take advantage of technologies like cloud, virtualization, and configuration automation to manage IT infrastructure using patterns, practices, and ideas that have been adopted from software development, especially Agile concepts, and brought into the Network Operations world as part of the DevOps movement. Also, we will also go through the challenges and problems created by all these new tools, and the principles and mindset changes that a team needs to make to use them effectively.
There was a company which had typical long running releases and the business was not happy. Business wanted change but IT was not sure how to deliver. Then they heard about Agile. It looked like the magic potion to all their problems.They started doing Agile but it just meant more work for the team and a chaos during the last days of the sprint. Operations was still not happy. Then they heard about another magic potion called Devops, which forced them to think about continuous delivery. I'll talk about the various tools being used in order to bring about this change and what were the challenges that they faced in this journey.The talk has two dimensions: First, The tool chain and Second, how the team was convinced to hop on this journey of continuos delivery. Let me begin by saying that both of the points are equally important and correlated because convincing a team to change is very difficult if the tool selection is not right. I'll also get into a demo of the working pipeline using this toolset.
REA Group is the parent company of one of the most popular Australian websites - realestate.com.au.
Over the past 7 years REA Group has scaled from a 30 odd IT workforce to 200 across multiple locations.
From Waterfall to Agile. From archaic to an employer of choice.
Over my 7 years at REA we have lessons which I’d love to share on
• Hiring Operations and Developers
• Getting Operations and Developers to collaborate
• Optimising teams to be more effective
• Overcoming cultural differences in a distributed team - particularly Asian and Western cultures
• How to knowledge share technical information across the entire company
Developers are trained to communicate to things with a goal in mind. When you're talking to something like, say a computer, you type in your code and it responds by giving you back what you want. Nine times out of ten, it works perfectly. Why, then, is it so difficult to do this same thing when talking to a client about a project, updating a superior on your progress, or pitching an investor your million-dollar idea? Because talking to people requires a special set of skills - namely, empathy and a little bit of storytelling. In an industry filled with brilliant minds, great ideas and mass disruption, so few of the best and brightest know how to tell their compelling story. The takeaways from this workshop will be learning how to value the listener and use vulnerability to improve your social connection.
It's 2:30 AM and you hear your phone buzz. You reach over and see an alert from PagerDuty. That new service your team has been working on for a few weeks has crashed and you don't know the first thing about debugging Clojure apps. After crawling out of bed and logging into your company's VPN you discover your co-workers have left you absolutely no documentation on what to do when "bad things happen". You sit there wondering if you'll be getting back to bed tonight.
Sound familiar? It doesn't have to be this way. On-call doesn't have to be a pit of lost productivity and stress. On-call can actually be a very rewarding experience that improves application stability, increases uptime, and avoids those dreaded 2:30 AM PagerDuty notifications. Let's start thinking about on-call for Humans.
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.
Is your performance monitoring using real-time analytics in a way that will produce results or noise and frustration? Real-time analytics can improve the value of performance monitoring by enabling operations teams to pinpoint problems faster and proactively manage applications, but it’s notoriously difficult to harness its value. In this presentation, we will show you how to avoid the pitfalls of partial analytics implementation, and explain the value of a comprehensive monitoring analytics platform.
Once infrastructure becomes code it becomes testable as code (testing is generally considered a pretty good idea). It also becomes reviewable as code. Code review is a powerful complement to testing (and might just be the more effective of the two for finding bugs), spreading knowledge, and improving at the craft of programming
In this talk:
- Be convinced reviewing code review is also a pretty good idea.
- Cover pre and post commit workflows and example tooling to make your day better.
- Lessons from the messy growing pains of growing an organization from virtually no formal code review to reviewing every commit.
- Best practices for being an effective reviewer and reviewee.
Government agencies are often hesitant to use open source tools out of concerns of security and compliance issues. This hesitancy to use open source deprives many government agencies from closely collaborating with others to create software that is finely tuned and widely available to scratch its own itch. The five-year old OpenSCAP community is helping to change that and re-imagining the US Governments role in open source through its NIST-Certified SCAP 1.2 scanning software and growing body of open source licensed SCAP content. By the OpenSCAP suite scanning and configuration management tools, government agencies looking to become high velocity organizations can automate the cumbersome process certifying a server has been properly hardened for production and begin to develop community resources for hardening of other popular open source tools. The OpenSCAP community is actively developing suite of software tools to make continuous monitoring in agile environments easier, especially for developers, who often do not realize they could be scanning their systems more collaboratively with Ops. OpenSCAP is not merely a secure piece of open source software, it is software that helps demonstrate security and compliance. The SCAP-Security-Guide Project is the only source of official configuration management SCAP and hardening content for Linux that is licensed open source and also directly reviewed by official government agencies. Initially started (and still significantly funded) by Red Hat, the OpenSCAP project has recently moved it's repository from the the Fedora Project to GitHub and has seen an increase in the pace of development.
In a quest to move faster, organizations can end up creating security vulnerabilities using the tools and products meant to protect them. Both Chris Gates and Ken Johnson will share their collaborative research into the technology driving DevOps as well as share their stories of what happens when these tools are used insecurely as well as when the tools are just insecure.
Technologies discussed will encompass AWS Technology, Chef, Puppet, Hudson/Jenkins, Vagrant, Kickstart and much, much more. This talk will most definitely be an entertaining one but a cautionary tale as well, provoking attendees into action. Ultimately, this is research targeted towards awareness for those operating within a DevOps environment.
Or, "Automation is hard and the enterprise is large."
Fewer steps, decreased time-to-production, faster iteration cycles... Devops practically sells itself - except when it doesn't. You can do all the right things but if you don't make it matter for Mission(tm), nobody will listen. We're very good at the first step toward excellence (doing great things) but we often forget about the follow-up - talk about it. But how? Where? Changing culture isn't easy, especially when you're a single person inside a huge government organization. We'll show a few tips we've learned along our journey toward making government work a little less painful. Speed of government? Red tape? Legions of bureaucrats with nothing better to do than slow you down? We know your pain. We're here to help.
We pursue increasingly rapid delivery cycles while acheiving previously unimaginable degrees of scalability, reliability, and raw performance. But there is obviously a growing and serious mismatch between our develoment and operations performance in securing our applications compared to our performance in other areas. I work at a company extensively involved in Drupal and other open source projects that concentrate on both DevOps and security, but continue to be plagued by serious security vulnerabilities. Organizations and individuals negatively affected by Heartbleed and other security flaws probably would have readily traded some delay in accessing new features or temporary access problems for better security. So, how can we better focus DevOps culture and practices on the concept of Continous Security to deliver this? Perhaps we need to look at ongoing advances in automated security testing, more rigorous and frequent manual code review, and paired/team programming practices, and work better on more fully integrating these all into DevOps.
Right-sizing your environment is one of the most stressful decisions to make when moving to the cloud. If you under-provision resources, systems are at risk of going down and you lose money. If you over-provision, you’re wasting money that could be used elsewhere. In this presentation, we’ll share with you 3 ways we’ve learned how to get capacity utilization wrong and how we eventually got it right.
- CPU measurement alone won’t give you the full view of your infrastructure utilization
- You can’t measure the utilization for a metric if you don’t know how high it can go
- If you only rely on request count and don’t include queue length, you will miss an early warning
W. Edwards Deming offered 14 key principles for management to follow for significantly improving the effectiveness of a business or organization. Many of the principles are philosophical. Others are more programmatic. All are transformative in nature. The points were first presented in his book Out of the Crisis.
Recent publications from EUROCONTROL (the European Organisation for the Safety of Air Navigation) provide a concise and accessible way to learn the principles & practices of Systems Thinking for Safety. This provides a quick way to establish a foundation of fundamental principles and practical advice for organizations adopting Blameless Postmortems as part of their DevOps practices.
Tips, Insights, and Anecdotes about how do deal with moving towards a DevOps culture as an introvert.
Vagrant helps developers minimize the difference between production and development environments. That's great for developers, but why should the rest of the team care? This talk will discuss several features of Vagrant that will increase consistency and minimize surprises throughout the deployment pipeline. The discussion will be non-technical, focusing on the value for the entire team.
Delali Dzirasa is Founder and President of Fearless Solutions, a software firm based out of Baltimore, MD. Delali is a Certified Scrum Master and PMP® with a decade of experience leading agile software teams and programs. . Delali Dzirasa graduated with a B.S. in Computer Engineering from the University Maryland, Baltimore County (UMBC) in 2004. Delali always had a passion for entrepreneurship and after working at a handful of technology firms, he founded Fearless in 2009. Fearless is a company driven by delivering innovative products and services to our customers that make a difference.
Delali strives to make a difference in technology as well as his surrounding community. He serves as a Board Member on the UMBC Computer Science and Electrical Engineering Visiting Committee and an active volunteer and member of the Central Maryland Chapter of AFCEA.
He currently resides with his wife and son in Baltimore City, where he is passionate about increasing the rate of city youth heading into STEM based fields.
When Delali isn’t busy running Fearless (rarely), he enjoys working out and hanging out with friends and family. He can be reached at delalid@fearsol.com.
DevOps has been a hot topic in the industry for some time now. A lot of people been talking about it. Some have built business models around DevOps-related tools and themes. People have made career around talking about it. In light of all of that, I find it chuckle-worthy that very few people actually know what DevOps is (just follow #devops on Twitter for proof.) I am not going to be one of many trying to create a buzzword-infested definition of DevOps to suit my particular agenda. Instead, I’d like to demystify some of the more common misconception about what DevOps is.
With continuous development, we write less code and consume more re-usable open source code. Innovation is accelerated and so is application complexity.
Complexity is the enemy of quality. Poor quality creates unplanned break-fixes. Break-fixes create a drag on development speed. It’s a continuous loop. What if we could deliver applications on-time (even faster), on-budget (even more efficiently) and with a natural byproduct of less risk?
The good news: other industries have with supply chain management. Applying supply chain approaches to software raises the bar on continuous goals. Get practical tips from the software supply chain playbook to: -Scrutinize the number and quality of your “suppliers” -Manage out avoidable risk and bloat -Improve traceability and visibility -Ensure prompt agile responses when things go wrong
The potential of new legislation with the Cyber Supply Chain Transparency & Remediation Act makes this a particularly important topic for Federal Agencies and the ISVs and SIs who provide software to them. This session will also provide background on this act and provide practical guidance on how respond to and benefit from it.
A quick tour through the tools, techniques and things to look out for in order to deliver a fast web experience. We will cover a broad range of topics including:
- Reporting the performance of users visiting your sites
- New browser primitives that provide incredible insight and diagnostics as well as upcoming specs to be aware of
- Testing for web performance
- Best practices around what to measure and how
- Practical hands-on examples with WebPageTest
- What it takes to deliver a visually fast experience
- Implications for mobile
- What changes with HTTP/2
- CDN's
- Third-Party code (Ads, Analytics, Social, etc)
The Lean approach champions quick, cheap experiments designed to test hypotheses. It seeks to spend as few resources as possible determining what to build and then, once discovered, to pull back hard and build the thing right.
However, typically in our environment, we scope a project, assume it's the right thing to build, try to build it right, and do whatever's necessary to get it into production, which takes incredible effort.
During this session, I'll tell the story of how we applied Lean principles to pivot a project away from our traditional many-people/many-months approach and towards a resource-constrained discovery phase. Our output was both working software which the stakeholder team could use to validate their assumptions about project direction, and a much better understanding of several early technical uncertainties that represented risk to the original project.
This session will cover the history of Devops. We will look at some of it’s early influences and influencers. Also included will be some best practice case studies and an overview of some of the most widely used tools.
Welcome to the US Patent and Trademark Office. Our CIO will share some insights on why DevOps is so important to the USPTO.