0. Introduction

Introduction

At Stelligent, we implement cloud delivery solutions for customers in Amazon Web Services – commonly referred to as just ‘AWS’. A common objective with our customers is to significantly reduce the time it takes to release their software systems. Essentially, make it possible so that their software is always releasable. The purpose of this course is to show you exactly what we do – to the extent that this is possible in a video course with very dynamic information. My hope is that you can use this material to implement Cloud Delivery in AWS solutions for your own companies. I won’t be able to cover every technology combination or the challenge that a large part of efforts like these involve working with people across teams, responsibilities and skill levels – and people, let’s just say, are indeterministic. While much of the technology will be focused on a Ruby on Rails application running on Linux on AWS, I’ll also be covering open-source cloud delivery implementations that Stelligent has constructed for open-source applications written in Java, Node and soon, .NET. You can apply many of the principles, practices and even the code for other development platforms as well.

About the website

All this content is posted to devopsaws.stelligent.com. If you are watching the video, you’ll need to register at stelligent.com to get a userid to access the rest of this content.

You can navigate the content by scrolling through the table of contents on the right panel at any time. You can also access a map of not only the production line you’ll be creating throughout the course, but also the supporting work that’s necessary to create a complete software system – including the infrastructure.

While the core of this course will stay intact, we will be continually adding and updating content and adding/updating to the reference implementations we’ve implemented. All of the reference implementations will be open source.

Continuous Delivery

“Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” (http://martinfowler.com/bliki/ContinuousDelivery.html) Continuous Delivery has the following characteristics:

  • Holistic Software – Infrastructure, Application Code, Configuration and Data are fully scripted, tested, versioned and continuously run.
  • Holistic Teams – Cross-functional teams consisting of all roles make up a software delivery team.
  • Self-Service Resources – This is a key attribute of Continuous Delivery. All team members should have self-service access to resources they require without needing to request it through emails, phone calls, etc. All access can be continually monitored and governed through automation and review.

Continuous Delivery Benefits

  • Always Releasable Software – Because there are often many release candidates per day, software – based on recent contributions – is always ready to release to users.
  • Reduce Cycle Time – Time between an idea and software in use by users. Reduce wait times and organizational silos.
  • Feedback – Increasing the frequency of useful feedback to people who can fix the problems. Reducing the overhead organizational layers between a failure and someone who can fix issue. Increasing experimentation. By increasing and amplifying feedback loops, you can further reduce MTTD and MTTR.

Key Patterns

Below is a list of the core patterns that I’ll focus on in this course. For more information on CD patterns, see Continuous Delivery Patterns and Antipatterns in the Software Lifecycle (DZone, 2011).

Scripted Infrastructure – “By fully automating environment provisioning, you reduce the risks of deployment errors occurring in one environment that do not occur in other environments. By scripting environments, you verify the integrity of a particular version of the software (that is, that nothing has been modified) in target environments. By following the policy that nothing gets modified to an environment unless it’s in a versioned script, automated, and part of a single path to production, you can better determine the root cause of deployment errors. The benefits of scripted environments include:

  • Environments are always in a known state.
  • They enable self-service environments and deployments.
  • They lessen the chance that deployments behave differently based on unique environment types.
  • Environments are a part of a single path (and version) to production.
  • They lessen the chance that knowledge is locked in team members’ heads.
  • Deployments are more predictable and repeatable.”

(IBM developerWorks, “Agile DevOps: The flattening of the software release process“, Duvall, 2012)

Test-Driven Infrastructures – “A simple premise of DevOps is the application of the best practices and patterns from development to operations and from operations to development. The test-driven approach of writing tests along with the code has its origins in software development. As infrastructure automation tools become more mainstream across organizations, engineers are applying test-driven practices to their infrastructure; the infrastructure is described in a script (as you saw in Listing 1), and these scripts have tests. Some of the many benefits of test-driven infrastructures are:

  • Problems manifest earlier because infrastructure changes are integrated with the rest of the software system through a Continuous Integration system.
  • The tests — and the scripted infrastructure — become documentation.
  • You can better isolate destructive changes, because everything is a script and described in tests.”

(IBM developerWorks, “Agile DevOps: The flattening of the software release process“, Duvall, 2012)

  • Version Everything – “Version everything. Yes, everything: infrastructure, configuration, application code, and your database. If you do, you have a single source of truth that enables you to view the software system — and everything it takes to create the software — as a holistic unit.” (IBM developerWorks, “Agile DevOps: Version everything“, Duvall, 2012)
  • Single Path to Production – “Configuration management of the entire system – source, configuration, environment and data. Any change can be tied back to a single revision in the version-control system”. All changes are part of a single delivery pipeline of changes on their way to production. (DZone, “Continuous Delivery Patterns and Antipatterns in the Software Lifecycle“, Duvall, 2011)

DevOps

“A movement that was born of the need to improve IT service delivery agility and found initial traction within many large public cloud services providers. Underpinning DevOps is the philosophy found in the Agile Manifesto, which emphasizes people (and culture) and seeks to improve collaboration between operations and development teams. DevOps implementers also attempt to better utilize technology—especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.” (http://www.gartner.com/it-glossary/devops/)

  • Synthesis across the software systems lifecycle: process, teams and systems
  • Considers all parts of the software system: app code/configuration/infrastructure/data
  • Considers all people that contribute to software systems: users, analysts, app developers, testers, DBAs, sys ops, security, release engineering, etc.
  • Avoids the “not my job syndrome”: you’re only “done” when software system is in production
  • In many ways, Continuous Delivery done well implies embracing the DevOps mindset
    • Technically speaking, you can embrace “DevOps” without doing Continuous Delivery, but our approach at Stelligent is to work with customers who want to have “always releasable software” in AWS, so Continuous Delivery becomes the means to the end
    • You can also institute Continuous Delivery without fully embracing DevOps, but the change to the organization will likely be short lived, this is because DevOps is often a change in mindset and a change in team and organizational culture
  • CALMS
    • Culture
    • Automation
    • Lean
    • Measurement
    • Sharing

AWS

Here are some of the key benefits in using AWS.

  • Low Cost – You only pay for what you use. When you’re done with it, you terminate it and you’re no longer charged for it. When utilized effectively, you can significantly reduce compute expenses. When cloud computing is coupled with extreme automation, organizations realize tremendous significant cost savings.
  • Agility and Instant Elasticity – In reality, this is the key benefit of AWS and the cloud, in general. When the cost of experimentation is low (because the infrastructure can be rapidly scaled out and scaled in programmatically based on demand), you have more options and can rapidly produce benefits for your users.
  • Open and Flexible – All compute resources are available through an API. Many cloud providers – including AWS – provide SDK, command line and DSL access as well. Since all resources are programmatically accessible, your entire infrastructure can be automated.
  • Secure – AWS is a secure, durable technology platform with industry-recognized certifications and audits: PCI DSS Level 1, ISO 27001, FISMA Moderate, HIPAA, and SAS 70 Type II. AWS services and data centers have multiple layers of operational and physical security to ensure the integrity and safety of your data (Source: https://aws.amazon.com/about-aws/)

For more, see https://aws.amazon.com/about-aws/

Further Reading

Below, you see a set of checklists of the high-level steps in creating a deployment pipeline for continuous delivery. Each of the steps will be described in more detail in later lessons.

Setup Checklist

[frontend-checklist name=”Setup”]

Developer Practices Checklist

[frontend-checklist name=”DevPractices”]

Process and Documentation Checklist

[frontend-checklist name=”Processes”]

Deployment Production Line Bootstrapping Checklist

[frontend-checklist name=”ProductionLine”]

Commit stage checklist

[frontend-checklist name=”Commit”]

Acceptance stage checklist

[frontend-checklist name=”Acceptance”]

Capacity stage checklist

[frontend-checklist name=”Capacity”]

Pre-production stage checklist

[frontend-checklist name=”Pre-Production”]

Production stage checklist

[frontend-checklist name=”Production”]

Self-service deployment checklist

[frontend-checklist name=”Self-Service”]

Crosscutting concerns checklist

[frontend-checklist name=”Crosscutting”]

Ongoing activities checklist

[frontend-checklist name=”Ongoing”]

Production operations checklist

[frontend-checklist name=”ProductionOperations”]

Course Overview

This course has 13 lessons based on the order in which we typically implement these solutions for customers.

The 1st lesson covers all the kickoff and project setup activities including the basic AWS and team setups.

In the 2nd lesson, I cover the process we go through if a project is currently in development and/or production. In the Processes and Documentation lesson, you’ll learn the steps we typically go through to determine our stakeholder’s process for delivering software to users – or, the overall value-stream.

In the 3rd lesson, you’ll learn how to fully code the stages and steps in the initial structure of the deployment production line using a continuous integration server. You’ll also learn how to code the configuration of your AWS Virtual Private Cloud – or VPC – using AWS’ CloudFormation infrastructure automation tool.

In the 4th lesson, you’ll start delivering something of value to your stakeholders. You’ll be implementing the commit stage of the deployment production line in which team members get quick feedback on the changes they just committed to the version-control repository.

In the 5th lesson, you’ll learn how to implement the steps in the acceptance stage of the deployment production line. You’ll see examples of creating a network using VPC, creating environments, writing infrastructure tests and running longer-running tests

In the 6th lesson, you’ll learn how to implement the steps in the capacity stage of the deployment production line. You’ll see examples of running load & performance tests, chaos and other stress tests

In the 7th lesson, you’ll learn how to implement the steps in the exploratory stage of the deployment production line. You’ll see examples of running a self-service deployment and providing a mechanism for approving/rejecting the production candidate

In the 8th lesson, you’ll learn how to implement the steps in the pre-production stage of the deployment production line. You’ll see examples of creating the production database, applying database updates and running a blue-green deployment to switch between production and pre-production environments

In the 9th lesson, you’ll learn how to implement the few steps necessary to run the production stage.

In the 10th lesson, you’ll learn how to implement a self-service deployment using artifacts created in other stages and how to configure your CI server to send notifications to users of the self-service deployment

In the 11th lesson, you’ll learn how to implement various cross-cutting concerns that don’t go into a specific stage. This includes application, system and cost monitoring, encryption, architecture diagrams and identity and access management

In the 12th lesson, you’ll learn the ongoing tasks that occur regularly to include project management activities, daily checkpoints, knowledge sharing, screencasts, documentation, metrics and tests

In the 13th and final lesson, you’ll learn the various activities for running production operations. This includes how to use monitoring tools, running through operations and security checklists and an overall deployment production line checklist.

Resources

Reference Implementations

At Stelligent, we’ve developed several reference implementations which provide detailed examples of how to establish a cloud delivery infrastructure for various development platforms and AWS infrastructure implementations.

Rails/Linux – Honolulu Answers

Java/Linux – A Media Manager

MEAN stack (MongoDB, Express, Angular, Node)