When embarking on a journey of transformation, you want to measure your current status and subsequent progress while keeping tabs on factors that drive improvement in technology performance. Nicole Forsgren explains the importance of knowing how (and what) to measure—ensuring you catch successes and failures when they first show up, not just when they’re epic.
Amazon Elastic Container Service is an orchestration service for Docker containers in clusters of EC2 instances. We’ll dive into the details of how Capital One deployed its first ECS cluster, with full zero-downtime continuous delivery and multi-region resiliency for both the ECS cluster itself and services deployed to it.
Auto scaling architecture for ECS clusters with CloudFormation and multiple environments
Continuous delivery for ECS clusters with zero-downtime blue/green deployments
Logging and monitoring with CloudWatch, New Relic, and ELK
Data is an integral part of every application, so why aren’t we talking about it more when it comes to DevOps and including the DBAs in this important conversation. In this session, we’ll talk about why the database has been left behind and the special challenges it presents. We’ll also explore the similarities to application development and show that even though there are challenges, it is possible to include your database in DevOps processes. It’s time to start thinking about incorporating your databases into your best practices so it’s no longer the bottleneck.
Are the benefits of containerization limited to ease of integration, testing, deployment and operations? David Grizzanti explains how his team at Comcast – which develops a highly performant, distributed software system supporting millions of customers and deployed across multiple data centers – moved large-scale, multi-data-center services from an architecture deployed on virtual machines supported by separate development and operations teams to one based on containers with Apache Mesos operated by a single DevOps team, sharing how Comcast overcame multiple challenges – some that were anticipated and many that were not.
David discusses the team’s journey from excited experimentation through the valleys of frustration and ultimately to a deeper appreciation for containerization and explains how they were able to get everything working; and optimize the architecture to support service discovery and multitenancy in some interesting ways.
Topics include: - Some of the basics: Environments, tools, choices - War games and surprises: IP addresses, logging, metrics - Team organization: Taking responsibility for development, integration, and operations of the platform - Application errors under load - Debugging performance - Scaling the application up - Supporting multi-tenancy - Simplifying the application’s core algorithm - Achieving superior performance
We do a lot of things in the name of progress. We have Agile, Scrum and as they are applied to Systems Administration we now have DevOps. But why do we do it all, why have we invented and described all new methodologies and processes? Is it to find a perfect budgeting method? Is to to find a perfect plan? Is it to make an on time schedule? Is it to have defect free systems? Those could all be potential side effects, but not the ultimate goal of why we do it all. We don’t have time for the five whys, but lets shorten the process and see if we can get to the root of it all.
The ideal DevOps project starts with everything stored in source control. As a coach I often find that too little thought is given to how a team will handle their source control branching strategy. Time and time again I have seen how this lone decision determines much of the complexity of both product and process. The ease of your journey to continuous delivery is largely dependent on this decision. I’d like to discuss this idea and talk about teams seeing success when they take time to make this decision and don’t just buy into master-only development or a model such as git flow. Instead, they think about how they want to manage complexity, and it starts with source control and branching strategy.
Choosing appropriate tooling for the provisioning of virtual infrastructure such as servers, storage, and networking components is a challenge due to the variety of available tools. These tools range from provider-native services such as AWS CloudFormation to multi-provider technologies such as Hashicorp’s Terraform. Between the native and non-native solutions is a family of light-weight tools that operate directly on provider-native template files. I will briefly review the trade-offs between the different types of tooling, discuss why we chose the CloudFormation template-generating library SparkleFormation to meet our specific goals, and conclude with a tour of our SparkleFormation implementation.
How hackathons should be built around helping the community- so longer hackathons judged based on the number of lives they positively impact and not just how cool they are
What can WordPress gain from Serverless Architecture?
WordPress is the most widely used CMS and a prime target for that reason. Going Serverless means there’s no Dashboard to hack and sites can now serve millions of hits per day with zero downtime or bottlenecks. This approach to hosting is more secure and scalable than any traditional web hosting product at a fraction of the cost.
I would like to demonstrate the benefits and how-to of taking WordPress Serverless. This would include a basic level understanding of what Serverless is, limitations, benefits, and tools available
My team has developed a SaaS product for this called, Shifter. Built entirely on AWS, we use the Serverless Framework, AWS Lambda, Docker and more to make this possible.
Talk 1 00:00
Talk 2 1:49
Talk 3 3:28
Talk 4 5:08
In 2011 we delivered 2 major releases of our on premise enterprise software. Market, technology and customer requirements forced us to change that in order to remain competitive.
Now – in 2017 - we are deploying and providing feature releases every 2 weeks for both our on premise and SaaS-based offering. We deploy 170 SaaS production changes per day and have a DevOps pipeline that allows us to deploy a code change within 1h if necessary.
To increase quality, we built and provide a DevOps pipeline that currently executes 31000 Unit ABSTRACT Integration Tests per Hour as well as 60h UI Tests per Build. Our application teams are responsible end-to-end for their features and use production monitoring to validate their deployments which allows them to find 93% of bugs in production before it impacts our end users.
In this session I explain how this transformation worked from both “Top Down” as well as “Bottom Up” in our organization. A key component was the 4 people strong DevOps Team w
I will also talk about the “dark moments” as change is never without friction. Both internally as well as with our customers who also had to get used to more rapid changes.
Successful mentoring doesn’t just happen, it’s planned. We will discuss what mentoring is not, what mentoring is, factors for effective mentorship, and why it’s important to the developer community.
Let’s make a valuable interview by setting better expectations and creating better evaluation techniques.
Let’s make an honest interview by asking instead of assuming, and treating candidates like they’ll be treated on the team.
Let’s make a collective interview by encouraging dialog and testing a candidate’s to teach, learn, and work with teammates.
Let’s make a nice interview by ensuring the process is valuable to the candidate even if they’re not yet ready to join the team.
We will explore the value of bringing Serverless development to your operations and developer teams, and how it fits with DevOps culture. This talk will offer an introduction to Serverless applications, practical options for replacing infrastructure with Serverless, and will explore developer culture.
Which cloud do we want: public, private, hybrid? How are we going to orchestrate containers? How many pizzas should our teams eat? Should everyone be on call, even front-end? Maybe we should only hire full-stack ninjas? Do we even want to dev some ops, or do we need site reliability instead? Technical decision-making is a sea of bad and worse choices waiting to happen; let’s talk about it.
Rarely do we have the opportunity to introduce the DevOps “Kai-Zen” mindset at the genesis of a team or project. But isn’t that the beauty of Continuous Improvement? It can begin anywhere and never ends. Here are some tips for introducing DevOps to a team with an established culture.
After many years doing DevOps-y things before learning the term “DevOps”, I moved to a larger, more traditional IT organization, with a goal of helping modernize their outdated technologies and practices. The next several years brought many challenges – technical, political, and interpersonal – some of which were more easily overcome, and some of which, well, not so much.
I’ll tell the story from where we started (spoiler alert: it’s about as much juicy legacy as anyone can handle) to where we ended up, what we got right, and where I went wrong. Whether you’re just starting out on your DevOps journey, or are well on your way, I hope I can impart some of what I’ve learned, for you to take back and help maximize the quality of your own teams’ relationships.
Genome-wide association studies (GWAS) have revealed associations between human genetic variants and hundreds of human traits, including disease susceptibility. We found that differences in quality control (QC) upstream of GWAS critically affect the results. Despite this, no clear mechanism for reproducibility of GWAS QC pipelines exists to our knowledge. We developed CLINK, a cloud-based interactive GWAS QC tool focused on reproducibility. We use Amazon Web Services (AWS) machine images, adopting a dev/ops model to develop a version-controlled virtual appliance geared around the Jupyter Notebook. We demonstrate the reproducibility of CLINK using a large case/control study of primary open-angle glaucoma, a leading cause of irreversible blindness.
Software architecture. Software engineering. Software construction. Practitioners of the architecture, engineering, and construction of buildings might consider these terms to be overly lofty for the craft of software development. One of these industries is plagued by cost overruns, failed projects, religious battles over methodologies, dysfunctional teams, and unhappy clients, but is also innovative, socially conscious, and applying technology to solve real-world problems. And the other is software development.
Tim Gross worked for a decade in the building industry before switching to building software. In this talk Tim will explore how designing and constructing buildings is nothing like your software project – except in all the ways that they both succeed and fail.
Talk One 00:00
Talk Two 1:51
Talk Three 3:26
Talk Four 5:01
In DevOps it is common to have Ruby, Python and Bash on all Windows machines - will you install PowerShell on your Mac workstation and Linux servers?
What if PowerShell’s platform of origin had not been Windows or if it had not started as a proprietary product? Would you view it differently today?
This talk is about how the architecture of PowerShell puts developer productivity front and center and how that has a direct, practical, positive effect on the individual developer experience as well as team level benefits.
This intentional design aspect of PowerShell causes it to generate real business ROI as well as individual developer productivity.
This is my second time around with a hyper-productive shell environment as it was OS/400 that some of PowerShell’s key concepts were pulled from.
As background, I maintain a PowerShell universal installer for the Microsoft port of OpenSSH as well as a Bash universal installer for installing PowerShell Core on Linux and OSX. I have also written a multi-platform PowerShell script to make an AWS account compliant with the CIS AWS Foundations Benchmark.
If you don’t enjoy being productive, this session is not for you.