Mobycast

Support Mobycast
https://glow.fm/mobycast

In this episode, we cover the following topics:

• Amazon Elastic Container Service (ECS) basics
  • Orchestration system for containers
  • Well integrated with all the other Amazon services – More bang for your buck
  • ECS components
    • Cluster
      • Logical grouping of tasks or services
      • For EC2 launch type, set of EC2 instances that are defined and managed by:
        • Launch Configuration
        • Auto Scale Group
    • Service
      • Allows you to run and maintain a specified number of instances of a task definition simultaneously
      • For long-running applications
    • Task
      • Defines a collection of containers that you want to run together
      • Specifies resource quotas needed to run (e.g. memory, CPU, disk volumes)
  • Simple deployment with ECS
    • Build image, publish image, create task definition revision, update ECS service
• Running containers
  • Three methods
    • Create a long running task
      • ECS service, service scheduler, integration with ELB
    • Run a single task
    • Create a scheduled task
  • We are going to focus on the most typical use case - ECS services
    • You have to choose a launch type
      • EC2 or Fargate
• Fargate
  • Announced at re:Invent 2017
    • Generally available since 2018
  • What is it?
    • Allows you to run containers without having to manage servers or clusters of EC2s
      • Don't need to choose server types, decide when to scale your clusters, or optimize cluster packing
      • You get complete control over task placement within your own VPC
        • But underlying infrastructure is managed by Fargate
  • Benefits
    • No clusters to manage
    • Seamless scaling
    • Only pay for when you are running tasks
      • Ideal for batch jobs, cron jobs and other on-and-off workloads
      • Running cluster of instances constantly incurs costs, but Fargate stops billing when containers stop
  • Specifics
    • Each Fargate task has its own isolation boundary
      • It does not share the underlying kernel, CPU resources, memory resources, or ENI
        • Leverages Firecracker microVM
        • Increases efficiency (e.g. approximately 50% price cut for Fargate in January 2019 due to Firecracker)
    • Tasks must be launched into a cluster
      • Cluster is logical infrastructure and permissions boundary for isolating groups of tasks
      • Clusters support running both EC2 and Fargate launch types (mix-n-match)
    • Fargate tasks require awsvpc network mode
      • Provides each task with an ENI
        • You must specify one or more subnets
        • You must specify one or more security groups
      • Decide on whether to assign public IP address to ENI
        • If on public subnet, you must assign public IP to pull images
        • If on private subnet, just requires NAT gateway
    • You must specify CPU and memory at the task level
      • You can also optionally specify CPU and memory at container level
    • Only supports the following log drivers
      • awslogs
        • Sends log information to CloudWatch Logs
      • splunk
  • Pricing
    • Based on amount of CPU and memory used
    • Charged by the second, with minimum charge of 1 minute
    • Example costs for running a blog server 24x7
      • Note: costs for us-west-2 region
      • Fargate, 0.25 VCPU, 0.5GB memory
        • per vCPU per hour: $0.04048
        • per GB per hour: $0.004445
        • Memory = $1.60 (30 days * 24 hours * 0.5 GB * 0.004445)
        • CPU = $7.29 (30 days * 24 hours * 0.25VCPU * 0.04048)
        • Total = $8.89 / month
      • t2.micro, 1 VCPU, 1GB memory
        • per hour: $0.0116
        • Total = $8.35 (30 days * 24 hours * 0.0116)
      • t3.nano, 2 VCPU, 0.5GB memory
        • per hour: $0.0052
        • Total = $3.74 (30 days * 24 hours * 0.0052)

Links

• Amazon Elastic Container Service
• ECS Fargate
• AWS Fargate Price Reduction – Up to 50%

End Song
ERRE - Lamictal

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
• Reddit: https://reddit.com/r/mobycast
  
  

Support Mobycast
https://glow.fm/mobycast

In this episode, we cover the following topics:

• Container runtimes 
  • Responsible for: 
    • Setting up namespaces and cgroups for containers 
    • Running commands inside those namespaces and cgroups 
  • Types of runtimes 
    • Low-level 
      • Handles tasks related to containers such as: 
        • Creating a container 
        • Attaching a process to an existing container 
    • High-level 
      • Handles "high level" tasks such as: 
        • Image creation 
        • Image management 
      • Defers container tasks to "low level" runtime 
• Container standards 
  • Open Container Initiative (OCI) 
    • Established in June 2015 by Docker and others 
    • Contains two specifications: 
      • Runtime Specification (runtime-spec) 
        • runc is an implementation of OCI runtime-spec 
      • Image Specification (image-spec) 
• Runc 
  • Low-level container runtime 
  • CLI tool for spawning and running containers according to the OCI specification 
  • Container runtime originally developed as part of Docker 
    • Later lifted out as separate open source project 
• Containerd 
  • High-level container runtime 
  • Provides abstraction layer for the syscalls and OS-specific functionality required to run container 
    • Platforms can build on top of abstraction layer without having to drop down to kernel 
    • Much nicer to work with abstractions (Container, Task, Snapshot) than to manage calls to clone() and mount() 
  • Available as daemon for Linux and Windows 
  • Designed to be embedded into a larger system (like Docker) 
    • Used by container platforms like Docker and Kubernetes 
  • Under the hood, containerd uses runc 
  • Only deals with core container management 
    • Push/pull functionality 
    • Image management 
    • Container lifecycle APIs 
      • Create, execute and manage containers and their tasks 
    • Snapshot management 
  • Out of scope 
    • Networking 
      • Very complicated, much more platform specific than abstracting Linux calls 
      • Instead, containerd exposes events so consumers can subscribe to events they care about 
        • E.g. hook events to add interfaces to network namespace 
  • Exposes functionality via GRPC API 
    • Listens on Linux socket 
• Runtime platforms 
  • Docker 
    • Uses containerd, plus shim 
    • Shim allows for daemon-less containers 
      • e.g. You can upgrade Docker daemon without restarting containers 
  • rkt 
    • Application container engine, part of CoreOS (RedHat) 
    • rkt has no centralized "init" daemon 
      • Instead it launches containers directly from client commands 
    • Was part of CNCF, but archived in August 2019 
      • Reasons cited by CNCF: 
        • "end user adoption has severely declined" 
        • "project activity and the number of contributors has also steadily declined over time" 
      • containerd and CRI-O are now the CNCF container runtime projects 
  • CRI-O 
    • Implementation of the Kubernetes CRI (Container Runtime Interface) to enable using OCI runtimes 
    • Lightweight alternative to using Docker, Moby or rkt as the runtime for k8s 
    • Allows k8s to use any OCI-compliant runtime as the container runtime for running pods 
    • Supports runc and Kata Containers 
• Revisit pseudo code example of creating a container 
  • Steps: 
    • Create root filesystem for container 
      • Spin up busybox in Docker container, and then export filesystem 
    • Run "launcher" process that sets up "child" namespace 
    • Launcher process forks new child process (now under new namespaces) 
      • Child process then forks new process for container 
        • chroot (to our root filesystem) 
        • mount any other FS 
        • set cgroups (e.g. apply CPU constraints) 

Links

• Open Container Initiative - OCI
• runc
• containerd
• What is containerd?
• CoreOS rkt
• rkt vs Docker

End Song
Miquel Salla - All is Coming Back (Focalist Remix)

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast

Support Mobycast:
https://glow.fm/mobycast

In this episode, we cover the following topics:

• Operating-system-level virtualization = containers
  • Allows the resources of a computer to be partitioned via the kernel
    • All containers share single kernel with each other AND the host system
  • Depend on their host OS to do all the communication and interaction with the physical machine
    • Containers don't need a hypervisor; they run directly within the host machine's kernel
  • Containers are using the underlying operational system resources and drivers
    • This is why you cannot run different OSes on the same host system
      • i.e. Windows containers can run on Windows only, and Linux Containers can run on Linux only
    • What we think of different OSes (RHEL, CentOS, SUSE, Debian, Ubuntu) are not really different...
      • They are all same core OS (Linux), they just differ in apps/files
  • Based on the virtualization, isolation, and resource management mechanisms provided by the Linux kernel
    • namespaces
    • cgroups
• Container history
  • FreeBSD Jails (2000)
    • BSD userland software that runs on top of the chroot(2) system call
      • chroot is used to change the root directory of a set of processes
    • Processes created in the chrooted environment cannot access files or resources outside of it
    • Jails virtualize access to the file system, the set of users, and the networking subsystem
    • A jail is characterized by four elements:
      • Directory subtree: the starting point from which a jail is entered
        • Once inside the jail, a process is not permitted to escape outside of this subtree
      • Hostname
      • IP address
      • Command: the path name of an executable to run inside the jail
    • Configured via jail.conf file
  • LXC containers (2008)
    • Userspace interface for the Linux kernel features to contain processes, including:
      • Kernel namespaces (ipc, uts, mount, pid, network and user)
      • Apparmor and SELinux profiles
      • Seccomp policies
      • Chroots (using pivot_root)
      • Kernel capabilities
      • CGroups (control groups)
  • Docker containers (2014)
    • Early versions of Docker used LXC as the container runtime
    • LXC was made optional in v0.9 (March 2014)
      • Replaced by libcontainer)
      • libcontainer became the core of runC
    • LXC was dropped in v1.10 (February 2016)
• Container technology
  • Containers are just processes. So what makes them special?
  • Namespaces
    • Restrict what you can SEE
    • Virtualize system resources, like the file system or networking
      • Makes it appear to processes within the namespace that they have their own isolated instance of resource
      • Changes to the global resource only visible to processes that are members of the namespace
    • Processes inherit from parent
    • Linux provides the following namespaces:
      • IPC (interprocess communications)
        • CLONE_NEWIPC: Isolates System V IPC, POSIX message queues
      • Network
        • CLONE_NEWNET: Isolates network devices, stacks, ports, etc
      • Mount
        • CLONE_NEWNS: Isolates mount points
      • PID
        • CLONE_NEWPID: Isolates process IDs
      • User
        • CLONE_NEWUSER: Isolates user and group IDs
      • UTS (Unix Timesharing System)
        • CLONE_NEWUTS: Isolates hostname and NIS domain name
      • Cgroup
        • CLONE_NEWCGROUP: Isolates cgroup root directory
    • Syscall interface
      • System call is the fundamental interface between an app and the Linux kernel
        • i.e. Linux kernel calls to create/enter namespaces for processes
  • Control groups (cgroups)
    • Restrict what you can DO
    • Limits an application (container) to a specific set of resources like CPU and memory
    • Allow containers to share available hardware resources and optionally enforce limits and constraints
    • Creating, modifying, using cgroups is done through the cgroup virtual filesystem
    • Processes inherit from parent
    • Can be reassigned to different cgroups
      • Memory
      • CPU / CPU cores
      • Devices
      • I/O
      • Processes
    • Using cgroups
      • To see mounted cgroups:
        • mount | grep cgroup
      • To create a new cgroup:
        • mkdir /sys/fs/cgroup/cpu/chris
      • To set "cpu.shares" to 512:
        • echo 512 > /sys/fs/cgroup/cpu/chris/cpu.shares
      • Now add a process to this cgroup:
        • echo > /sys/fs/cgroup/cpu/chris/cgroup.procs
• Pseudo code: Creating a container
  • Steps:
    • Create root filesystem for container
      • Spin up busybox in Docker container, and then export filesystem
    • Run "launcher" process that sets up "child" namespace
    • Launcher process forks new child process (now under new namespaces)
      • Child process then forks new process for container
        • chroot (to our root filesystem)
        • mount any other FS
        • set cgroups (e.g. apply CPU constraints)

Links

• FreeBSD Jails
• Linux Container Project - LXC, LXD, LXCFS
• namespaces - overview of Linux namespaces
• cgroups kernel documentation
• What Have Namespaces Done For You Lately? - YouTube video
  
  

End Song
Bettie Black & Sophia - Something Beautiful

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
  
  

Sponsors

• Circle CI
• Episode on CI/CD with Circle CI

Show Details

In this episode, we cover the following topics:

• Hypervisor implementations 
  • Hyper-V 
    • Type 1 hypervisor from Microsoft 
    • Architecture 
      • Implements isolation of virtual machines in terms of a partition 
        • Partition is logical unit of isolation in which each guest OS executes 
      • Parent partition 
        • Virtualization software runs in parent partition and has direct access to hardware 
          • Requires supported version of Windows Server 
        • There must be at least one parent partition 
        • Parent partition creates child partitions which host the guest OSes 
          • Done via Hyper-V "hypercall" API 
        • Parent partitions run a Virtualization Service Provider (VSP) which connects to the VMBus 
          • Handles device access requests from child partition 
      • Child partition 
        • Does not have direct access to hardware 
          • Has virtual view of processor and runs in Guest Virtual Address (not necessarily the entire virtual address space) 
        • Hypervisor handles interrupts to processor, and redirects to respective partition 
        • Any request to the virtual devices is redirected via the VMBus to the devices in the parent partition 
      • VMBus 
        • Logical channel which enables inter-partition communication 
  • KVM (Kernel-based Virtual Machine) 
    • Virtualization module in Linux kernel 
      • Turns Linux kernel into hypervisor 
      • Available in mainline Linux since 2007 
    • Can run multiple VMs running unmodified Linux or Windows images 
    • Leverages hardware virtualization 
      • Via CPU virtualization extensions (Intel VT or AMD-V) 
    • But also provides paravirtualization support for Linux/FreeBSD/NetBSD/Windows using VirtIO API 
    • Architecture 
      • Kernel component 
        • Consists of: 
          • Loadable kernel module, kvm.ko, that provides the core virtualization infrastructure 
          • Processor specific module, kvm-intel.ko or kvm-amd.ko 
      • Userspace component 
        • QEMU (Quick Emulator) 
          • Userland program that does hardware emulation 
          • Used by KVM for I/O emulations 
• AWS hypervisor choices & history 
  • AWS uses custom hardware for faster EC2 VM performance 
  • Original EC2 technology ran highly customized version of Xen hypervisor 
    • VMs can run using either paravirtualization (PV) or hardware virtual machine (HVM) 
    • HVM guests are fully virtualized 
      • VMs on top of hypervisor are not aware they are sharing with other VMs 
    • Memory allocated to guest OSes is scrubbed by hypervisor when it is de-allocated 
    • Only AWS admins have access to hypervisors 
  • AWS found that Xen has many limitations that impede their growth 
    • Engineers improved performance by moving parts of software stack to purpose-built hardware components 
  • C3 instance family (2013) 
    • Debut of custom chips in Amazon EC2 
      • Custom network interface for faster bandwidth and throughput 
  • C4 instance family (2015) 
    • Offload network virtualization to custom hardware with ASIC optimized for storage services 
  • C5 instance family (2017) 
    • Project Nitro 
      • Traditional hypervisors do everything 
        • Protect the physical hardware and bios, virtualize the CPU, storage, networking, management tasks 
      • Nitro breaks apart those functions, offloading to dedicated hardware and software 
      • Replace Xen with a highly optimized KVM hypervisor tightly coupled with an ASIC 
      • Very fast VMs approaching performance of bare metal server 
  • Amazon EC2 – Bare metal instances (2017) 
    • Use Project Nitro 

Links

• Xen Project
• Kernel Virtual Machine
• QEMU
• Mastering KVM Virtualization
• Hyper-V
• AWS Nitro System
• AWS re:Invent 2018: Powering Next-Gen EC2 Instances: Deep Dive into the Nitro System
• AWS re:Invent 2017: C5 Instances and the Evolution of Amazon EC2 Virtualization

End Song
Fax - Stages

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast 

Sponsor

• Circle CI
• Episode on CI/CD with Circle CI

Show Details

In this episode, we cover the following topics:

• VMs vs containers - why revisit?
  • Originally talked about this in episode 1
    • Got most of it right, but some inconsistencies/holes
    • Let's revisit to fill in the gaps, and dive a whole LOT deeper this time around
• Types of virtualization
  • Full virtualization ("virtual machines")
    • Simulates enough hardware to allow an unmodified "guest" OS to be run in isolation
    • Resources of computer are partitioned via hypervisor
    • Examples:
      • VMWare, Parallels, VirtualBox, Hyper-V
  • Operating-system-level virtualization ("containers")
    • Resources of computer are partitioned via the kernel
      • "Guest" OSes share same running instance of OS as the host system
    • Based on the virtualization, isolation, and resource management mechanisms provided by the Linux kernel
      • namespaces and cgroups
    • Examples:
      • Docker, LXC, FreeBSD jails
• Hypervisors
  • Also known as a Virtual Machine Manager (VMM)
  • Creates and runs virtual machines
    • It is a process that separates OS and apps from underlying physical hardware
    • Multiple VMs share virtualized hardware resources
  • When you create a new VM, the following happens:
    • Hypervisor allocates memory and CPU space for VMs exclusive use
    • Complete OS is installed onto the VM
    • The VM's OS communicates with the hypervisor to perform tasks
  • Host OS is able to see all physical hardware, whereas guest OS (VM) can only see hardware to which hypervisor has granted access
  • Two types of hypervisors
    • Type 1 (also called "native" or "bare metal" hypervisors)
      • Run directly on the host’s hardware to control the hardware and manage the guest VMs
        • runs in ring 0
      • Are an OS themselves (simple OS on top of which you run VMs)
        • the physical machine the hypervisor is running on serves only for virtualization purposes
          • Exceptions: Hyper-V, KVM
      • Examples
        • Xen, Microsoft Hyper-V, VMware ESX/ESXi
    • Type 2 (also called "hosted" hypervisors)
      • Run on conventional OS, just like other apps
      • Guest OS runs as a process on the host
      • Hypervisor separates the guest OS from the host OS
      • Examples
        • VirtualBox, Parallels
  • Protection levels (rings)
    • x86 family of CPUs provide a range of protection levels also known as rings
      • Ring 0 has the highest level privilege (kernel/supervisor)
      • Ring 3 lowest level (applications)
    • Hypervisor occupies ring 0 of CPU
    • Kernels for any guest operating systems running on the system must run in less privileged CPU rings
      • But most OS kernels are written explicitly to run in ring 0
      • Techniques to deal with this:
        • Full virtualization
          • hypervisor provides CPU emulation to handle ring 0 operations made by unmodified guest OS kernels
          • emulation process requires both time and system resources
            • inferior performance
        • Paravirtualization
          • Technique in which hypervisor provides an API and the OS of the guest VM calls that API
          • Requires guest OS to be modified (to make API calls)
            • Replace any privileged operations that will only run in ring 0 of the CPU with calls to the hypervisor ("hypercalls")
          • Allows tasks to run in host OS (instead of in guest OS where performance would be worse)
        • Hardware virtualization
          • Requires a CPU with hardware virtualization extensions, such as Intel VT or AMD-V
            • Intel virtualization (VT-x)
              • Virtual Machine Extensions
              • Adds ten new instructions
                • VMPTRLD, VMPTRST, VMCLEAR, VMREAD, VMWRITE, VMCALL, VMLAUNCH, VMRESUME, VMXOFF, and VMXON.
                • These instructions permit entering and exiting a virtual execution mode where the guest OS perceives itself as running with full privilege (ring 0), but the host OS remains protected.
          • Reduces/eliminates any OS modifications in guest OS
          • Provides an additional privilege mode above ring 0 in which the hypervisor can operate
            • essentially leaving ring 0 available for unmodified guest OSes
          • Better performance than paravirtualization

Links

• Virtual machine
• Hypervisor
• What is a hypervisor?
• What Is A Hypervisor? Types Of Hypervisors 1 & 2
  
  

End Song
Time for Trees - Sad Livin in the (New York) City - (David Last Remix)

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
  
  

Sponsor

• Circle CI
• Episode on CI/CD with Circle CI

Show Details

In this episode, we cover the following topics:

• Pillars in depth
  • Performance Efficiency
    • "Ability to use resources efficiently to meet system requirements and maintain that efficiency as demand changes and technology evolves"
    • Design principles
      • Easy to try new advanced technologies (by letting AWS manage them, instead of standing them up yourself)
      • Go global in minutes
      • Use serverless architectures
      • Experiment more often
      • Mechanical sympathy (use the technology approach that aligns best to what you are trying to achieve)
    • Key service: CloudWatch
    • Focus areas
      • Selection
        • Services: EC2, EBS, RDS, DynamoDB, Auto Scaling, S3, VPC, Route53, DirectConnect
      • Review
        • Services: AWS Blog, AWS What's New
      • Monitoring
        • Services: CloudWatch, Lambda, Kinesis, SQS
      • Tradeoffs
        • Services: CloudFront, ElastiCache, Snowball, RDS (read replicas)
    • Best practices
      • Selection
        • Choose appropriate resource types
          • Compute, storage, database, networking
      • Trade Offs
        • Proximity and caching
  • Cost Optimization
    • "Ability to run systems to deliver business value at the lowest price point"
    • Design principles
      • Adopt a consumption model (only pay for what you use)
      • Measure overall efficiency
      • Stop spending money on data center operations
      • Analyze and attribute expenditures
      • Use managed services to reduce TCO
    • Key service: AWS Cost Explorer (with cost allocation tags)
    • Focus areas
      • Expenditure awareness
        • Services: Cost Explorer, AWS Budgets, CloudWatch, SNS
      • Cost-effective resources
        • Services: Reserved Instances, Spot Instances, Cost Explorer
      • Matching supply and demand
        • Services: Auto Scaling
      • Optimizing over time
        • Services: AWS Blog, AWS What's New, Trusted Advisor
    • Key points
      • Use Trusted Advisor to find ways to save $$$
• The Well-Architected Review
  • Centered around the question "Are you well architected?"
  • The Well-Architected review provides a consistent approach to review workload against current AWS best practices and gives advice on how to architect for the cloud
  • Benefits of the review
    • Build and deploy faster
    • Lower or mitigate risks
    • Make informed decisions
    • Learn AWS best practices
• The AWS Well-Architected Tool
  • Cloud-based service available from the AWS console
  • Provides consistent process for you to review and measure your architecture using the AWS Well-Architected Framework
  • Helps you:
    • Learn
    • Measure
    • Improve
  • Improvement plan
    • Based on identified high and medium risk topics
    • Canned list of suggested action items to address each risk topic
  • Milestones
    • Makes a read-only snapshot of completed questions and answers
  • Best practices
    • Save milestone after initially completing workload review
    • Then, whenever you make large changes to your workload architecture, perform a subsequent review and save as a new milestone

Links

• AWS Well-Architected
• AWS Well-Architected Framework - Online/HTML version
  • includes drill down pages for each review question, with recommended action items to address that issue
• AWS Well-Architected Tool
• Enhanced Networking
• Amazon EBS-optimized instance
• VPC Endpoint
• Amazon S3 Transfer Acceleration
• AWS Billing and Cost Management

Whitepapers

• AWS Well-Architected Framework
• Operational Excellence Pillar
• Security Pillar
• Reliability Pillar
• Performance-Efficiency Pillar
• Cost Optimization Pillar

End Song:
The Shadow Gallery by Roy England

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
• Reddit: https://reddit.com/r/mobycast
  
  

In this episode, we cover the following topics:

• Pillars in depth
  • Security
    • "Ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies"
    • Design principles
      • Implement strong identity foundation
      • Enable traceability
      • Security at all layers
      • Automate security best practices
      • Protect data in transit and at rest
      • Keep people away from data
      • Prepare for security events
    • Key service: AWS IAM
    • Focus areas
      • Identity and access management
        • Services: IAM, AWS Organizations, MFA
      • Detective controls
        • Services: CloudTrail, CloudWatch, AWS Config, GuardDuty
      • Infrastructure protection
        • Services: VPC, Shield, WAF
      • Data protection
        • Services: KMS, ELB (encryption), Macie (detect sensitive data)
      • Incident response
        • Services: IAM, CloudFormation
    • Best practices
      • Identity and access management
        • AWS Cognito
          • Act as broker between login providers
          • Securely access any AWS service from mobile device
      • Data protection
        • Encrypt
          • Encryption at rest
          • Encryption in transit
          • Encrypted backups
        • Versioning
        • Storage resiliency
        • Detailed logging
      • Incident response
        • Employ strategy of templated "clean rooms"
          • Create new trusted environment to conduct investigation
          • Use CloudFormation to easily create the "clean room" environment
  • Reliability
    • "Ability to recover from failures, dynamically acquire resources to meet demand and mitigate disruptions such as network issues"
    • Design principles
      • Test recovery procedures
      • Auto recover from failures
      • Scale horizontally to increase availability
      • Stop guessing capacity
      • Manage change with automation
    • Key service: CloudWatch
    • Focus areas
      • Foundations
        • Services: IAM, VPC, Trusted Advisor (visibility into service limits), Shield (protect from DDoS)
      • Change management
        • Services: CloudTrail, AWS Config, CloudWatch, Auto Scaling
      • Failure management
        • Services: CloudFormation, S3, Glacier, KMS
    • Best practices
      • Foundations
        • Take into account physical and service limits
        • High availability
          • No single points of failure (SPOF)
          • Multi-AZ design
          • Load balancing
          • Auto scaling
          • Redundant connectivity
          • Software resilience
      • Failure management
        • Backup and disaster recovery
          • RPO, RTO
        • Inject failures to test resiliency
    • Key points
      • Plan network topology
      • Manage your AWS service and rate limits
      • Monitor your system
      • Automate responses to demand
      • Backup
• In the next episode, we'll cover the remaining 2 pillars and discuss how to perform a Well-Architected Review.

Links

• AWS Well-Architected
• AWS Well-Architected Framework - Online/HTML version
  • includes drill down pages for each review question, with recommended action items to address that issue
• AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures - ARC338
• Shuffle Sharding: Massive and Magical Fault Isolation
  
  

Whitepapers

• AWS Well-Architected Framework
• Operational Excellence Pillar
• Security Pillar
• Reliability Pillar
• Performance-Efficiency Pillar
• Cost Optimization Pillar

End song:
The Runner (David Last Remix) - Fax

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
  
  

In this episode, we cover the following topics:

• AWS Well-Architected Framework
  • Provides consistent approach to evaluating systems against cloud best practices
  • Helps advise changes necessary to make specific architecture align with best practices
  • Comprised of 3 components:
    • Design Principles
    • Pillars
      • Operational Excellence
      • Security
      • Reliability
      • Performance Efficiency
      • Cost Optimization
    • Questions
• General design principles
  • Cloud-native has changed everything. In cloud, you can:
    • Stop guessing capacity needs
    • Test at scale
    • Automate all the things to make experimentation easier
    • Allow for evolutionary architectures (you are never stuck with a particular technology)
    • Drive architectures using data (allows you to make fact based decisions on how to improve your workload)
    • Improve through game days
• Pillars in depth
  • Operational Excellence
    • "Ability to run and monitor systems to deliver business value and to continuously improve supporting processes and procedures"
    • Design principles
      • Perform operations as code
      • Annotate documentation
      • Make frequent, small, reversible changes
      • Refine operations procedures frequently
      • Anticipate failure
      • Learn from all operational failures
    • Key service: CloudFormation
    • Focus areas
      • Prepare
        • Services: AWS Config, AWS Config Rules
      • Operate
        • Services: CloudWatch, X-Ray, CloudTrail, VPC Flow Logs
      • Evolve
        • Services: Elasticsearch (for searching log data to gain insights), CloudWatch Insights
    • Best practices
      • Prepare
        • Implement telemetry for:
          • Application
          • Workload
          • User activity
          • Dependencies
        • Implement transaction traceability
      • Operate
        • Any event for which you raise an alert should have associated runbook
          • Runbook defines triggers for escalations
        • Users should be notified when system is impacted
        • Communicate status through dashboards
          • Provide dashboards to communicate the current operating status of the business and provide metrics of interest
      • Evolve
        • Feedback loops
          • Identify areas for improvement
          • Gauge impact of changes to the system (i.e. did it make an improvement?)
          • Perform operations metrics reviews
            • Retrospective analysis of operations metrics
              • Use these reviews to identify opportunities for improvement, potential courses of action, and share lessons learned
    • Key points
      • Runbooks, playbooks
      • Document environments
      • Make small changes through automation
      • Monitor workload with business metrics
      • Exercise your response to failures
      • Have well-defined escalation management
• In future episodes, we'll cover the remaining 4 pillars

Links

• AWS Well-Architected Framework - Online/HTML version
  • includes drill down pages for each review question, with recommended action items to address that issue
• Are You Well-Architected?
• AWS re:Invent 2016 Keynote: Werner Vogels
  • See: 25:45 through 31:25
• Runbooks
• Playbooks
• AWS Service Health Dashboard
• AWS Personal Health Dashboard
  
  

Whitepapers

• AWS Well-Architected Framework
• Operational Excellence Pillar
• Security Pillar
• Reliability Pillar
• Performance-Efficiency Pillar
• Cost Optimization Pillar

End Song:
30 Days & 30 Nights by Fortune Finder

For a full transcription of this episode, please visit the episode webpage.

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
• Reddit: https://reddit.com/r/mobycast

• The Twelve-Factor App methodology 
  • Drafted by developers at Heroku based upon their observations of what made good apps 
  • First presented by Adam Wiggins circa 2011 (then published in 2012) 
• The Factors 
  • 1 - Codebase: one codebase tracked in revision control, many deploys 
  • 2 - Dependencies: explicitly declare and isolate dependencies 
  • 3 - Config: strict separation of config from code 
  • 4 - Backing services: foster loose coupling by treating backing services as attached resources 
  • 5 - Build, release, run: strictly separate build and run stages 
  • 6 - Processes: processes are stateless and share-nothing 
  • 7 - Port binding: export services via port binding 
  • 8 - Concurrency: scale out via the process model 
  • 9 - Disposability: processes are disposable, they can be started or stopped at a moment’s notice 
  • 10 - Dev/prod parity: Keep development, staging, and production as similar as possible 
  • 11 - Logs: treat logs as event streams, don't manage log files 
  • 12 - Admin processes: admin and utility code ships with app code to avoid synchronization issues 
• What's Missing? 
  • 7 years since first being published, what changes should be made to make it more relevant for today? 
    • Some have argued for adding 3 additional factors: 
      • Telemetry 
      • Security 
      • "API First"-philosophy 

For a full transcription of this episode, please visit the episode webpage.

End song:
Flowerchild (Roy England Remix) by Owen Ni - Make Mistakes

We'd love to hear from you! You can reach us at:

• Web: https://mobycast.fm
• Voicemail: 844-818-0993
• Email: [email protected]
• Twitter: https://twitter.com/hashtag/mobycast
• Reddit: https://reddit.com/r/mobycast

In Episode 76 of Mobycast, Jon and Chris finish our series on encryption by digging into AWS’ encryption services. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.