Conway's Law tells us "organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." When organizations are healthy and dynamic, adaptability and high-quality software result. Unhealthy organizations “ship the org chart”, producing software that reflects dysfunctional practices. What if we turn Conway's law around and make technology choices that improve our culture? Can bad software choices create new rifts? Are we selecting tech that disempowers developers and keeps operations up at night? Is our software architecture secretly encoding new divisions between our teams? I've run containers in production, written microservices, and operated all manner of infrastructure from established favorites to the latest hipster trends. Let's talk about how all the usual technological suspects (and maybe a few surprising ones) can shape the organizational culture in startups and enterprises alike.
Leaving the comfort zone of throwing code over the wall so the OPS team can deploy takes either guts or insanity. Developers should care more about how their products reach customers and one of the best ways to do this is to get into DevOps and involve themselves in the process of making sure the code is doing it's best being a good citizen in the actual environment. We'll see some of the hops, prejudices and issues developers have to face when they start their journey into the DevOps land and how this will improve their skill set and the final experience customers have actually using the product.
Well-funded tech companies are hiring consultants or high-level leaders to help them create inclusive work cultures. But if you don't have the budget for a consultant or a Chief Diversity Officer, we can walk you through some tried and true DIY steps to creating a more inclusive work environment. We will focus on the four pillars of workplace inclusion: hiring, retention, promotion, and culture. Whether you're a 4-person start-up or a 200-person international tech company, a CEO or an entry-level developer, our DIY guide will provide you with the tools to create a more inclusive environment that will benefit employees and an organization's bottom line.
Have you ever played buzz-word bingo at a conference before? Attend this interactive session (with real Bingo!) where Ross Kukulinski, a NodeJS Evangelist, container enthusiast, and NodeSource technical product manager will share his cloud-native implementation of the Internet Archive’s Wayback Machine. Ross will share his goals, architecture, and technology stack choices to implement a scalable, containerized, microservice implementation of the Wayback Machine using Node.JS, Docker, and Kubernetes. Topics covered in the talk will include: Architecture Scaling Monitoring CI/CD Live demo
Behind the extensive downtimes I witness every holiday, I see a corporate failure to change the archaic processes to match the change in business models. Technology space has evolved. Businesses, however, especially larger ones, have a natural aversion to change, that is often justified by risk and cost factors. However, processes are put in place for exactly that reason — to save time and money. If they don’t accomplish those two goals or worse, contributing to the opposite – they need to be changed. In this talk I'll discuss a real world example of Black Friday 8 hour downtime of a large e-commerce website and discuss key anti-DevOps patterns contributing to the failure.
A brief History of Linux containers to provide understanding of where the technology came from. The history will be able to shed some light on the development of containers, and help with the understanding of the current implementations.
Earlier bill pay services were scattered in different regions, delivered in different release cycles by different teams. Consolidating all those services to a Microservice, integrated with CI/CD to deploy on AWS made it convenient and faster for team to deliver bug fixes or new services faster to client.
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.
End-to-end monitoring, testing, and validation of an application or service can be helpful to both development and the business if done properly. It lets you answer the age old question "Is $APP up?" with confidence. Especially when individual service-owning teams are part of a larger whole, having a way to rapidly iterate and verify your changes is vital. This talk will go over background & history on end-to-end testing efforts, then discuss best practices for care and feeding of such systems, and pitfalls to avoid, with references.
Cloud computing and the advancement of tools for resource management and infrastructure automation have created unconventional forms of processing massive amounts of data, both efficiently, reliably and cost effectively. The effects of cloud computing can be visible in everyday life. Academic research is one of the fields that can benefit greatly from cloud computing. Particularly, genomics projects have successfully adopted cloud computing in research, and some start-ups have been created to offer services for mapping gene information to find links to pathologies by using AWS. Beyond genomics research projects, there is a vast amount of geospatial, satellite imagery, weather, news and other types of data available for analysis (https://aws.amazon.com/public-data-sets). To date, most compute intensive research tasks are run in supercomputers; the implementation of cloud computing has not been as fast as in other areas. Here it is proposed the utilization of AWS to analyze a set of data, automating the deployment of infrastructure and trigger analysis when a set of data is uploaded. This example shows scalability and elasticity of public clouds and can be easily applied to other types of analytics.
Managing application secrets, such as database passwords or API keys, can be a tricky problem in any environment. It becomes even trickier when we have an end-to-end Continuous Delivery pipeline, deploying an application with no human intervention. The question becomes: how do we maintain secrets in source control, along with the infrastructure and functional code, without exposing them to everyone? Additionally, CapitalOne, being a large financial institution, is subject to regulations like "segregation of duties", which prohibits developers from having admin access to production. Using a combination of AWS KMS, IAM, and iptables, we were able to design a simple, cheap, and scalable solution that satisfies our security needs, as well as the regulatory requirements.
Devops is culture enabled by tools, which are necessary but not sufficient. I touch on the history of devopsdays and the motivations that lead orgs to devops, while encouraging orgs to collaborate, communicate, and iterate towards increasing value for their orgs.
I was the regular enterprise sysadmin: network administrator & datacenter systems engineer in an ISP, IT operation support administrator in a retail company and IT systems engineer in a software development company. I spent time on choosing cool names for my servers. I knew the exact location of a server in the datacenter. I felt sad when their lights stopped blinking. I felt more sad it that happened on a weekend night. And then I joined a team adopting the DevOps mindset. Let me be honest: change was scary! But it was also a great learning experience. This talk will share what was challenging and what worked for me in my transition from being a regular sysadmin to living and breathing DevOps.
With the rise in telecommuting as an effective business strategy, we all deal with remote workers at some point during our work hours -- whether they are teammates or clients. Learn some tips and tricks I’ve picked up over several years as a remote worker working with teammates and clients from afar.
One of the most overlooked advantages of converting to a DevOps culture can be the reduction of stress. This could be due to “sharing the load” as a whole team, the feeling of joint ownership in solving a business problem, or many other things. If you’re asked to support somebody else’s application without any insight to how it was built and what problems it’s trying to solve you’re likely to experience more than a little stress. The same is true if you’ve toiled away creating the perfect application only to see it deployed in a way that makes it unable to perform. The combination of stress and burnout is perhaps the biggest health threat in our industry. In fact, recent research has found that burnout--and the related concept of ""vital exhaustion""--increases your risk of cardiovascular disease as much as body mass index, smoking and lipid levels. Unfortunately there are also well-known stories of burnout-related suicides in our industry, making this literally a life and death issue. If that isn’t reason enough to address the issue, we also know from the State of DevOps survey that the #1 indicator of company success is job satisfaction. In this talk Ken will go over some of the leading research in the area of burnout. We’ll talk about some of the more common causes of burnout as identified by clinical research and talk about how you can learn from organizations with solid DevOps cultural practices to help alleviate them.