The DevOps world is all about speed. We ship fast, and we’re proud of that. But with our infrastructure changing every day, and the complexity, requirements, and size of projects getting greater, it has become challenging and time-consuming to meet the quality expectations. In order to work together and collaborate effectively in a high velocity environment, uncertainty and complexity needs to be reduced. This talk will cover a devops workflow that helps establish trust in your software development and release process.
It's a common question from security practitioners in any development practice: how do I secure the code my development team is building? The challenge of answering this question in DevOps: the time between developer check-in and deployment is measured in minutes, not days or weeks. But focusing only on speed without understanding the goals of DevOps can lead to undesirable trade-offs, like unnecessarily shutting down the build pipeline. In this presentation, we establish five principles for securing DevOps development (Automate Security In, Integrate to Fail Quickly, No False Alarms, Build Security Champions, Keep Operational Visibility). We review the state of the art of application security practices and talk about ways to leverage the principles and practices of DevOps, such as quick feedback loops and feature toggling, to create more secure code. And we look at organizational, process, and technology innovations to secure applications in ways that incorporate, but go beyond, testing for vulnerabilities, by looking at what developers can do before checking in code and what application security looks like in production.
When you scale up an infrastructure it is crucial that you can trust you have the right resources in play, the right code deployed and that information can only flow in a secure manner. When you scale the organization, trust is required amongst all of the people responsible for coding, testing, deploying and managing the applications that power the business. With all of the chatter around scaling, you would think someone would have told you the key ingredient necessary for creating and fostering the required trust. Unfortunately it is very easy to get to the end of the diving board, right on the edge of jumping into something like a hybrid cloud deployment, before you realize you need to figure this out on your own. This talk can help. We'll discuss some concrete ways you can engineer trust into the system (complete with examples) you are building or operating so that it works well for cloud-native and legacy applications. By the end, you'll have a good idea of the decision/enforcement points you'll need to consider to be able to create a system (and an organization) that can scale.
SRE is a topic that most recently has become a popular discussion across many companies I have interacted with. What is SRE? Who are SRE's? How do we get it? I, just like everyone else have opinions around this topic. However there is a common ground between us all. SRE is not only about tooling and tech, but it is primarily a CULTURAL shift within companies. Now, just as a disclaimer these are just my opinions and experiences with building organizations like this and talking to other companies who have implemented or are implementing this. There is no prescription to building SRE. Everyone will find a way that this fits their company and build this according to their current operating model. Forcing this in because it's the new fad is not the best approach but that's up to you...
Sharon is the founder of Communilogue, an agency specializing in helping teams foster greater collaboration. A life-long stutterer, she uses her speech limitation to teach conference audiences as well as teams at companies about the value of vulnerability in communication. An internationally recognized public speaker, she’s given keynotes, hosted workshops and spoken in house to companies. Sharon’s talks inspire attendees to be more empathetic communicators, and they empower attendees to be more inclusive in their personal and professional lives. Originally from Chicago, she lives in Pittsburgh with her partner. You can learn more about her work at Communilogue.com.
We are inundated with more and more data everyday. From system notifications, to alerts, SMS, to push, we're constantly notified of things happening. Additionally we're having to take more and more data into consideration in order to make a proper decision. When working in a business critical alerting environment where decisions can cost 1,000's of dollars in a matter of minutes, how do you take in all the data from multiple alerts and balance that data against what your 'gut' tells you? We'll look at how our brains process information, go back in time to look at our primitive brains, and use some insights about our modern brains to help provide some guidance on how to make that critical decision under pressure!
No critique of bimodal IT is complete without a board game analogy; here's mine. What if Wardley maps were hex-based? In the game Settlers of Catan, players vie for longest road, largest army, and resource monopolies on the game board. But when the Cities and Knights expansion is added to the game, suddenly there are multiple paths to victory. In Accidental Empires, Robert X. Cringely's history of Silicon Valley, he talks about commandos, infantry, and police. Simon Wardley talks about pioneers, settlers, and town planners. The concept remains the same: some innovate, others turn the innovations into products, and still others make products into commodities. This talk will explain mapping of the enterprise IT journey by way of board games, with whimsical asides.
Although the jobs of software engineer and chef are vastly different, there are a lot of interesting similarities. I'll share a few valuable lessons on tools, technique, burnout and camaraderie that I learned while cooking in some of the world's best restaurants and how they apply to working in tech.
How do young women of color see themselves in the products they are using in their everyday lives?" "What information should be included in technology tools that accurately reflect the cultural roots of girls of color?" "How can more young women of color interested in technology create a voice for the consumer?" These critical questions and several others will be addressed in this workshop that invites students to identify how social justice principles plays a role in technology advancement. Specifically, this session will expose students to the role of unconscious bias and how certain beliefs and assumptions influence their relationship with technological products and experiences. User experience is one approach to address issues of unconscious bias often times found in technology. User experience, a field rooted in diverse social science fields such as sociology and psychology, assesses the interaction and perceptions that people have when using a product of service. In this session, attendees will be introduced and be able to engage in practical application in the following UX fundamentals: user research and user design. Participants will learn how to understand and incorporate the needs of groups with detailed research and design a process that allows users to interact with a technological product and experience from moment to moment. Participants will be able to identify user experience (UX) design to overcome challenges in unconscious biases in technology both from an entrepreneurial and consumer perspective. Lessons learned and long-term implications for this approach will also be addressed.
Six months ago my team decided to take a RESTful web service (Conqueso) and rewrite it in a more scalable, auditable, highly-available fashion (propsd). As operations people, this was our first foray into delivering a software product together. We flailed spectacularly, learned a lot, and got a thank you note in the end. This is a three-part story about the things we learned. Each part covers a chunk of the development cycle: design, coding, maintenance. We discovered that patterns that work in operations can become anti-patterns in development. During the design phase we found that "Divide & Conquer" works for patching servers but doesn't translate well into writing technical specifications. While coding we saw that "Lone Wolves" are a perfect fit for fixing on-call issues but a poor fit for collaborative development. In maintenance mode we "Monitored All the Things", but no one knew because we forgot to send out status updates. Because propsd is open source, our journey and learning is lovingly documented by code, comments, and pull requests. So maybe other operations teams figuring out how to do development don't have to go through the same pain? At least, that's my hope by telling this story.
Wouldn't we all want to work at an organization that values and rewards the contribution of knowledge workers? Wouldn't it be easier if our current organizations prioritized learning, experimentation, and collaboration as key success factors? Well...yes! But we must deal with the realities in front of us, not those wish to be. Even after ample research substantiating the benefits of organizations moving towards more autonomy, faster feedback and a culture of relentless learning, many orgs still hold on to the notion of power, while putting on a front of change and collaboration.
Understanding feedback through a systems lens has advantages. This pure feedback loop is more accurate, it moves us away from needless judgement, and it enhances accountability just to name a few. By taking a step back and examining the feedback and data we receive in three different ways, we can understand it much clearer. Those ways are: 1) Are differences between the giver and receiver creating friction for the feedback? 2) Is the feedback partly related to the differing roles between giver and receiver as it relates to the common "system"? 3) Are processes, policies, physical environment, or other factors within the system reinforcing problems with the feedback? Allowing ourselves to view feedback from a "Systems Thinking" model, we can begin to look for patterns, understand the feedback loop with more accuracy, and identify contributing factors to both failure and success.This quick (IGNITE-style) talk will discuss feedback from a "Systems Thinking" perspective.
3AM sure does seem to get a lot of flack. It's the timeframe of choice for horror stories of ailing infrastructure, broken backups, and overly caffeinated engineers. How often does 3AM get thrown under the bus? This tongue-in-cheek lightning talk will take a look at all of the ways that 3AM seems to get referenced both inside and outside of of the technology industry. Graphs may be involved, but not willingly.
In this talk, we will see what happens when we stop looking at our infrastructure development as just a bundle of scripts and start looking at it as an application. We will go over various concepts in the programming world that can be carried into infrastructure development, including local development, test-driven code, modular applications, and static code analysis. Out of this talk, I hope to give operations engineers a new way to build out systems and feel more confident in the stability of their infrastructure.
In the past year Google, the NSA, and NIST have urged developers and theorists to get more serious about quantum computing. What are quantum computers, do they exist, and if so, how do we keep stuff secret from them? How does this change TLS/SSL? Also covering lots more benefits of researching post-quantum encryption today.