Merge pull request #12 from margaretvaltie/heroku

Heroku

content/events/2019-boston/program.md

@@ -0,0 +1,13 @@
++++
+Title = "Program"
+Type = "program"
+Description = "Program for DevOpsDays Boston 2019"
++++
+
+<div class = "row">
+  <div class = "col">
+    <hr />
+    If Open Space is new to you, you may be interested in <a href="/pages/open-space-format">more details about Open Space</a>.
+    <hr />
+  </div>
+</div>

content/events/2019-boston/program/anand-tiwari.md

@@ -0,0 +1,35 @@
+---
+title: "DevSecOps - Automating Security in DevOps"
+Type: "talk"
+Speakers: ["anand-tiwari"]
+
+---
+As part of this workshop attendees will receive a state-of-the-art DevSecOps tool-chest comprising of various open-source tools and scripts to help the DevOps engineers in automating security within the CI/CD pipeline. While the workshop uses Java/J2EE framework, the workshop is language agnostic and similar tools can be used against other application development frameworks.
+
+The workshop will also present various case studies on how critical bugs and security breaches affecting popular software and applications could have been prevented using a simple DevSecOps approach.
+Why DevSecOps ?
+The DevSecOps process will help in
+
+* Create a security culture/mindset amongst the already integrated “DevOps” team.
+* Find and fix security bugs as early in SDLC as possible.
+* The culture promotes the philosophy “security is everyone’s problem”.
+* Integrate all security software centrally and utilize the results more effectively.
+* Measure and shrink the attack surface
+
+Course Outline
+
+The following topics will be covered encompassing the entire Secure DevOps pipeline
+
+* Introduction and overview of DevOps
+* What and Why of DevSecOps ?
+* Integrating Security in CI/CD
+* Vulnerability Management using Archerysec
+* Secret Management using Vault, Jenkins and Docker Secrets
+* Security in Developer Workstations: Pre-Commit Hooks using Talisman
+* Software Composition Analysis using Dependency-Checker
+* SAST - Static Application Security Testing using FindSecBugs
+* DAST - Dynamic Application Security Testing using ZAP and OpenVAS
+* Compliance as Code using Inspec
+* Security in Infrastructure as a Code using Clair
+* Production Real-Time Alerting and Monitoring using Modsecurity WAF
+*     Challenges in DevSecOps

content/events/2019-boston/program/andrew-kirkpatrick.md

@@ -0,0 +1,11 @@
+---
+title: "Containerizing legacy applications with dynamic file-based configurations and secrets"
+Type: "talk"
+Speakers: ["andrew-kirkpatrick"]
+
+---
+Most applications nowadays are designed with containers in mind, or older projects are updated to be run within them. But what if you don’t have the time, resources or the authority to modify your applications?
+
+Additionally, with service discovery, secure secrets management and dynamic secrets rotation now becoming commonplace, what is the easiest way to utilize these in an application without modifying how it handles configuration or polls for changes?
+
+There are a few ways to facilitate this, from simple ConfigMaps to cross-container volume mounts with config-watchers to using Consul Template with Consul and Vault. It depends how quickly you want to get started and how complex your use-case is!

content/events/2019-boston/program/angel-rivera.md

@@ -0,0 +1,10 @@
+---
+title: "Apps, Stacks, and Frameworks: Avoiding “Shiny Object” Syndrome"
+Type: "talk"
+Speakers: ["angel-rivera"]
+
+---
+
+Technology is fast moving, and devops tools pop up like wildfire. Teams are desperate to solve their problems & often make implementation decisions based on word of mouth, “kick the tires” syndrome or superficial evaluations. In some cases we justify our stack decisions based on project/sprint deadlines, the product’s marketing materials, occasionally, the README files. Really scary stuff!
+
+In this talk I’ll explore how & why teams are easily lulled into believing that shiny objects will independently solve their stack deficiencies. I’ll discuss my experiences with “Shiny Object” frameworks/tools and the true impact they had in actually solving problems. I’ll also discuss some strategies that can help teams make better choices when properly vetting potential solutions based on my experience in the federal government evaluating vendor proposals and homegrown solutions, as the sole DevOps engineer at a startup and other technical teams throughout my career.

content/events/2019-boston/program/arthur-maltson.md

@@ -0,0 +1,9 @@
+---
+title: "Built With ❤️ - Why Developer Experience Matters"
+Type: "talk"
+Speakers: ["arthur-maltson"]
+
+---
+One evening you’re browsing Twitter and you stumble on a really cool new Open Source tool. The README is intuitive, the installation is seamless and you’re up and running in no time. When using the tool, error messages are clear and how to fix the issues obvious. Before you know it, you’ve achieved what you wanted and you feel like a superstar! But the experience is very different the next day at work. You just spent a couple weeks fiddling to get a project running locally but now you have to jump through hoops to get the application built and deployed with that dreadful internal tool. Why can’t our day time experiences look like our weekend passion projects? It can!
+
+In this session you’ll be introduced to the concept of Developer Experience and why it matters. You’ll then embark on a journey to build a new tool with Developer Experience as a core focus. You’ll learn how certain targeted approaches can improve the Developer Experience through the entire Experience Lifecycle. At the end of the talk you will be equipped with ways to improve the Developer Experience in your work; whether you’re building tools for developers, collaborating with other developers on a business project, or just building a side project one your own.

content/events/2019-boston/program/ben-kehoe.md

@@ -0,0 +1,7 @@
+---
+title: "Applying the Serverless Mindset to Any Tech Stack"
+Type: "talk"
+Speakers: ["ben-kehoe"]
+
+---
+Debates about what technologies are or aren’t serverless are endless and tiresome. The term is now applied to products that require the operator to run their own clusters or manage installations of FaaS platforms. The buzzwordy nature of the term and its overuse obscures a deeper truth: serverless has never been about technologies. Instead, it’s an approach to development that focuses on delivering business value and minimizing total cost of ownership. When taken to its logical conclusion, it results in the technologies we call “serverless”, such as AWS Lambda. But the approach itself is not limited to these technologies: a person or team can apply this approach within the constraints imposed by their organization. The serverless mindset can serve as a compass to guide decision-making even in organizations that are entirely on-prem, leading to faster, more responsive development and lower TCO.

content/events/2019-boston/program/dan-zentgraf.md

@@ -0,0 +1,17 @@
+---
+title: "DevOps and the Database Bottleneck"
+Type: "talk"
+Speakers: ["dan-zentgraf"]
+
+---
+Databases are central to just about every application system but remain a neglected topic when it comes to DevOps. Seriously - while application change delivery has evolved to where changes can be applied in amazingly short intervals, most enterprise databases still live in a silo that exists somewhere on the other side of a bureaucratic ticket-driven process from 2003. To be fair, databases are critical things which, when broken, will break everything else. However, given that you can never be faster than your slowest operation, this central part of application systems is often a drag on teams’ overall throughput. So, something has to give if we are to get through the Database Bottleneck bring agility to application delivery and the businesses it supports.
+
+The good news is that there is an emerging body of knowledge on how to conquer this challenge and this talk will:
+
+* Describe the problem of automating / accelerating database changes
+* Explain how the problem impacts the various roles in app delivery
+* Introduce the two main approaches to database change automation - state-based and migration-based
+* Explain the strengths and weaknesses of each approach
+* Discuss how they fit into CI/CD workflows
+
+This talk will discuss problems, approaches, and solution patterns It will explicitly not have a tool or demo focus, but instead look at the approaches, processes and context into which you can fit tools.

content/events/2019-boston/program/dave-mcallister.md

@@ -0,0 +1,43 @@
+---
+title: "Building Cost Visibility For Your Kubernetes Clusters"
+Type: "talk"
+Speakers: ["dave-mcallister"]
+
+---
+RED (Rates, Errors, Duration) was a spinoff from Google’s Golden Signals designed for monitoring microservices. However, RED use has clearly demonstrated that the applicability is applicable to any services-based architecture.
+
+With RED, unlike the modern belief in observability, your architecture is watched from aspects of multiple dimensions. You receive alerts and indications not just from anomalies, but also from headache alerts. By seeing multiple dimensions of concerns, be they failures in service or activity to close to the edge of capability, these combined monitors and deep-dive, focused access get you to your root cause faster, with less false positives and quicker resolution.
+
+Duration speaks of time. In particular, time to send and receive a specific request. And both client-side and server-side are important in meeting your customers’ desires.
+
+Often this is relegated to distributed request tracing. And while each individual trace is important, so is the sum of the latency experienced across the entire environment. A High Latency Trigger(HLT) in one spot can cause a cascading HLT across the entire system.
+
+In today’s instant gratification world, slow response is bad. So you need to identify not only the headache (alert) but identify and narrow to the culprit as fast as possible.
+
+Errors are just what it says, problems that cause an incorrect, incomplete or unexpected result. They are failures in the code, bugs that appear under production loads (or under peak loads). Errors require rapid response. They require point specific responses. And while errors can be measured as a metric, you will need to dive deep into the structure and get to your root cause as soon as possible. If your business is dependent on the system that failed, ASAP might not even be fast enough.
+
+And BTW, errors can also result in signal anomalies in rate and duration.
+
+Not responding to errors rapidly and specifically result in lost business, unhappy users and stressed DevOps/SRE teams.
+
+Rate, or traffic, can be considered as the number of requests on the network and system. This is the communication pipeline for your apps and your enemy is peak load. While you could think of this as bandwidth, to quote John Mashey, “Bandwidth costs money”. Are you hitting peak loads that exceed your bandwidth?
+
+Rate includes lots of items. High-level ones are like HTTP, SOAP, REST. But keep in mind that it’s not just the web, it’s things like middleware messaging/queuing, API calls. It can also be overhead of control structures like service meshes. Any environment that fails on peak traffic is a suspect for Rate monitoring
+
+With rate breaches, you need to move quickly from the metric measurements to a specific cause, be they in your own services or external factors. And since loads may be temporal, you need to be able to dig into the potential causes after the fact. Just a metric isn’t enough, you’ll need detailed info as well.
+
+With RED, while there can be many alerts, it follows that there are two major categories that apply broadly, anomaly alerts and headache alerts.
+
+Rate is most often an anomaly alert. You’re alerting on something that has crossed a threshold, usually a percentage value. The risk here is that the alert doesn’t get processed in real time. Duration and metrics are most accurately retrieved via logs (after all, a distributed trace is really just a specialized log entry).
+
+As a caveat, anomaly alerts are new, and often do not consider seasonality. They require aggregation, especially when going for the root cause. This is where visualization for humans is vital, as we are still pretty unmatched at pattern extrapolation.
+
+Also, keep in mind that too low may be as indicative as too high. Low saturation at normal high volume times is a definite flag.
+
+Duration crosses the streams, being both an anomaly alert and a headache alert. It’s worthwhile to keep an eye on the total duration/latency of a request as well as on crucial services. While it may be difficult, being able to see duration from the client through the app environment is incredibly useful.
+
+Errors and to a point duration are both headache alerts. Something needs fixing NOW, so get it done. Here you need the alert as fast as possible. You need the information that shows where it occurred, when it occurred and what was going on. Again, log aggregation and threaded displays are vital; sometimes the thing that caused a failure isn’t the thing that failed.
+
+So RED gives you the framework to build alerting, monitoring and analysis into a flexible structure to meet the emerging needs of services-based architectures as well as give you the capability to grow as your environment scales.
+
+Come learn how to make RED something you want to see every day.

content/events/2019-boston/program/dave-stanke.md

@@ -0,0 +1,7 @@
+---
+title: "All Tech is Debt"
+Type: "talk"
+Speakers: ["dave-stanke"]
+
+---
+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.

content/events/2019-boston/program/david-fredericks.md

@@ -0,0 +1,26 @@
+---
+title: "FOMO? Take Control of Your Career and Life!"
+Type: "talk"
+Speakers: ["david-fredericks"]
+
+---
+Our industry has been exploding! This has been amazing for growth and financial advancement of the industry, but comes with a huge negative cost to the workforce.
+
+IME the technical workforce has been the most negatively impacted by this great expansion. When business demands (constantly) exceed capacity, strong leadership must be present to prioritize initiatives to mitigate downstream impacts. Unfortunately, important services for the workforce tend to be the first to go, widening the gap for developing future leaders and technical SME.
+
+Currently, our technological advancement is outpacing our ability to develop the current technical workforce, creating more constraints and disparity among the engineering communities. How can we help to solve this critical issue and maintain the control over our own development and career advancement?
+
+We must EMPOWER every engineer with the information and knowledge to create, implement and execute their own PDP.
+
+This is why I want to drive home the message that everyone is responsible for THEIR own professional development.
+
+My talk will cover:
+
+• What is a professional development plan (PDP)? • When do you need a PDP? • How do you start a PDP? • Why is a PDP so important? • Who needs to be involved?
+
+Professional planning is a journey. The more individuals learn, the more aware they become of what is valuable to them. This is why it is extremely important to emphasize the value that comes from going through the process.
+
+Setting up a PDP Framework:
+
+• Continuing Education • Skills Training • EQ
+• Professional Networking

content/events/2019-boston/program/doran-smestad.md

@@ -0,0 +1,12 @@
+---
+title: "DevOps for the Startup: how to efficiently find market fit."
+Type: "talk"
+Speakers: ["doran-smestad"]
+
+---
+
+Most conversations around DevOps and Site Reliability Engineering (SRE) focus on medium to large business. Where there are sufficient funds and enough sprawling infrastructure that a team dedicated to upkeep is required; the SRE/Ops team. But, what about startups? Enabling rapid development, high reliability, and consistent infrastructure is just as vital to survival as it in in larger companies, if not more. Yes, there are startups who have already found market fit and need to rapidly scale - but what about the startups like us that are still looking for the right fit?
+
+Instead of dismissing DevOps/SRE as “not yet needed” we took a different approach: embracing DevOps principals and culture from day one. Our infrastructure is managed by terraform, our code is built and tested on every commit, and our master branch is synonymous with production.
+
+Over the course of this talk, I’ll describe why we adopted DevOps and why we place engineer efficiency as our highest priority, even higher than consistency and reliability. We’ll walk through our path from using manually-built artifacts and deployment, all the way to automated build pipelines and version management, and through to our goal of master-branch triggered deployments. We’ll share the lessons we learned from choosing carefully what to automate and when, and how we continue to deliver code faster and faster despite a constant team size. We’ll also share our vision on the future of DevOps and SRE in small and scaling companies: operationalizing production, Security, and IT functions together.

content/events/2019-boston/program/garland-kan.md

@@ -0,0 +1,14 @@
+---
+title: "Building Cost Visibility For Your Kubernetes Clusters"
+Type: "talk"
+Speakers: ["garland-kan"]
+
+---
+
+This talk addresses one of the most common challenges for organizations adopting Kubernetes at scale: understanding how you’re spending money in your k8s clusters. The inherent sharing nature of Kubernetes means that you have no visibility into how much stuff costs. Without this cost visibility, you can’t optimize your cluster utilization and cut costs, forecast budgets accurately, or understand your product margins in multi-tenancy situations.
+
+Cloud providers like AWS and GCP don’t tell you how you’re spending money at the application-level. Since each instance can be shared by multiple namespaces and pods in a k8s cluster, knowing how much an instance costs (cloud providers share this level of information) isn’t actionable. What you really need to know is how much each namespace or pod costs that was running on the same instance.
+
+Without a clear understanding of how much compute spend a team or customer is responsible for, you can’t accurately manage your budget, understand your cluster utilization, or calculate product margins.
+
+This session will walk the user through open source tools and techniques on how to solve this problem and accurately attribute costs in a Kubernetes cluster. And now that you know how to build cost visibility into your k8s cluster, we will do a quick overview on cost saving techniques.

content/events/2019-boston/program/ian-crosby.md

@@ -0,0 +1,11 @@
+---
+title: "A Monolith, a Microservices, and a Function Walk into a Bar"
+Type: "talk"
+Speakers: ["ian-crosby"]
+
+---
+With a variety of choices and a constantly changing landscape designing a lasting architecture is no easy task. Monolith style applications take a lot of criticism these days, but when starting a new project this is often the right choice. In the early stages we cannot anticipate the changes which will come, from a technical perspective or in terms of features and requirements. Microservices, serverless or the next latest trend may be turn out to be the solution we need, but this is rarely clear on day one. The most important aspect of any new architecture is that it lends itself to incremental change.
+
+In this talk, we will walk through evolving a non trivial monolithic application. We’ll cover how and why to split out functionality as microservices. From there we will continue with separating pieces into functions, and integrate them via the serverless paradigm. We’ll cover the platforms, patterns, and practices which make these migrations easier.
+
+Attendees will learn the benefits and drawbacks of each architecture style. As well as best practices for evolving your architecture (when, why, and how). The live demo will involve Docker, Kubernetes and KNative, while focusing on the general patterns rather than the specific technologies involved.