Mobycast Transistor (https://transistor.fm) https://feeds.transistor.fm/mobycast A Podcast About Cloud Native Software Development, AWS, and Distributed Systems © 2020 Kelsus, Inc 6b9a5bfb-8944-5cf9-b64b-59d3ab128fef no Learn cloud native software development by podcast en-us Wed, 23 Jul 2025 14:35:59 +0000 Tue, 02 Dec 2025 20:28:10 +0000 https://mobycast.fm https://img.transistor.fm/Z_gt6R_io2WrspA_0HRg0_WR4u2-Vy_ZQfdA-I5suBk/rs:fill:0:0:1/w:1400/h:1400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9zaG93/LzQyMDcvMTU2ODA0/MzY1My1hcnR3b3Jr/LmpwZw.jpg Mobycast https://mobycast.fm episodic Mobycast.fm A Podcast About Cloud Native Software Development, AWS, and Distributed Systems A Podcast About Cloud Native Software Development, AWS, and Distributed Systems. aws, cloud, software, development, programming Jon Christensen No No Hands On AWS - Massively Scalable Image Hosting Using S3 and CloudFront - Part 2 110 110 Hands On AWS - Massively Scalable Image Hosting Using S3 and CloudFront - Part 2 full 66cfb193-5360-44ab-81e1-354617dc1c9a https://share.transistor.fm/s/d0a3c3f5 In this episode, we cover the following topics:

  • We discuss the features and limitations of serving files directly from S3.
  • We then talk about how CloudFront can address many of S3's limitations. In particular, CloudFront is performant, inexpensive and allows us to use custom CNAMEs with TLS encryption.
  • How to create a secure CloudFront distribution for files hosted in S3.
  • What is OAI (Origin Access Identity), why we need it and how to set it up.
  • We show how you can configure your CloudFront distribution to use TLS and redirect HTTP to HTTPS.
  • We finish up by discussing "byte-range requests" and how to enable them for our image hosting solution.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

End Song

Beauty in Rhythm by Roy England

More Info

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

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

]]> In this episode, we cover the following topics:

  • We discuss the features and limitations of serving files directly from S3.
  • We then talk about how CloudFront can address many of S3's limitations. In particular, CloudFront is performant, inexpensive and allows us to use custom CNAMEs with TLS encryption.
  • How to create a secure CloudFront distribution for files hosted in S3.
  • What is OAI (Origin Access Identity), why we need it and how to set it up.
  • We show how you can configure your CloudFront distribution to use TLS and redirect HTTP to HTTPS.
  • We finish up by discussing "byte-range requests" and how to enable them for our image hosting solution.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

End Song

Beauty in Rhythm by Roy England

More Info

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

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

]]> Wed, 08 Jul 2020 12:00:00 +0000 Mobycast.fm Mobycast.fm 2473 In episode #109 of Mobycast, we started our discussion on how to build a massively scalable image hosting service. We talked about the general architecture and then dove deep on how to handle image uploads. But uploading is only half the solution. We also need to allow downloads of the images. Turns out, downloading is a totally different game. In this episode of Mobycast, Jon and Chris finish their two-part series on building an image hosting solution. We discuss in detail how to enable downloads of files with the help of CloudFront, a global network of edge locations that makes it easy to achieve massive scale. In episode #109 of Mobycast, we started our discussion on how to build a massively scalable image hosting service. We talked about the general architecture and then dove deep on how to handle image uploads. But uploading is only half the solution. We AWS, Amazon Web Services, Amazon S3, CloudFront, CDN, image hosting, image upload, massively scalable No Hands On AWS - Massively Scalable Image Hosting Using S3 and CloudFront - Part 1 109 109 Hands On AWS - Massively Scalable Image Hosting Using S3 and CloudFront - Part 1 full 27bb47db-ee77-43ce-9f80-8333eb7d9553 https://share.transistor.fm/s/d518f15c In this episode, we cover the following topics:

  • A common feature for web apps is image upload. And we all know the "best practices" for how to build this feature. But getting it right can be tricky.
  • We start off by discussing the problem space, and what we want to solve. A key goal is to have a solution that is massively scalable while being cost-effective.
  • We outline the general architecture of the solution, with separate techniques for handling image uploading and downloading.
  • We then dive deep into how to handle image uploading, highlighting various techniques for controlling access over who can perform uploads.
  • Two common techniques for securing uploads when using AWS are presigned URLs and presigned POSTs. We discuss how each works and when to use one over the other.
  • We finish up by putting everything together and detailing the steps involved with uploading an image.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Lazy Sunday by Roy England

More Info

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

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

]]> In this episode, we cover the following topics:

  • A common feature for web apps is image upload. And we all know the "best practices" for how to build this feature. But getting it right can be tricky.
  • We start off by discussing the problem space, and what we want to solve. A key goal is to have a solution that is massively scalable while being cost-effective.
  • We outline the general architecture of the solution, with separate techniques for handling image uploading and downloading.
  • We then dive deep into how to handle image uploading, highlighting various techniques for controlling access over who can perform uploads.
  • Two common techniques for securing uploads when using AWS are presigned URLs and presigned POSTs. We discuss how each works and when to use one over the other.
  • We finish up by putting everything together and detailing the steps involved with uploading an image.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Lazy Sunday by Roy England

More Info

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

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

]]> Wed, 01 Jul 2020 08:00:00 +0000 Mobycast.fm Mobycast.fm 2605 If you are building software apps, at some point you will likely need to build an image hosting service (let's be honest, probably more than once!). Image hosting is a core feature of many apps, and it's important to get right. We all know the best practices for building image hosting in the cloud. Start with Amazon S3 for the uploads. Then serve them up with a CDN like CloudFront. Easy, right? Well, as usual, the devil's in the details. In this episode of Mobycast, Jon and Chris kick off a two-part series detailing how to build a massively scalable image hosting service. We share hard-won tips and tricks so you can avoid common pitfalls when building your own solution. If you are building software apps, at some point you will likely need to build an image hosting service (let's be honest, probably more than once!). Image hosting is a core feature of many apps, and it's important to get right. We all know the best pra AWS, Amazon Web Services, Amazon S3, CloudFront, CDN, image hosting, image upload, massively scalable No Replay of Ep 43 - The Birth of NoSQL and DynamoDb – Part 5 108 108 Replay of Ep 43 - The Birth of NoSQL and DynamoDb – Part 5 full de6848bb-1197-4440-aa9e-95b3241e12df https://share.transistor.fm/s/b1d2fd4d Show Details

Jon Christensen and Chris Hickman of Kelsus and Rich Staats of Secret Stache conclude their series on the birth of NoSQL and DynamoDB. They compare the NoSQL database, Leviathan, created by Chris’s startup in the late 1990s to today’s DynamoDB. A lot of things haven’t changed, even though technology has evolved. It’s cyclical. There are patterns and problems that continue to dominate.

  

Some of the highlights of the show include:

  • Reason for Creation of NoSQL Database: How to scale database with Internet-scale applications to have a virtual pool of infinite storage that can be scaled out
  • Main Architecture Components of Leviathan:
    • API client
    • Update distributor (UD)
    • Base server (storage node)
    • Shepherd (housekeeping management system)  
  • Additional core components included smart IP and storage abstraction layer (SAL)
  • Leviathan mostly used C code and minimal Java code to support users
  • Big difference between DynamoDB and Leviathan is request router and partition metadata system living on the server vs. living on the edge
  • Leviathan was a closed system with an instance for every network or data center; not designed to run as a software as a service, like DynamoDB
  • Leviathan was strongly consistent, unlike DynamoDB’s eventually consistent model
  • Definition and Different Types of Transactions
  • Shepherd was used to identify and address consistency, synchronous, and timing issues 
  • Rather than using a file system, Leviathan used relational databases 

Links and Resources

DynamoDB

Microsoft SQL

Oracle DB

AWS IoT Greengrass

Kelsus

Secret Stache Media

 

Quotes:

“We had the same kind of problems that DynamoDB had - how do you scale your database dealing with Internet-scale applications and have this virtual pool of infinite storage that can be scaled out.” Chris Hickman

 

“This system and this technology went through many iterations.” Chris Hickman

 

“You can’t have a 100% consistent state across everything. It’s just impossible. How do you do the right thing?” Chris Hickman

 

“The big difference between DynamoDB and Leviathan...is the request router and partition metadata system living on the server vs. living out at the edge.” Jon Christen 

]]> Show Details

Jon Christensen and Chris Hickman of Kelsus and Rich Staats of Secret Stache conclude their series on the birth of NoSQL and DynamoDB. They compare the NoSQL database, Leviathan, created by Chris’s startup in the late 1990s to today’s DynamoDB. A lot of things haven’t changed, even though technology has evolved. It’s cyclical. There are patterns and problems that continue to dominate.

  

Some of the highlights of the show include:

  • Reason for Creation of NoSQL Database: How to scale database with Internet-scale applications to have a virtual pool of infinite storage that can be scaled out
  • Main Architecture Components of Leviathan:
    • API client
    • Update distributor (UD)
    • Base server (storage node)
    • Shepherd (housekeeping management system)  
  • Additional core components included smart IP and storage abstraction layer (SAL)
  • Leviathan mostly used C code and minimal Java code to support users
  • Big difference between DynamoDB and Leviathan is request router and partition metadata system living on the server vs. living on the edge
  • Leviathan was a closed system with an instance for every network or data center; not designed to run as a software as a service, like DynamoDB
  • Leviathan was strongly consistent, unlike DynamoDB’s eventually consistent model
  • Definition and Different Types of Transactions
  • Shepherd was used to identify and address consistency, synchronous, and timing issues 
  • Rather than using a file system, Leviathan used relational databases 

Links and Resources

DynamoDB

Microsoft SQL

Oracle DB

AWS IoT Greengrass

Kelsus

Secret Stache Media

 

Quotes:

“We had the same kind of problems that DynamoDB had - how do you scale your database dealing with Internet-scale applications and have this virtual pool of infinite storage that can be scaled out.” Chris Hickman

 

“This system and this technology went through many iterations.” Chris Hickman

 

“You can’t have a 100% consistent state across everything. It’s just impossible. How do you do the right thing?” Chris Hickman

 

“The big difference between DynamoDB and Leviathan...is the request router and partition metadata system living on the server vs. living out at the edge.” Jon Christen 

]]> Wed, 15 Apr 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2562 This is the fifth and final episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. In this episode, we compare Viathan’s pre-cloud architecture to that of DynamoDB. They’re less different than you might expect! This is the fifth and final episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. In this episode, we compare Viathan’s pr aws, cloud, software, development, programming No Replay of Ep 42 - The Birth of NoSQL and DynamoDb – Part 4 107 107 Replay of Ep 42 - The Birth of NoSQL and DynamoDb – Part 4 full beb79d85-fa92-4396-913d-448711d6afa2 https://share.transistor.fm/s/4aa50225 Show Details

What’s under the hood of Amazon’s DynamoDB? Jon Christensen and Chris Hickman of Kelsus continue their discussion on DynamoDB, specifically about it’s architecture and components. They utilize a presentation from re:Invent titled, Amazon DynamoDB Under the Hood: How we built a hyper-scale database.

  

Some of the highlights of the show include:

  • Partition keys and global secondary indexes determine how data is partitioned across a storage node; allows you to scale out, instead of up
  • Understand how a database is built to make architecture/component definitions less abstract
  • DynamoDB has four components:

          1.   Request Router: Frontline service that receives and handles requests
          2.   Storage Node: Services responsible for persisting and retrieving data
          3.   Partition Metadata System: Keeps track of where data is located
          4.   Auto Admin: Handles housekeeping aspects to manage system

  • What level of uptime availability do you want to guarantee?
  • Replication: Strongly Consistent vs. Eventually Consistent
  • Walkthrough of Workflow: What happens when, what does it mean when…
  • DynamoDB architecture and components are designed to improve speed and scalability
  • Split Partitions: Longer times that your database is up and the more data you put into it, the more likely you’re going to get a hot partition or partitions that are too big 

Links and Resources

DynamoDB

re:Invent

Amazon DynamoDB Under the Hood: How we built a hyper-scale database

Paxos Algorithm

Amazon S3

Amazon Relational Database Service (RDS)

MongoDB

JSON

Kelsus

Secret Stache Media


Quotes:

“Keep in mind that data is partitioned across storage node, and that’s a key feature of being able to scale out, as opposed to scaling up.” Jon Christensen


“Amazon was opening up the kimono...how DynamoDB has been architected and constructed and how it works.” Chris Hickman


“Managed Service - they get to decide how it’s architected...because they also have to keep it up and live up to their SLA.” Chris Hickman


“The longer the time that your database is up and the more data you put into it, the more likely that you’re going to get a hot partition or partitions are just going to get too big.” Chris Hickman

]]> Show Details

What’s under the hood of Amazon’s DynamoDB? Jon Christensen and Chris Hickman of Kelsus continue their discussion on DynamoDB, specifically about it’s architecture and components. They utilize a presentation from re:Invent titled, Amazon DynamoDB Under the Hood: How we built a hyper-scale database.

  

Some of the highlights of the show include:

  • Partition keys and global secondary indexes determine how data is partitioned across a storage node; allows you to scale out, instead of up
  • Understand how a database is built to make architecture/component definitions less abstract
  • DynamoDB has four components:

          1.   Request Router: Frontline service that receives and handles requests
          2.   Storage Node: Services responsible for persisting and retrieving data
          3.   Partition Metadata System: Keeps track of where data is located
          4.   Auto Admin: Handles housekeeping aspects to manage system

  • What level of uptime availability do you want to guarantee?
  • Replication: Strongly Consistent vs. Eventually Consistent
  • Walkthrough of Workflow: What happens when, what does it mean when…
  • DynamoDB architecture and components are designed to improve speed and scalability
  • Split Partitions: Longer times that your database is up and the more data you put into it, the more likely you’re going to get a hot partition or partitions that are too big 

Links and Resources

DynamoDB

re:Invent

Amazon DynamoDB Under the Hood: How we built a hyper-scale database

Paxos Algorithm

Amazon S3

Amazon Relational Database Service (RDS)

MongoDB

JSON

Kelsus

Secret Stache Media


Quotes:

“Keep in mind that data is partitioned across storage node, and that’s a key feature of being able to scale out, as opposed to scaling up.” Jon Christensen


“Amazon was opening up the kimono...how DynamoDB has been architected and constructed and how it works.” Chris Hickman


“Managed Service - they get to decide how it’s architected...because they also have to keep it up and live up to their SLA.” Chris Hickman


“The longer the time that your database is up and the more data you put into it, the more likely that you’re going to get a hot partition or partitions are just going to get too big.” Chris Hickman

]]> Wed, 08 Apr 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2465 Welcome to Mobycast! This is the fourth episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. In this episode we finish our deep dive into the technical details of how AWS’s Dynamo DB works. If you’re just joining us at Mobycast, thanks for sticking with us through this five part series. By the end, you’ll be ready to join us on any of our other technical deep dives. Welcome to Mobycast! This is the fourth episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. In this episode we finish ou aws, cloud, software, development, programming No Replay of Ep 41 - The Birth of NoSQL and DynamoDb – Part 3 106 106 Replay of Ep 41 - The Birth of NoSQL and DynamoDb – Part 3 full e29f7daf-4afc-4920-931c-a3bb155977b2 https://share.transistor.fm/s/d880cb26 Show Details

Jon Christensen and Chris Hickman of Kelsus and Rich Staats of Secret Stache continue their discussion on the birth of NoSQL and DynamoDB. They examine DynamoDB’s architecture and popularity as a solution for Internet-scale databases. 


Some of the highlights of the show include:

  • Challenges, evolution, and reasons associated with Internet-scale data
  • DynamoDB has been around a long time, but people are finally using it
  • DynamoDB and MongoDB are document or key value stores that offer scalability and event-driven programming to reduce complexity
  • Techniques for keeping NoSQL database’s replicated data in sync
  • Importance of indexes to understand query patterns
  • DynamoDB’s Table Concept: Collection of documents/key value items; must have partition key to uniquely identify items in table and determine data distribution
  • Sort keys create indexes (i.e. global/local secondary index) to support items within partitioning 
  • Query a DynamoDB database based on what’s being stored and using keys; conduct analysis on queries to determine their effectiveness


Links and Resources

AWS

re:Invent

DynamoDB

NoSQL

MongoDB

Groupon

JSON

PostgreSQL

Kelsus

Secret Stache Media


Quotes:


“Kind of what drove this evolution from SQL to NoSQL - realizing that the constraints were now different, the economics of the resources that were being used.” Chris Hickman


“People are realizing that Dynamo is not an ugly stepchild.” Jon Christensen


“Event-driven programming...it’s very popular, and it’s going to become even more popular.” Chris Hickman


End Song

Benirrás Nights by Roy England ft. Dovetracks

]]> Show Details

Jon Christensen and Chris Hickman of Kelsus and Rich Staats of Secret Stache continue their discussion on the birth of NoSQL and DynamoDB. They examine DynamoDB’s architecture and popularity as a solution for Internet-scale databases. 


Some of the highlights of the show include:

  • Challenges, evolution, and reasons associated with Internet-scale data
  • DynamoDB has been around a long time, but people are finally using it
  • DynamoDB and MongoDB are document or key value stores that offer scalability and event-driven programming to reduce complexity
  • Techniques for keeping NoSQL database’s replicated data in sync
  • Importance of indexes to understand query patterns
  • DynamoDB’s Table Concept: Collection of documents/key value items; must have partition key to uniquely identify items in table and determine data distribution
  • Sort keys create indexes (i.e. global/local secondary index) to support items within partitioning 
  • Query a DynamoDB database based on what’s being stored and using keys; conduct analysis on queries to determine their effectiveness


Links and Resources

AWS

re:Invent

DynamoDB

NoSQL

MongoDB

Groupon

JSON

PostgreSQL

Kelsus

Secret Stache Media


Quotes:


“Kind of what drove this evolution from SQL to NoSQL - realizing that the constraints were now different, the economics of the resources that were being used.” Chris Hickman


“People are realizing that Dynamo is not an ugly stepchild.” Jon Christensen


“Event-driven programming...it’s very popular, and it’s going to become even more popular.” Chris Hickman


End Song

Benirrás Nights by Roy England ft. Dovetracks

]]> Wed, 01 Apr 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 1780 Welcome to Mobycast! This is the third episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. In this episode we start to dive into the technical details of how AWS’s Dynamo DB works. If you’re just joining us at Mobycast, this will be your first taste of getting technical with us as we ease you into our library of curated, important cloud-native development topics. Welcome to Mobycast! This is the third episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. In this episode we start to d aws, cloud, software, development, programming No Replay of Ep 40 - The Birth of NoSQL and DynamoDb – Part 2 105 105 Replay of Ep 40 - The Birth of NoSQL and DynamoDb – Part 2 full ec664c63-e1fa-470f-9d6b-eb2d9da6e720 https://share.transistor.fm/s/34e4e86e Show Details

Jon Christensen and Rich Staats learn about Chris Hickman’s first venture-backed startup (circa 1998) and its goal to build a database for Internet-scale applications. His story highlights what software is all about – history repeating itself because technology/software is meant to solve problems via new tools, techniques, and bigger challenges at bigger scales.

Some of the highlights of the show include:

  • Why Chris left Microsoft and how much it cost him; yet, he has no regrets
  • Chris’s concept addressed how to build a scalable database layer; how to partition, chart, and cluster; and how to make it highly available and a completely scale-out architecture
  • Chris couldn’t use the code he had created for it while at Microsoft; but from that, he  learned what he wouldn’t do again
  • Chris let the file system be the database at Microsoft, and the project was named, Internet File Store (IFS); it used backend code and was similar to S3
  • Chris named his startup Viathan; had to do copyright, trademark, and domain name searches
  • Data for the Microsoft project could be stored in files/XML documents; Viathan took a different approach and used relational databases instead of a file system
  • Companies experienced problems at the beginning of the Internet; rest of ecosystem wasn’t developed and there weren’t enough people needing Internet solutions yet
  • Viathan went through several iterations that led to patents being issued and being considered as Prior art
  • Viathan’s technology couldn’t just be plugged in and turned on, applications had to be modified – a tough sell
  • Chris did groundbreaking work for what would become DynamoDB

Links and Resources

AWS

DynamoDB

AWS re:Invent 2018 – Keynote with Werner Vogels

re:Invent

DeepRacer

JSON

Moby Dick

MongoDB Acid Compliance

Prior Art

Kelsus

Secret Stache Media


]]> Show Details

Jon Christensen and Rich Staats learn about Chris Hickman’s first venture-backed startup (circa 1998) and its goal to build a database for Internet-scale applications. His story highlights what software is all about – history repeating itself because technology/software is meant to solve problems via new tools, techniques, and bigger challenges at bigger scales.

Some of the highlights of the show include:

  • Why Chris left Microsoft and how much it cost him; yet, he has no regrets
  • Chris’s concept addressed how to build a scalable database layer; how to partition, chart, and cluster; and how to make it highly available and a completely scale-out architecture
  • Chris couldn’t use the code he had created for it while at Microsoft; but from that, he  learned what he wouldn’t do again
  • Chris let the file system be the database at Microsoft, and the project was named, Internet File Store (IFS); it used backend code and was similar to S3
  • Chris named his startup Viathan; had to do copyright, trademark, and domain name searches
  • Data for the Microsoft project could be stored in files/XML documents; Viathan took a different approach and used relational databases instead of a file system
  • Companies experienced problems at the beginning of the Internet; rest of ecosystem wasn’t developed and there weren’t enough people needing Internet solutions yet
  • Viathan went through several iterations that led to patents being issued and being considered as Prior art
  • Viathan’s technology couldn’t just be plugged in and turned on, applications had to be modified – a tough sell
  • Chris did groundbreaking work for what would become DynamoDB

Links and Resources

AWS

DynamoDB

AWS re:Invent 2018 – Keynote with Werner Vogels

re:Invent

DeepRacer

JSON

Moby Dick

MongoDB Acid Compliance

Prior Art

Kelsus

Secret Stache Media


]]> Wed, 25 Mar 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2003 Welcome to Mobycast! This is the second episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. You’ll get to see how his work in the early 2000’s/late 90’s was instrumental to what later became the databases that we count on today. Anyway, the reason that you should listen to this is not because it’s a fun story but because we’re asking you to trust us here at Mobycast when we tell you what we think is the best way to do distributed systems and cloud-native development, and what better way to learn to trust us than to listen to how Chris got started in this whole world… Welcome to Mobycast! This is the second episode that we’re re-releasing from back when we told Chris’s personal story of starting Viathan, which was a software startup built to create one of the first internet scale databases. You’ll get to see how his wo aws, cloud, software, development, programming No Replay of Ep 39 - The Birth of NoSQL and DynamoDB 104 104 Replay of Ep 39 - The Birth of NoSQL and DynamoDB full 6c5e579a-79e8-4492-bb6c-c4430dad4a51 https://share.transistor.fm/s/4ca7dbc7 Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache offer a history lesson on the unique challenges of data at “Internet scale” that gave birth to NoSQL and DynamoDB. How did AWS get to where it is with DynamoDB? And, what is AWS doing now? 


Some of the highlights of the show include:

  • Werner’s Worst day at Amazon: Database system crashes during Super Saver Shipping
  • Amazon strives to prevent problems that it knows will happen again by realizing relational database management systems aren’t built/designed for the Internet/Cloud
  • Internet: Scale up vs. scale out via databases or servers; statefulness of databases prevents easy scalability
  • Need sharding and partitioning of data to have clusters that can be scaled up individually
  • Amazon’s Aha Moment: Realization that 90% of data accessed was simplistic, rather than relational; same thing happened at Microsoft - recall the Internet Tidal Wave memo?
  • Challenge of building applications using CGI bin when Internet was brand new
  • Solution: Build your own Internet database; optimize for scalability 

Links

AWS

re:Invent

DynamoDB

NoSQL

AWS re:Invent 2018 - Keynote with Andy Jassy

AWS re:Invent 2018 - Keynote with Werner Vogels

Oracle Database

Bill Gates’ Internet Tidal Wave

CGI Bin

Kelsus

Secret Stache Media



End Song

Whisper in a Dream by Uskmatu


More Info

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

]]> Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache offer a history lesson on the unique challenges of data at “Internet scale” that gave birth to NoSQL and DynamoDB. How did AWS get to where it is with DynamoDB? And, what is AWS doing now? 


Some of the highlights of the show include:

  • Werner’s Worst day at Amazon: Database system crashes during Super Saver Shipping
  • Amazon strives to prevent problems that it knows will happen again by realizing relational database management systems aren’t built/designed for the Internet/Cloud
  • Internet: Scale up vs. scale out via databases or servers; statefulness of databases prevents easy scalability
  • Need sharding and partitioning of data to have clusters that can be scaled up individually
  • Amazon’s Aha Moment: Realization that 90% of data accessed was simplistic, rather than relational; same thing happened at Microsoft - recall the Internet Tidal Wave memo?
  • Challenge of building applications using CGI bin when Internet was brand new
  • Solution: Build your own Internet database; optimize for scalability 

Links

AWS

re:Invent

DynamoDB

NoSQL

AWS re:Invent 2018 - Keynote with Andy Jassy

AWS re:Invent 2018 - Keynote with Werner Vogels

Oracle Database

Bill Gates’ Internet Tidal Wave

CGI Bin

Kelsus

Secret Stache Media



End Song

Whisper in a Dream by Uskmatu


More Info

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

]]> Wed, 18 Mar 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 1981 We present to you a remastered and re-released version of one of our early shows from 2018. It was one of our most popular shows of all time, and in it, Chris Hickman recounts his story of being a Microsoft employee dealing with issues of internet scaling in the late 90s to becoming one of the pioneers of NoSQL. Listen to this series to get to know Chris. These are the formative years of the guy who made Mobycast possible with his incredible depth and breadth of development experience. We present to you a remastered and re-released version of one of our early shows from 2018. It was one of our most popular shows of all time, and in it, Chris Hickman recounts his story of being a Microsoft employee dealing with issues of internet scaling aws, cloud, software, development, programming No Replay of Ep 14. Stop Worrying About Cloud Lock-in 103 103 Replay of Ep 14. Stop Worrying About Cloud Lock-in full 3c1a29f5-06d7-46f8-b763-3c9229a5a560 https://share.transistor.fm/s/ddf63d6d Original Show Notes:
At the recent Gluecon event, a popular topic centered around how to prevent Cloud Lock-in. Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache discuss why you your time is better spent focusing on one cloud provider. If/when Cloud Lock-in becomes an issue, you will have the resources to deal with it.

Some of the highlights of the show include:

  • AWS Fargate is ‘serverless ECS’. You don’t need to manage your own cluster nodes. This sounds great, but we’ve found the overhead of managing your own cluster to be minimal. Fargate is more expensive than ECS, and you have greater control if you manage your own cluster.
  • Cloud lock-in was a huge concern among people at Gluecon 2018. People from large companies talked about ‘being burned’ in the past with vendor lock-in. The likely risks are (1) price gouging and (2) vendors going out of business.
  • Cloud allows people to deploy faster and more cheaply than running their own hardware, as long as you don’t have huge scale. Few businesses get large enough to need their own data center on-prem to save money.
  • Small and startup companies often start off in the Cloud. Big companies often have their own data centers and they are now migrating to the Cloud.
  • AWS does allow you to run their software in your own data center, but this ties you to AWS.
  • There is huge complication and risk to architecting a system to run in multiple cloud environments, and it almost certainly wouldn’t run optimally in all clouds.
  • We think the risk of AWS hiking prices drastically, or going out of business, is essentially zero.
  • If you were building a microservice-based multi-cloud system, some of the difficulties include: Which cloud hosts the database? How do I spread my services across 2 clouds? What about latency between cloud providers networks? How do I maintain security? How do I staff people who are experts at operating in both clouds?
  • It’s clear that lock-in is a real fear for many companies, regardless of our opinion that it shouldn’t be such a concern.
  • Jon thinks the fear of lock-in may drive cloud providers toward standardization; Chris thinks AWS doesn’t have a compelling reason to standardize since they’re the industry leader.
  • Our advice: as a small or medium size company, don’t worry about cloud lock in. If you get big enough that it’s really a concern, we recommend building abstractions for the provider-specific parts of your system, and having a backup of your system ready to run in a 2nd cloud provider, but don’t try to run them concurrently.

Links and Resources

]]> Original Show Notes:
At the recent Gluecon event, a popular topic centered around how to prevent Cloud Lock-in. Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache discuss why you your time is better spent focusing on one cloud provider. If/when Cloud Lock-in becomes an issue, you will have the resources to deal with it.

Some of the highlights of the show include:

  • AWS Fargate is ‘serverless ECS’. You don’t need to manage your own cluster nodes. This sounds great, but we’ve found the overhead of managing your own cluster to be minimal. Fargate is more expensive than ECS, and you have greater control if you manage your own cluster.
  • Cloud lock-in was a huge concern among people at Gluecon 2018. People from large companies talked about ‘being burned’ in the past with vendor lock-in. The likely risks are (1) price gouging and (2) vendors going out of business.
  • Cloud allows people to deploy faster and more cheaply than running their own hardware, as long as you don’t have huge scale. Few businesses get large enough to need their own data center on-prem to save money.
  • Small and startup companies often start off in the Cloud. Big companies often have their own data centers and they are now migrating to the Cloud.
  • AWS does allow you to run their software in your own data center, but this ties you to AWS.
  • There is huge complication and risk to architecting a system to run in multiple cloud environments, and it almost certainly wouldn’t run optimally in all clouds.
  • We think the risk of AWS hiking prices drastically, or going out of business, is essentially zero.
  • If you were building a microservice-based multi-cloud system, some of the difficulties include: Which cloud hosts the database? How do I spread my services across 2 clouds? What about latency between cloud providers networks? How do I maintain security? How do I staff people who are experts at operating in both clouds?
  • It’s clear that lock-in is a real fear for many companies, regardless of our opinion that it shouldn’t be such a concern.
  • Jon thinks the fear of lock-in may drive cloud providers toward standardization; Chris thinks AWS doesn’t have a compelling reason to standardize since they’re the industry leader.
  • Our advice: as a small or medium size company, don’t worry about cloud lock in. If you get big enough that it’s really a concern, we recommend building abstractions for the provider-specific parts of your system, and having a backup of your system ready to run in a 2nd cloud provider, but don’t try to run them concurrently.

Links and Resources

]]> Wed, 11 Mar 2020 14:00:00 +0000 Mobycast.fm Mobycast.fm 1649 Cloud lock-in is always fun to talk about. Conversations abound on Twitter, at conferences, and by the water cooler. This week we replay an early episode from June 13, 2018 to see if our opinions on cloud lock-in have changed in the past two years.  Spoiler alert: they haven't. Cloud lock-in is always fun to talk about. Conversations abound on Twitter, at conferences, and by the water cooler. This week we replay an early episode from June 13, 2018 to see if our opinions on cloud lock-in have changed in the past two years.  Spoil aws, ecs, fargate, cloud, lock-in No Learn cloud native software development by podcast Learn cloud native software development by podcast trailer 1f4ea56c-2a15-4041-baaa-41632927a0ff https://share.transistor.fm/s/6814346a Start with 39. The Birth of NoSQL and DynamoDB – Part 1.

If you like that one, finish the five part series.

If you still want more? Ask me for advice. I'll tell you what are the next best ones at jon@mobycast.fm.

]]> Start with 39. The Birth of NoSQL and DynamoDB – Part 1.

If you like that one, finish the five part series.

If you still want more? Ask me for advice. I'll tell you what are the next best ones at jon@mobycast.fm.

]]> Sun, 08 Mar 2020 20:00:00 +0000 Mobycast.fm Mobycast.fm 135 You can learn how to be a great software developer by listening to this podcast. Get to know Chris and Jon by listening to our personal story, and continue from there into topics ranging from serverless to Docker to networking, encryption, and purpose built databases. We cover all the concepts great web application developers are expected to know. You can learn how to be a great software developer by listening to this podcast. Get to know Chris and Jon by listening to our personal story, and continue from there into topics ranging from serverless to Docker to networking, encryption, and purpose bui aws, cloud, software, development, programming No Automate all the things - Updating container secrets using CloudWatch Events + Lambda 102 102 Automate all the things - Updating container secrets using CloudWatch Events + Lambda full 18ed553e-2de5-4b0b-8ece-917f4d0f62de https://share.transistor.fm/s/c9a1108b In this episode, we cover the following topics:

  • Developing a system for automatically updating containers when secrets are updated is a two-part solution. First, we need to be notified when secrets are updated. Then, we need to trigger an action to update the ECS service.
  • CloudWatch Events can be used to receive notifications when secrets are updated. We explain CloudWatch Events and its primary components: events, rules and targets.
  • Event patterns are used to filter for the specific events that the rule cares about. We discuss how to write event patterns and the rules of matching events.
  • The event data structure will be different for each type of emitter. We detail a handy tip for determining the event structure of an emitter.
  • We discuss EventBridge and how it relates to CloudWatch Events.
  • We explain how to create CloudWatch Event rules for capturing update events emitted by both Systems Manager Parameter Store and AWS Secrets Manager.
  • AWS Lambda can be leveraged as a trigger of CloudWatch Events. We explain how to develop a Lambda function that invokes the ECS API to recycle all containers.
  • We finish up by showing how this works for a common use case: using the automatic credential rotation feature of AWS Secrets Manager with a containerized app running on ECS that connects to a RDS database.


Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Night Sea Journey by Derek Russo

More Info

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

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

]]> In this episode, we cover the following topics:

  • Developing a system for automatically updating containers when secrets are updated is a two-part solution. First, we need to be notified when secrets are updated. Then, we need to trigger an action to update the ECS service.
  • CloudWatch Events can be used to receive notifications when secrets are updated. We explain CloudWatch Events and its primary components: events, rules and targets.
  • Event patterns are used to filter for the specific events that the rule cares about. We discuss how to write event patterns and the rules of matching events.
  • The event data structure will be different for each type of emitter. We detail a handy tip for determining the event structure of an emitter.
  • We discuss EventBridge and how it relates to CloudWatch Events.
  • We explain how to create CloudWatch Event rules for capturing update events emitted by both Systems Manager Parameter Store and AWS Secrets Manager.
  • AWS Lambda can be leveraged as a trigger of CloudWatch Events. We explain how to develop a Lambda function that invokes the ECS API to recycle all containers.
  • We finish up by showing how this works for a common use case: using the automatic credential rotation feature of AWS Secrets Manager with a containerized app running on ECS that connects to a RDS database.


Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Night Sea Journey by Derek Russo

More Info

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

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

]]> Wed, 04 Mar 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 4095 Back in episode #94 of Mobycast, we showed how Amazon Elastic Container Service (or ECS) makes it easy to inject sensitive data into your containers. However, ECS only injects secrets at container startup. It's up to you to ensure that the container is restarted if secrets are updated. But who wants to manually restart containers? In this episode of Mobycast, Jon and Chris are back to provide an automated solution to this problem. We show you step-by-step how to leverage CloudWatch Events and Lambda to automatically update your container secrets. After listening, you'll be able to "automate all things". Well... at least for updating container secrets :-). Back in episode #94 of Mobycast, we showed how Amazon Elastic Container Service (or ECS) makes it easy to inject sensitive data into your containers. However, ECS only injects secrets at container startup. It's up to you to ensure that the container is AWS, Amazon Web Services, containers, Elastic Container Service, ECS, Secrets Manager, Systems Manager, Parameter Store, CloudWatch, CloudWatch events No Database Soup - Explaining ACID, BASE, CAP - Part 3 101 101 Database Soup - Explaining ACID, BASE, CAP - Part 3 full 4df4ede3-db59-4eeb-8337-e253e64b727e https://share.transistor.fm/s/a48d7744 In this episode, we cover the following topics:

  • In this new series, we are discussing database consistency models explained in three acts. This episode is "Act III: Eventual consistency saves the web (circa early 2000s)".
  • We explain eventual consistency and the motivation behind the philosophy.
  • The BASE acronym stands for three key properties of a distributed system that utilizes eventual consistency. We define and explain these BASE attributes:
  • Basically available
  • Soft state
  • Eventual consistency
  • We share the story of Werner Vogel's keynote at re:Invent 2018, where he outlined the reasons why DynamoDB was created. In particular, DynamoDB allows for an eventual consistency data model.
  • Interestingly, the DynamoDB story closely parallels what happened when Chris was at Microsoft. It just happened at least 6 years earlier.
  • We then wrap up everything we have learned about ACID, CAP, and BASE by providing some guidelines on when to choose ACID vs. BASE systems.


Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Whisper In A Dream (Feathericci Remix) by Uskmatu

More Info

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

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

]]> In this episode, we cover the following topics:

  • In this new series, we are discussing database consistency models explained in three acts. This episode is "Act III: Eventual consistency saves the web (circa early 2000s)".
  • We explain eventual consistency and the motivation behind the philosophy.
  • The BASE acronym stands for three key properties of a distributed system that utilizes eventual consistency. We define and explain these BASE attributes:
  • Basically available
  • Soft state
  • Eventual consistency
  • We share the story of Werner Vogel's keynote at re:Invent 2018, where he outlined the reasons why DynamoDB was created. In particular, DynamoDB allows for an eventual consistency data model.
  • Interestingly, the DynamoDB story closely parallels what happened when Chris was at Microsoft. It just happened at least 6 years earlier.
  • We then wrap up everything we have learned about ACID, CAP, and BASE by providing some guidelines on when to choose ACID vs. BASE systems.


Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Whisper In A Dream (Feathericci Remix) by Uskmatu

More Info

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

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

]]> Wed, 26 Feb 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2961 This week on Mobycast, Jon and Chris conclude their multi-part series on "database soup", where we make sense of the jumbled acronyms of consistency models. In this episode, we learn about eventual consistency and the BASE properties. Eventual consistency may sound like a beer guy meme - "I am not always consistent, but when I am, I get there eventually.". But it's no joke - eventual consistency is a key technique for scaling systems, and it's important to know what it is and when to use it. We finish up by summarizing what we have learned about ACID and BASE and knowing the tradeoffs each makes. Afterwards, you'll no longer confuse consistency models with the pH scale of your high school chemistry class. This week on Mobycast, Jon and Chris conclude their multi-part series on "database soup", where we make sense of the jumbled acronyms of consistency models. In this episode, we learn about eventual consistency and the BASE properties. Eventual consiste database consistency model, ACID, BASE, CAP theorem, eventual consistency No Database Soup - Explaining ACID, BASE, CAP - Part 2 100 100 Database Soup - Explaining ACID, BASE, CAP - Part 2 full e217ccdc-2c19-427e-a795-f742a6934d17 https://share.transistor.fm/s/d48fbb63 In this episode, we cover the following topics:

  • In this new series, we are discussing database consistency models explained in three acts. This episode is "Act II: The arrival of the Internet creates new challenges (circa 1998)".
  • Problems with building large scale-out systems led to the "discovery" of the CAP theorem (by Eric Brewer of Inktomi). We explain what the CAP theorem postulates and break it down in understandable terms.
  • The three properties of the CAP theorem are consistency, availability and partition tolerance. What exactly is meant by "partition tolerance"?
  • A key implication of the CAP theorem is that must choose your priorities. As a system scales, it cannot be both available and consistent.
  • We discuss Physalia, a technology developed by AWS for making Elastic Block Service (EBS) more resilient. The design of Physalia was inspired by the principles of the CAP theorem.
  • We then take a personal story detour that is (mostly) related to the CAP theorem. It turns out, Eric Brewer and Chris share a common experience during the first Internet bubble.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast


End Song

Disruption by Miquel Salla

More Info

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

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

]]> In this episode, we cover the following topics:

  • In this new series, we are discussing database consistency models explained in three acts. This episode is "Act II: The arrival of the Internet creates new challenges (circa 1998)".
  • Problems with building large scale-out systems led to the "discovery" of the CAP theorem (by Eric Brewer of Inktomi). We explain what the CAP theorem postulates and break it down in understandable terms.
  • The three properties of the CAP theorem are consistency, availability and partition tolerance. What exactly is meant by "partition tolerance"?
  • A key implication of the CAP theorem is that must choose your priorities. As a system scales, it cannot be both available and consistent.
  • We discuss Physalia, a technology developed by AWS for making Elastic Block Service (EBS) more resilient. The design of Physalia was inspired by the principles of the CAP theorem.
  • We then take a personal story detour that is (mostly) related to the CAP theorem. It turns out, Eric Brewer and Chris share a common experience during the first Internet bubble.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast


End Song

Disruption by Miquel Salla

More Info

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

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

]]> Wed, 19 Feb 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2727 This is part 2 of our three-part series where we make sense of the alphabet soup of acronyms for database consistency models. In this episode of Mobycast, we learn how the explosion of the Internet created new challenges for strongly consistent systems, leading to the "discovery" of the CAP theorem. The CAP theorem reminds us that as systems scale, errors will become more likely, forcing us to choose our priorities. We also learn what Chris shares in common with Eric Brewer, the creator of the CAP theorem. It's a roller coaster ride that comes to a crashing halt. This is part 2 of our three-part series where we make sense of the alphabet soup of acronyms for database consistency models. In this episode of Mobycast, we learn how the explosion of the Internet created new challenges for strongly consistent systems Database consistency model, ACID, CAP, BASE, CAP theorem, consistency, availability, partition tolerance network partition, Eric Brewer, Inkomi No Database Soup - Explaining ACID, BASE, CAP - Part 1 99 99 Database Soup - Explaining ACID, BASE, CAP - Part 1 full 60c99b07-123c-4ca2-93a2-b55ff9696e91 https://share.transistor.fm/s/72ef2153 In this episode, we cover the following topics:

  • In this new series, we are discussing database consistency models explained in three acts. This episode is "Act I: Transaction processing (circa 1973)".
  • We start with the motivation behind talking about database soup - why are ACID, CAP, and BASE important to understand?
  • We define transaction processing and its origins. What exactly is a "transaction"?
  • Transactions are governed by ACID semantics. We define and explain the four characteristics of the ACID acronym::
  • Atomicity
  • Consistency
  • Isolation
  • Durability
  • The computer scientist, Jim Gray, came up with the idea of ACID semantics in the late 1970's. We discuss some of the history behind this, along with a bizarre and tragic ending to his story.
  • We also share a personal story about another important player in transaction processing, Phil Bernstein.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast


End Song

Talcum by Lost Lake

More Info

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

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

]]> In this episode, we cover the following topics:

  • In this new series, we are discussing database consistency models explained in three acts. This episode is "Act I: Transaction processing (circa 1973)".
  • We start with the motivation behind talking about database soup - why are ACID, CAP, and BASE important to understand?
  • We define transaction processing and its origins. What exactly is a "transaction"?
  • Transactions are governed by ACID semantics. We define and explain the four characteristics of the ACID acronym::
  • Atomicity
  • Consistency
  • Isolation
  • Durability
  • The computer scientist, Jim Gray, came up with the idea of ACID semantics in the late 1970's. We discuss some of the history behind this, along with a bizarre and tragic ending to his story.
  • We also share a personal story about another important player in transaction processing, Phil Bernstein.

Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast


End Song

Talcum by Lost Lake

More Info

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

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

]]> Wed, 12 Feb 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2479 Databases are one of the fundamental building blocks for cloud-native apps. And with so many types of databases to choose from, it's important to understand their consistency models so that we can make smart choices. But with acronyms such as ACID and BASE, making sense of them can feel like swimming in a big bowl of database soup. Spoiler alert, they have nothing to do with high school chemistry class. In this episode of Mobycast, Jon and Chris kick off a three-part series where we dive deep on this database soup. In part 1, we learn about transaction processing, the ACID acronym and say hello to strong consistency. Databases are one of the fundamental building blocks for cloud-native apps. And with so many types of databases to choose from, it's important to understand their consistency models so that we can make smart choices. But with acronyms such as ACID and Database consistancy model, ACID, CAP, BASE, transaction processing, strong consistency, relational database, atomicity, Jim Gray, Phil Bernstein No Your Most Important Skill 98 98 Your Most Important Skill full 082d592e-f4e7-4473-8ea0-7b717b9383cd https://share.transistor.fm/s/2a2c706c Oh by the way, buy girl scout cookies from my daughter here! GIRL SCOUT COOKIEEEEES!

In this episode, we cover the following topics:

  • Technology is changing at an increasing rate, with a constant stream of new things to learn. We discuss how innovation has changed the rules of the game.
  • "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it." - Ferris Bueller
  • Chris recounts a personal story that emphasizes the importance of continual learning and growth.
  • During preparation for a previous Mobycast mini-series, he relies on a trusted solution pattern for accessing private subnets.
  • But during final fact checking, he discovers entirely new options that may be better/easier solutions.
  • We break down some important lessons learned from this experience.
  • Why do we think the following Stephen King quote is sage advice for all of us?
  • "Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings."
  • We then turn our attention to discussing what is your most important skill.
  • What is it?
  • How can you cultivate it?
  • Why does this matter?


Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Disco Pigs (Rave Mix) by Roy England

More Info

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

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

]]> Oh by the way, buy girl scout cookies from my daughter here! GIRL SCOUT COOKIEEEEES!

In this episode, we cover the following topics:

  • Technology is changing at an increasing rate, with a constant stream of new things to learn. We discuss how innovation has changed the rules of the game.
  • "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it." - Ferris Bueller
  • Chris recounts a personal story that emphasizes the importance of continual learning and growth.
  • During preparation for a previous Mobycast mini-series, he relies on a trusted solution pattern for accessing private subnets.
  • But during final fact checking, he discovers entirely new options that may be better/easier solutions.
  • We break down some important lessons learned from this experience.
  • Why do we think the following Stephen King quote is sage advice for all of us?
  • "Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings."
  • We then turn our attention to discussing what is your most important skill.
  • What is it?
  • How can you cultivate it?
  • Why does this matter?


Detailed Show Notes

Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast

https://glow.fm/mobycast

End Song

Disco Pigs (Rave Mix) by Roy England

More Info

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

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

]]> Wed, 05 Feb 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 3592 Technology is changing rapidly and it is a major investment to learn a new skill, technique or technology. Our knowledge gained is so hard fought that it is only natural to rely on it dearly. But it's a mistake to hold on to this knowledge for too long - you must be open to new ideas. In this episode of Mobycast, Chris shares with Jon a personal story about learning and growth. After being blindsided by relying on a familiar pattern, a valuable lesson is learned, one summed up well by author Stephen King when he implores us to "kill your darlings". Technology is changing rapidly and it is a major investment to learn a new skill, technique or technology. Our knowledge gained is so hard fought that it is only natural to rely on it dearly. But it's a mistake to hold on to this knowledge for too long AWS, Amazon Web Services, technology, cloud software, personal development, growth mindset, continuous learning No The Future of Containers - Part 3 - Unikernels 97 97 The Future of Containers - Part 3 - Unikernels full 054082ea-9f05-46e2-af63-c5be22698cc5 https://share.transistor.fm/s/5cd43bd9 In this episode, we cover the following topics:

  • We continue our discussion of microVMs with a look at Kata Containers.
  • Kata Containers formed by the merger of two projects: Intel Clear Containers and Hyper runV.
  • How does Kata Containers integrate with existing container tooling?
  • How mature are Kata Containers - are they ready for production?
  • We then take a look at unikernels, which take a dramatically different approach to solving the problem of providing high security with blazing performance.
  • The benefits of unikernels along with a comparison on how they differ from containers.
  • We discuss some of the most popular unikernel implementations, including OSv and MirageOS.
  • Does the future point to a deathmatch between containers and unikernels, or will there be a need for both approaches to cloud-native apps?


DETAILED SHOW NOTES
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

SUPPORT MOBYCAST
https://glow.fm/mobycast

END SONG
Palm of Your Hand by Blynkwth

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

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

]]> In this episode, we cover the following topics:

  • We continue our discussion of microVMs with a look at Kata Containers.
  • Kata Containers formed by the merger of two projects: Intel Clear Containers and Hyper runV.
  • How does Kata Containers integrate with existing container tooling?
  • How mature are Kata Containers - are they ready for production?
  • We then take a look at unikernels, which take a dramatically different approach to solving the problem of providing high security with blazing performance.
  • The benefits of unikernels along with a comparison on how they differ from containers.
  • We discuss some of the most popular unikernel implementations, including OSv and MirageOS.
  • Does the future point to a deathmatch between containers and unikernels, or will there be a need for both approaches to cloud-native apps?


DETAILED SHOW NOTES
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

SUPPORT MOBYCAST
https://glow.fm/mobycast

END SONG
Palm of Your Hand by Blynkwth

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

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

]]> Wed, 29 Jan 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 3447 What is the future of containers? In this three-part series, we are exploring the promising technologies aiming to make our cloud-native apps more secure without giving up performance. Previously, we learned all about microVMs, taking a deep dive on the most talked about microVM - AWS Firecracker. This week on Mobycast, we finish looking at microVMs with a discussion of Kata Containers. Then we explore the world of unikernels, which promise the same benefits as microVMs but with a dramatically different approach. Oh... and somewhere along the way, Chris accidentally invents a new technology - "conternels". What is the future of containers? In this three-part series, we are exploring the promising technologies aiming to make our cloud-native apps more secure without giving up performance. Previously, we learned all about microVMs, taking a deep dive on th AWS, Amazon Web Services, Docker, containerization, virtual machine, VM, containers, hypervisor, Firecracker, unikernel, virtualization No The Future of Containers - Part 2 - Making Sense of MicroVMs (continued) 96 96 The Future of Containers - Part 2 - Making Sense of MicroVMs (continued) full 885c41cf-0a02-4ee8-85eb-123806d60c61 https://share.transistor.fm/s/e4762573 In this episode, we cover the following topics:

  • We revisit a misunderstanding from last week's show to find out exactly what the Firecracker team means when they list "Single VM per Firecracker process" as a security benefit.
  • We discuss what's next on the Firecracker product roadmap, with particular emphasis on support for snapshot/restore.
  • We learn how AWS uses Firecracker in production today with AWS Lambda.
  • AWS is currently working on updating Fargate to use Firecracker. We look at why they are doing this and the design details of updating Fargate to use Firecracker.
  • We finish by looking at how you can use Firecracker for your own containers, by incorporating Firecracker-aware tooling into your container infrastructure. Specifically, we look at firecracker-containerd and Weave Ignite.


DETAILED SHOW NOTES
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

SUPPORT MOBYCAST
https://glow.fm/mobycast

END SONG
Thing Is by Public Address

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

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

]]> In this episode, we cover the following topics:

  • We revisit a misunderstanding from last week's show to find out exactly what the Firecracker team means when they list "Single VM per Firecracker process" as a security benefit.
  • We discuss what's next on the Firecracker product roadmap, with particular emphasis on support for snapshot/restore.
  • We learn how AWS uses Firecracker in production today with AWS Lambda.
  • AWS is currently working on updating Fargate to use Firecracker. We look at why they are doing this and the design details of updating Fargate to use Firecracker.
  • We finish by looking at how you can use Firecracker for your own containers, by incorporating Firecracker-aware tooling into your container infrastructure. Specifically, we look at firecracker-containerd and Weave Ignite.


DETAILED SHOW NOTES
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

SUPPORT MOBYCAST
https://glow.fm/mobycast

END SONG
Thing Is by Public Address

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

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

]]> Wed, 22 Jan 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 3652 Maybe you've heard some of the buzzwords everyone seems to be talking about when discussing the future of containers. Strange words like "microVMs"... "unikernels"... "sandboxes". Have you wondered what these things are and how you can use them? Or, for that matter, should you use them? In this episode of Mobycast, Jon and Chris continue their three-part series on the future of containers. We go deep on the most talked about microVM - AWS Firecracker. We learn how Amazon uses Firecracker and its tremendous benefits. We then discuss how to use Firecracker for your own containers and get the same great results. Maybe you've heard some of the buzzwords everyone seems to be talking about when discussing the future of containers. Strange words like "microVMs"... "unikernels"... "sandboxes". Have you wondered what these things are and how you can use them? Or, fo AWS, Amazon Web Services, Docker, containerization, virtual machine, VM, containers, hypervisor, Firecracker, unikernel, Kata Containers, virtualization No The Future of Containers - Part 1 - Making Sense of MicroVMs 95 95 The Future of Containers - Part 1 - Making Sense of MicroVMs full b3ee825a-79ad-44bf-9de9-b681fed7f6f3 https://share.transistor.fm/s/1853bfc3 In this episode, we cover the following topics:

  • We review virtual machines (full virtualization) and their benefits and tradeoffs.
  • We then revisit containers (OS-level virtualization) and briefly recap how they use OS kernel features to enable virtualization.
  • Containers provide great performance and resource efficiency, but at the cost of losing strong isolation. Can we have the performance and efficiency benefits of containers but with the strong isolation of VMs? There are some promising technologies that aim to combine the best of both VM and container worlds: microVMs, unikernels and container sandboxes.
  • What are microVMs?
  • What are unikernels?
  • What are container sandboxes?
  • AWS Firecracker is one of the most talked about microVMs. We discuss what it is, and the key benefits of using Firecracker.


DETAILED SHOW NOTES
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

SUPPORT MOBYCAST
https://glow.fm/mobycast

END SONG
Smooth Modulator by aMIGAaMIGO

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

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

]]> In this episode, we cover the following topics:

  • We review virtual machines (full virtualization) and their benefits and tradeoffs.
  • We then revisit containers (OS-level virtualization) and briefly recap how they use OS kernel features to enable virtualization.
  • Containers provide great performance and resource efficiency, but at the cost of losing strong isolation. Can we have the performance and efficiency benefits of containers but with the strong isolation of VMs? There are some promising technologies that aim to combine the best of both VM and container worlds: microVMs, unikernels and container sandboxes.
  • What are microVMs?
  • What are unikernels?
  • What are container sandboxes?
  • AWS Firecracker is one of the most talked about microVMs. We discuss what it is, and the key benefits of using Firecracker.


DETAILED SHOW NOTES
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

SUPPORT MOBYCAST
https://glow.fm/mobycast

END SONG
Smooth Modulator by aMIGAaMIGO

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

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

]]> Wed, 15 Jan 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 4103 With cloud computing, we started with virtual machines. They allow us to virtualize an entire server, while providing strong isolation and security. Then containers came along. They allow us to virtualize just our applications, making containers faster and less resource intensive than VMs. But with these gains we lose strong isolation. What if we could have the speed and resource efficiency of containers coupled with the enhanced security and isolation of VMs? In this episode of Mobycast, Jon and Chris kick off a three-part series on the future of containers. We dive deep on microVMs, unikernels and container sandboxes, understanding what they are, how they work, and how well they combine the best of both VM and container worlds. With cloud computing, we started with virtual machines. They allow us to virtualize an entire server, while providing strong isolation and security. Then containers came along. They allow us to virtualize just our applications, making containers faster AWS, Amazon Web Services, Docker, containerization, virtual machine, VM, containers, hypervisor, Firecracker, unikernel, Kata Containers, virtualization No Psst... Secrets Handling for Cloud-Native Apps - Part 2 94 94 Psst... Secrets Handling for Cloud-Native Apps - Part 2 full a5d4b8e8-e345-479e-b2fb-5cd7439171e6 https://share.transistor.fm/s/345ae5b0 In this episode, we cover the following topics:

  • AWS offers not one, but two, managed services for secrets management. Systems Manager Parameter Store and AWS Secrets Manager have similar functionality, making it sometimes confusing to know which to use. We compare and contrast the two services to help guide your choice.
  • The three types of sensitive data injection supported by Elastic Container Service (ECS).
  • Understanding when sensitive data is injected into the container and how to handle updates to secrets (such as credential rotation).
  • The required configuration changes and IAM permissions you need to enable ECS integration with Parameter Store and Secrets Manager.
  • A walkthrough of the specific steps you need to take to update your ECS application to support secrets integration.


Detailed Show Notes
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast
https://glow.fm/mobycast

End Song
Straddling by Derek Russo

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

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

]]> In this episode, we cover the following topics:

  • AWS offers not one, but two, managed services for secrets management. Systems Manager Parameter Store and AWS Secrets Manager have similar functionality, making it sometimes confusing to know which to use. We compare and contrast the two services to help guide your choice.
  • The three types of sensitive data injection supported by Elastic Container Service (ECS).
  • Understanding when sensitive data is injected into the container and how to handle updates to secrets (such as credential rotation).
  • The required configuration changes and IAM permissions you need to enable ECS integration with Parameter Store and Secrets Manager.
  • A walkthrough of the specific steps you need to take to update your ECS application to support secrets integration.


Detailed Show Notes
Want the complete episode outline with detailed notes? Sign up here: https://mobycast.fm/show-notes/

Support Mobycast
https://glow.fm/mobycast

End Song
Straddling by Derek Russo

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

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

]]> Wed, 08 Jan 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 2802 In episode #93 of Mobycast, we discussed secrets management for our cloud-native applications. We learned why we need secrets management and some of the possible solutions available to us. Now that we know the "theory", it's time to put that knowledge into practice. In this episode of Mobycast, Jon and Chris finish their two-part series on handling secrets with cloud-native apps. We show you how to easily implement secrets management for a containerized application running on Amazon Elastic Container Service (or ECS). After this episode, you'll be a pro at keeping a secret! In episode #93 of Mobycast, we discussed secrets management for our cloud-native applications. We learned why we need secrets management and some of the possible solutions available to us. Now that we know the "theory", it's time to put that knowledge AWS, Amazon Web Services, secrets management, secrets handling, containers, Elastic Container Service, ECS, Secrets Manager, Systems Manager, Parameter Store No Psst... Secrets Handling for Cloud-Native Apps - Part 1 93 93 Psst... Secrets Handling for Cloud-Native Apps - Part 1 full a4bcaea0-c05c-4204-9d0e-5ffbddda2fb0 https://share.transistor.fm/s/518bf571 Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we cover the following topics:

  • What is secrets management and why we need it for our cloud-native applications.
  • Guidelines for best practices when handling secrets.
  • We walkthrough a simple, roll-your-own approach to secrets management using encryption (KMS) and an object store (S3).
    • Although this is a simple technique, it does provide a very secure (and auditable) approach to secrets handling.
  • But, for most situtations, you'll want to leverage an off-the-shelf secrets management solution. We discuss 3 popular choices, including Hashicorp Vault, AWS Systems Manager Parameter Store and Amazon Secrets Manager.
  • What are the features you should expect from a secrets management solution.
  • We take a closer look at Vault, Parameter Store and Secrets Manager, and discuss the features that each provides.
  • We finish with some guidance on how to make the right choice of secrets management solution for your applications.

Links


End Song
Warming Trend by Aphreaq

More Info


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

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

]]> Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we cover the following topics:

  • What is secrets management and why we need it for our cloud-native applications.
  • Guidelines for best practices when handling secrets.
  • We walkthrough a simple, roll-your-own approach to secrets management using encryption (KMS) and an object store (S3).
    • Although this is a simple technique, it does provide a very secure (and auditable) approach to secrets handling.
  • But, for most situtations, you'll want to leverage an off-the-shelf secrets management solution. We discuss 3 popular choices, including Hashicorp Vault, AWS Systems Manager Parameter Store and Amazon Secrets Manager.
  • What are the features you should expect from a secrets management solution.
  • We take a closer look at Vault, Parameter Store and Secrets Manager, and discuss the features that each provides.
  • We finish with some guidance on how to make the right choice of secrets management solution for your applications.

Links


End Song
Warming Trend by Aphreaq

More Info


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

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

]]> Wed, 01 Jan 2020 13:00:00 +0000 Mobycast.fm Mobycast.fm 3349 Applications frequently need access to sensitive data, such as database credentials, API keys, passwords and tokens. Of course, we can't just store these secrets in plain text or hard-coded into our applications. Rather, we need to securely protect this sensitive information to ensure that only those with a "need to know" basis can access it. In this episode of Mobycast, Jon and Chris kick off a two-part series on handling secrets for your cloud-native applications. We discuss various approaches to secrets management, ranging from basic roll-your-own techniques to fully managed solutions. We explore some of the most popular options out there and help you decide which one is best for you. Applications frequently need access to sensitive data, such as database credentials, API keys, passwords and tokens. Of course, we can't just store these secrets in plain text or hard-coded into our applications. Rather, we need to securely protect thi AWS, Amazon Web Services, secrets management, secrets handling, containers, Secrets Manager, Parameter Store, Hashicorp Vault No VPC Ninja - Part 3 - Moving an ECS Application to Private Subnets 92 92 VPC Ninja - Part 3 - Moving an ECS Application to Private Subnets full 9694acb7-251d-461b-9005-b0ab05353721 https://share.transistor.fm/s/e7f81202 Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we explain how to move an existing ECS application to private subnets. We cover the following topics:

  • We describe the existing application, which is a typical two-tier web application, with a web service fronted by an Application Load Balancer (ALB) and database hosted on MySQL using RDS.
    • The current application is containerized and running under ECS.
    • Everything (the load balancer, ECS cluster, RDS instance) is running on public subnets.
  • The goal is to leave only the ALB public-facing, with all other resources protected on private subnets.
  • There are two phases to moving the application to private subnets. First, we need to move the ECS cluster to private subnets. Then, we can move the RDS instance to private subnets.
  • We detail step-by-step two deployment approaches for moving our ECS cluster to private subnets, both of which involve zero downtime.
    • Rolling deployment, which updates the existing cluster in-place.
    • Blue/green deployment, which creates a new cluster to replace the existing one.
  • We discuss the steps on moving the database instance to private subnets, including application downtime considerations.
  • As a bonus, we explain how to add encryption-at-rest to the RDS instance during the migration.

Links

End Song

The Runner (Lost Lake Remix) by Fax

More Info

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

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

]]> Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we explain how to move an existing ECS application to private subnets. We cover the following topics:

  • We describe the existing application, which is a typical two-tier web application, with a web service fronted by an Application Load Balancer (ALB) and database hosted on MySQL using RDS.
    • The current application is containerized and running under ECS.
    • Everything (the load balancer, ECS cluster, RDS instance) is running on public subnets.
  • The goal is to leave only the ALB public-facing, with all other resources protected on private subnets.
  • There are two phases to moving the application to private subnets. First, we need to move the ECS cluster to private subnets. Then, we can move the RDS instance to private subnets.
  • We detail step-by-step two deployment approaches for moving our ECS cluster to private subnets, both of which involve zero downtime.
    • Rolling deployment, which updates the existing cluster in-place.
    • Blue/green deployment, which creates a new cluster to replace the existing one.
  • We discuss the steps on moving the database instance to private subnets, including application downtime considerations.
  • As a bonus, we explain how to add encryption-at-rest to the RDS instance during the migration.

Links

End Song

The Runner (Lost Lake Remix) by Fax

More Info

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

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

]]> Wed, 25 Dec 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3228 In the first two episodes of this series, we learned how to build a VPC with public and private subnets. We did a deep dive on NAT, or network address translation, and then setup a software-only VPN for secure access to the private subnets. Now, it's time to put everything together and earn our cloud networking black belt. This week on Mobycast, Jon and Chris conclude their three-part series on how to incorporate private subnets for your cloud network. We finish by explaining step-by-step how to move an existing ECS application onto our new private subnets. Now... go build, ninja! In the first two episodes of this series, we learned how to build a VPC with public and private subnets. We did a deep dive on NAT, or network address translation, and then setup a software-only VPN for secure access to the private subnets. Now, it's t AWS, Amazon Web Services, VPC, virtual private cloud, VPN, virtual private network, private subnet, containers, Elastic Container Service, ECS No That's a Wrap - AWS re:Invent 2019 Takeaways - Part 2 91 91 That's a Wrap - AWS re:Invent 2019 Takeaways - Part 2 bonus e5397926-cb8f-4c2d-a301-5ba31a20014b https://share.transistor.fm/s/ca03be94 Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we cover the following topics:

  • Recap and analysis of Andy Jassy's keynote, including:
    • The theme of this year's keynote is transformation, presented via 6 theme songs.
    • "The hunger keeps on growing" (Dave Matthews Band, "Too Much")
      • Storage performance is growing much faster than compute/memory (6x faster since 2012). This is enabling new innovations like AQUA for Redshift, making it 10x faster than any other cloud data warehouse.
      • How the new Ultrawarm for Elasticsearch tier reduces cost by 90%.
      • AWS helps again with undifferentiated heavy lifting by offering a managed Cassandra service.
    • "I would walk 500 miles" (The Proclaimers, "I'm Gonna Be (500 Miles)")
      • AWS is one of the best places for AI/ML across all layers of the stack.
      • SageMaker is a vibrant ML platform that is rapidly evolving into the next generation developer desktop.
      • Can AWS really automate code reviews with its new Code Guru service?
      • Using the power of AI to search for enterprise data with Kendra.
    • "Break on through to the other side" (The Doors, "Break on Through")
      • If you can't come to AWS, AWS is coming to you! AWS infrastructure is everywhere with VMware Cloud on AWS, AWS Outposts, AWS Local Zones and AWS Wavelength.
  • Recap and analysis of Werner Vogel's keynote, including:
    • The problems and limitations of classic virtualization (Xen-based).
    • How the Nitro System takes a microservices approach to computer system design.
    • The importance of Firecracker as a next generation VM.
    • A case-study of the Elastic Block Service (EBS) architecture and how AWS is using a new technology called Physalia to battle the CAP theorem.
    • You can now learn more about how AWS designs and develops software with the new Amazon Builders' Library.
  • Key takeaways
    • The Nitro System is a key technology that is enabling AWS to break through barriers. It will provide us with powerful new capabilities to tackle previously unsolvable problems.
    • AWS is everywhere, extending all the way out to the edge with IoT/Greengrass, and everywhere in between with on-premise (AWS Outposts), near-premise (Local Zones) and even integrated on the 5G network with AWS Wavelength.
    • AWS is a leader in AI/ML, with Sagemaker becoming a next generation developer platform.
    • Analytics is a big priority, with focus on Redshift and data lakes.
    • Quantum computing is no longer the stuff of science fiction. It will be here sooner than you think.

Links


End Song

Walking Dub For Black Queens, by Place

More Info

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

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

]]> Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we cover the following topics:

  • Recap and analysis of Andy Jassy's keynote, including:
    • The theme of this year's keynote is transformation, presented via 6 theme songs.
    • "The hunger keeps on growing" (Dave Matthews Band, "Too Much")
      • Storage performance is growing much faster than compute/memory (6x faster since 2012). This is enabling new innovations like AQUA for Redshift, making it 10x faster than any other cloud data warehouse.
      • How the new Ultrawarm for Elasticsearch tier reduces cost by 90%.
      • AWS helps again with undifferentiated heavy lifting by offering a managed Cassandra service.
    • "I would walk 500 miles" (The Proclaimers, "I'm Gonna Be (500 Miles)")
      • AWS is one of the best places for AI/ML across all layers of the stack.
      • SageMaker is a vibrant ML platform that is rapidly evolving into the next generation developer desktop.
      • Can AWS really automate code reviews with its new Code Guru service?
      • Using the power of AI to search for enterprise data with Kendra.
    • "Break on through to the other side" (The Doors, "Break on Through")
      • If you can't come to AWS, AWS is coming to you! AWS infrastructure is everywhere with VMware Cloud on AWS, AWS Outposts, AWS Local Zones and AWS Wavelength.
  • Recap and analysis of Werner Vogel's keynote, including:
    • The problems and limitations of classic virtualization (Xen-based).
    • How the Nitro System takes a microservices approach to computer system design.
    • The importance of Firecracker as a next generation VM.
    • A case-study of the Elastic Block Service (EBS) architecture and how AWS is using a new technology called Physalia to battle the CAP theorem.
    • You can now learn more about how AWS designs and develops software with the new Amazon Builders' Library.
  • Key takeaways
    • The Nitro System is a key technology that is enabling AWS to break through barriers. It will provide us with powerful new capabilities to tackle previously unsolvable problems.
    • AWS is everywhere, extending all the way out to the edge with IoT/Greengrass, and everywhere in between with on-premise (AWS Outposts), near-premise (Local Zones) and even integrated on the 5G network with AWS Wavelength.
    • AWS is a leader in AI/ML, with Sagemaker becoming a next generation developer platform.
    • Analytics is a big priority, with focus on Redshift and data lakes.
    • Quantum computing is no longer the stuff of science fiction. It will be here sooner than you think.

Links


End Song

Walking Dub For Black Queens, by Place

More Info

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

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

]]> Thu, 19 Dec 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 2752 Last episode of Mobycast, we began our post-coverage analysis of AWS re:Invent 2019. With a major theme of "transformation", we walked through some of the key advancements being made by AWS to drive innovation now and into the future. From supercomputing to networking to AI and ML, AWS is proof that there is "no compression algorithm for experience." In this episode of Mobycast, Jon and Chris conclude their special two-part mini-series on this year's re:Invent conference. We finish recapping the big keynote sessions and highlight the major themes of this year's show. We close it all out by sharing our most important takeways that you need to know. Last episode of Mobycast, we began our post-coverage analysis of AWS re:Invent 2019. With a major theme of "transformation", we walked through some of the key advancements being made by AWS to drive innovation now and into the future. From supercomputing AWS, Amazon Web Services, re:Invent, reinvent, Andy Jassy, Werner Vogels, Nitro System, Nitro hypervisor No That's a Wrap - AWS re:Invent 2019 Takeaways - Part 1 91 91 That's a Wrap - AWS re:Invent 2019 Takeaways - Part 1 full 9c9300d4-1940-471b-89d4-ab10fd9603f9 https://share.transistor.fm/s/b4870799 Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we cover the following topics:

  • re:Invent 2019 by the numbers: 65,000 attendees, 3,000+ sessions, 4 keynotes, 6 venues.
  • Recap and analysis of Monday Night Live keynote with Peter DeSantis, including:
    • What is high performance computing (HPC)?
    • How AWS is reinventing the supercomputer.
    • Why everyone should care about HPC, not just the scientists.
    • How networking advancements are paving the way forward for cluster computing and enabling entirely new types of problem solving.
    • A discussion of the Elastic Fabric Adapter (EFA) and the new Scalable Reliable Datagram (SRD) networking protocol as a replacement for TCP for high performance networking.
    • Using the Nitro System to enable new instance types for machine learning infrastructure, such as the P3dn, G4dn and Inf1 instance types.
    • Utilizing custom silicon to make the "Inferentia" processor, which is a high-performance ML inference chip.
  • Recap and analysis of Andy Jassy's keynote, including:
    • The theme of this year's keynote is transformation, presented via 6 theme songs.
    • "Don't wait until tomorrow" (Van Halen, "Right Now")
      • Your transformation needs to start today. The problems will only get harder, deeper tomorrow.
    • "Don't stop me now, I'm having such a good time" (Queen, "Don't Stop Me Now")
      • Developers love AWS and its capabilities (175+ services, breadth & depth).
      • AWS is rapidly innovating its compute capabilities with new instance types (driven by Nitro System) and new ways of running containers (including the just announced Fargate for EKS).
    • "Is that all you get for your money?" (Billy Joel, "Movin' Out (Anthony's Song)")
      • You need to modernize your technology stack. Get off mainframes, migrate away from the old guard databases with their licensing tricks, and switching from Windows to Linux.
    • "The hunger keeps on growing" (Dave Matthews Band, "Too Much")
      • Data is exploding, and customers are moving from data silos to data lakes, with S3 the most popular choice for data lakes.
      • New feature, Amazon S3 Access Points, helps make giving access to S3 data easier on a per user/application basis.
      • AWS is a leader in analytics infrastructure with Athena, EMR, Redshift, ElastiSearch, Kinesis, and QuickSight.
      • AWS is investing heavily in its Redshift platform, with many new features announced including the ability to now manage compute and storage separately using the new Redshift RA3 instances.

Links


End Song

You Just Can’t, by Roy England

More Info

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

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

]]> Support Mobycast
-> https://glow.fm/mobycast <-

In this episode, we cover the following topics:

  • re:Invent 2019 by the numbers: 65,000 attendees, 3,000+ sessions, 4 keynotes, 6 venues.
  • Recap and analysis of Monday Night Live keynote with Peter DeSantis, including:
    • What is high performance computing (HPC)?
    • How AWS is reinventing the supercomputer.
    • Why everyone should care about HPC, not just the scientists.
    • How networking advancements are paving the way forward for cluster computing and enabling entirely new types of problem solving.
    • A discussion of the Elastic Fabric Adapter (EFA) and the new Scalable Reliable Datagram (SRD) networking protocol as a replacement for TCP for high performance networking.
    • Using the Nitro System to enable new instance types for machine learning infrastructure, such as the P3dn, G4dn and Inf1 instance types.
    • Utilizing custom silicon to make the "Inferentia" processor, which is a high-performance ML inference chip.
  • Recap and analysis of Andy Jassy's keynote, including:
    • The theme of this year's keynote is transformation, presented via 6 theme songs.
    • "Don't wait until tomorrow" (Van Halen, "Right Now")
      • Your transformation needs to start today. The problems will only get harder, deeper tomorrow.
    • "Don't stop me now, I'm having such a good time" (Queen, "Don't Stop Me Now")
      • Developers love AWS and its capabilities (175+ services, breadth & depth).
      • AWS is rapidly innovating its compute capabilities with new instance types (driven by Nitro System) and new ways of running containers (including the just announced Fargate for EKS).
    • "Is that all you get for your money?" (Billy Joel, "Movin' Out (Anthony's Song)")
      • You need to modernize your technology stack. Get off mainframes, migrate away from the old guard databases with their licensing tricks, and switching from Windows to Linux.
    • "The hunger keeps on growing" (Dave Matthews Band, "Too Much")
      • Data is exploding, and customers are moving from data silos to data lakes, with S3 the most popular choice for data lakes.
      • New feature, Amazon S3 Access Points, helps make giving access to S3 data easier on a per user/application basis.
      • AWS is a leader in analytics infrastructure with Athena, EMR, Redshift, ElastiSearch, Kinesis, and QuickSight.
      • AWS is investing heavily in its Redshift platform, with many new features announced including the ability to now manage compute and storage separately using the new Redshift RA3 instances.

Links


End Song

You Just Can’t, by Roy England

More Info

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

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

]]> Wed, 18 Dec 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3092 We're happy to report that we are back and survived AWS re:Invent. As promised, re:Invent is a heavyweight of a conference and this year did not disappoint! With 4 keynotes, over 3,000 sessions, and hundreds of new product and feature announcements, we've got a lot of ground to cover. In fact, we have so much to share with you, that we are splitting this into a special two-part mini-series. In this episode of Mobycast, we start by recapping some of the big keynote sessions and discuss the new products and technologies that we are most excited about. We're happy to report that we are back and survived AWS re:Invent. As promised, re:Invent is a heavyweight of a conference and this year did not disappoint! With 4 keynotes, over 3,000 sessions, and hundreds of new product and feature announcements, we AWS, Amazon Web Services, re:Invent, reinvent, Andy Jassy, Monday Night Live, Nitro System, Nitro hypervisor No VPC Ninja - Part 2 - Private subnets with VPN (continued) 90 90 VPC Ninja - Part 2 - Private subnets with VPN (continued) full 0c48e60e-0e5a-4335-a76c-8088666a5926 https://share.transistor.fm/s/0d264505 Support Mobycast
https://glow.fm/mobycast

In this episode, we cover the following topics:

  • Before we get started, a CAVEAT. There are other (potentially BETTER) ways of accessing resources on private subnets. 
    • We'll talk about these (such as AWS Client VPN or AWS Systems Manager Session Manager) in future episodes. 
    • But a great choice (with the most flexibility/power) remains our current choice: a third-party software-only VPN solution. 
  • There are many options for third-party software VPNs, both commercial and open source. Some of the options we considered include: 
    • SoftEther 
    • Openswan 
    • OpenVPN (* our choice) 
  • Discussion of the different flavors and pricing models for OpenVPN Access Server.
  • Step-by-step walkthrough of installing OpenVPN Access Server via the AWS Marketplace. 
    • Including how to setup TLS for your VPN server. 
  • We detail the process of how to create private subnets within a VPC. 
    • Create new subnets to be used as private subnets, keeping in mind a multi-AZ design. 
    • Routing table considerations. 
    • Setting up a NAT gateway to forward Internet traffic for private subnets. 
  • Some pro tips to keep in mind when building out your cloud network. 
    • CIDR block considerations (the "Goldilocks" approach to sizing). 
    • Did you know that NAT gateways are SPOFs? We discuss how to improve availability. 

Links


End Song
Tachyon, 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:

 

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

In this episode, we cover the following topics:

  • Before we get started, a CAVEAT. There are other (potentially BETTER) ways of accessing resources on private subnets. 
    • We'll talk about these (such as AWS Client VPN or AWS Systems Manager Session Manager) in future episodes. 
    • But a great choice (with the most flexibility/power) remains our current choice: a third-party software-only VPN solution. 
  • There are many options for third-party software VPNs, both commercial and open source. Some of the options we considered include: 
    • SoftEther 
    • Openswan 
    • OpenVPN (* our choice) 
  • Discussion of the different flavors and pricing models for OpenVPN Access Server.
  • Step-by-step walkthrough of installing OpenVPN Access Server via the AWS Marketplace. 
    • Including how to setup TLS for your VPN server. 
  • We detail the process of how to create private subnets within a VPC. 
    • Create new subnets to be used as private subnets, keeping in mind a multi-AZ design. 
    • Routing table considerations. 
    • Setting up a NAT gateway to forward Internet traffic for private subnets. 
  • Some pro tips to keep in mind when building out your cloud network. 
    • CIDR block considerations (the "Goldilocks" approach to sizing). 
    • Did you know that NAT gateways are SPOFs? We discuss how to improve availability. 

Links


End Song
Tachyon, 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:

 

]]> Wed, 11 Dec 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3704 In episode #89 of Mobycast, we introduced using private subnets for your cloud network. We learned about the differences between public and private subnets, as well as some of the key technologies they depend upon such as NAT, or network address translation. We also learned that using private subnets comes with a new problem - how to access these private resources? We discussed three primary approaches, before settling on VPN as our choice. In this episode of Mobycast, Jon and Chris continue their three-part series on using private subnets with your cloud network. We finish our network design by guiding you step-by-step in setting up a software-based VPN and building out private subnets. We also share some inside tips that will make you look like a cloud networking pro. In episode #89 of Mobycast, we introduced using private subnets for your cloud network. We learned about the differences between public and private subnets, as well as some of the key technologies they depend upon such as NAT, or network address translati AWS, Amazon Web Services, VPC, virtual private cloud, VPN, virtual private network, private subnet, OpenVPN, Open VPN No VPC Ninja - Part 1 - Private Subnets with VPN 89 89 VPC Ninja - Part 1 - Private Subnets with VPN full bb446ac1-a766-4213-8f67-78ec7f00c894 https://share.transistor.fm/s/556b83e6 Support Mobycast
https://glow.fm/mobycast

Show Details

In this episode, we cover the following topics:

  • Subnet 101
    • Public subnets
      • Used for public facing resources which allow inbound connections from the public Internet
    • Private subnets
      • What are they?
        • Used for resources that should not be exposed to open Internet
        • Do not allow direct access from open Internet
        • Require use of network address translation (NAT) for egress-only Internet access
      • Why use private subnets?
        • Protect your cloud servers from script kiddies
        • Limit exposure
    • Security groups and routing tables allow resources on public subnets to communicate with private subnets
  • NAT (network address translation) deep dive
    • What is NAT?
      • Remaps one IP address space into another
        • Done by modifying network address information in IP header of packets while in transit across routing device
      • Tool to deal with IPv4 address exhaustion
        • Only need single public IP address for NAT, which hides entire private network behind it
      • Note: Actual role of NAT device is both address translation and port address translation
    • How does it work?
      • IP header consists of:
        • Source IP
        • Source port
        • Destination IP
        • Destination port
      • Routing device modifies IP address in packets
        • Outgoing packets (from private-to-public)
          • Source IP and port changed to NAT values
            • I.e. packets appear to originate from NAT (instead of private IP itself)
        • Incoming packets (public-to-private)
          • Dest IP and port changes to private values
      • For TCP/UDP
        • NAT keeps in memory table that maps traffic to private IPs
          • Table includes each active connection (particularly the destination address and port)
          • When reply comes back to router, uses table to determine private IP that reply should be forwarded to
          • Port numbers are changed so combination of IP and port on returned packet can be unambiguously mapped to corresponding private destination
          • Note: conversation to open Internet has to originate in private network!
            • This is because initial message establishes required information in translation table
  • How can a single computer have both public and private IP addresses?
    • A quick primer on IP addresses and network interface cards
      • MAC (media access control) address
        • Physical address
        • Unique ID assigned to NIC
      • IP address
        • Logical address
      • Network switches maintain Address Resolution Protocol (ARP) tables that map IP addresses to MAC addresses
        • ARP table used to know which MAC address to attach to packet
      • Single NIC can have multiple IP addresses
  • Alas, private subnets are less convenient than public subnets.
    • Instances on private subnet won't be publicly accessible, they can only be accessed from inside the network.
    • This leads to the problem of how to connect to an instance on a private subnet from a remote location?
      • Three broad categories of solutions:
        • Direct Connect
          • Dedicated network connection over private lines straight into AWS backbone
          • Requires network equipment on customer side
          • Cons:
            • Requires dedicated hardware
            • Expensive
            • Applicable only when you have an on-prem location that needs to be physically connected to VPC
        • Bastion host (jump host)
          • Public-facing server running SSH daemon
            • Once connected to bastion host, users can then ssh to machines on private subnet
          • Typically have a single instance on public subnet
            • Minimizes surface area to be protected
          • Cons:
            • Adds an extra layer of indirection
            • ssh key management is more complicated
            • SPOF
            • Security risk of protecting the bastion host
        • VPN (virtual private network)
          • Many different options, ranging in cost and equipment requirements
          • For both connecting on-prem location, as well as general remote user access
  • VPN
    • Available options
      • Managed VPN
        • Managed IPsec VPN connection over existing internet
        • Quick and usually simple method for making secure connection to VPC
        • Can be used as redundant link for Direct Connect
        • Supports static routes or BGP peering/routing
        • How to setup:
          • Designate an appliance to act as your customer gateway (usually the on-prem router)
          • Create VPN connection in AWS and download config file for your customer gateway
          • Configure customer gateway with config file
      • VPN CloudHub
        • Connect locations in hub and spoke manner using Virtual Private Gateway
        • Allows remote locations to communicate with each other via the hub (Virtual Private Gateway in AWS)
        • Each remote location uses Site-to-Site VPN connection to connect to hub
        • Reuses existing internet connection
        • Supports BGP routes to direct traffic
          • e.g. use MPLS first then CloudHub VPN as backup
        • How to setup:
          • Assign multiple Customer Gateways to a Virtual Private Gateway, each with their own BGP ASN and unique IP ranges
      • Third-party software VPN
        • You provide your own VPN endpoint/software
        • Use this option if you must manage both ends of VPN connection
        • How to setup:
          • Install VPN software via Marketplace appliance or on EC2 instance
    • TIL... AWS has increased the options
      • Managed VPN is now known as "AWS Site-to-Site VPN"
      • New option: "AWS Client VPN"
        • Fully managed, highly available software-only VPN
        • Supports OpenVPN-based clients
      • We'll discuss "AWS Client VPN" in-depth in a future episode
    • Our choice for this episode: let's setup a third-party software VPN solution
      • Rationale:
        • Not too much $$$
        • Pretty sophisticated solution that's easy to manage

Links

End Song
Zero Gravity 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:

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

Show Details

In this episode, we cover the following topics:

  • Subnet 101
    • Public subnets
      • Used for public facing resources which allow inbound connections from the public Internet
    • Private subnets
      • What are they?
        • Used for resources that should not be exposed to open Internet
        • Do not allow direct access from open Internet
        • Require use of network address translation (NAT) for egress-only Internet access
      • Why use private subnets?
        • Protect your cloud servers from script kiddies
        • Limit exposure
    • Security groups and routing tables allow resources on public subnets to communicate with private subnets
  • NAT (network address translation) deep dive
    • What is NAT?
      • Remaps one IP address space into another
        • Done by modifying network address information in IP header of packets while in transit across routing device
      • Tool to deal with IPv4 address exhaustion
        • Only need single public IP address for NAT, which hides entire private network behind it
      • Note: Actual role of NAT device is both address translation and port address translation
    • How does it work?
      • IP header consists of:
        • Source IP
        • Source port
        • Destination IP
        • Destination port
      • Routing device modifies IP address in packets
        • Outgoing packets (from private-to-public)
          • Source IP and port changed to NAT values
            • I.e. packets appear to originate from NAT (instead of private IP itself)
        • Incoming packets (public-to-private)
          • Dest IP and port changes to private values
      • For TCP/UDP
        • NAT keeps in memory table that maps traffic to private IPs
          • Table includes each active connection (particularly the destination address and port)
          • When reply comes back to router, uses table to determine private IP that reply should be forwarded to
          • Port numbers are changed so combination of IP and port on returned packet can be unambiguously mapped to corresponding private destination
          • Note: conversation to open Internet has to originate in private network!
            • This is because initial message establishes required information in translation table
  • How can a single computer have both public and private IP addresses?
    • A quick primer on IP addresses and network interface cards
      • MAC (media access control) address
        • Physical address
        • Unique ID assigned to NIC
      • IP address
        • Logical address
      • Network switches maintain Address Resolution Protocol (ARP) tables that map IP addresses to MAC addresses
        • ARP table used to know which MAC address to attach to packet
      • Single NIC can have multiple IP addresses
  • Alas, private subnets are less convenient than public subnets.
    • Instances on private subnet won't be publicly accessible, they can only be accessed from inside the network.
    • This leads to the problem of how to connect to an instance on a private subnet from a remote location?
      • Three broad categories of solutions:
        • Direct Connect
          • Dedicated network connection over private lines straight into AWS backbone
          • Requires network equipment on customer side
          • Cons:
            • Requires dedicated hardware
            • Expensive
            • Applicable only when you have an on-prem location that needs to be physically connected to VPC
        • Bastion host (jump host)
          • Public-facing server running SSH daemon
            • Once connected to bastion host, users can then ssh to machines on private subnet
          • Typically have a single instance on public subnet
            • Minimizes surface area to be protected
          • Cons:
            • Adds an extra layer of indirection
            • ssh key management is more complicated
            • SPOF
            • Security risk of protecting the bastion host
        • VPN (virtual private network)
          • Many different options, ranging in cost and equipment requirements
          • For both connecting on-prem location, as well as general remote user access
  • VPN
    • Available options
      • Managed VPN
        • Managed IPsec VPN connection over existing internet
        • Quick and usually simple method for making secure connection to VPC
        • Can be used as redundant link for Direct Connect
        • Supports static routes or BGP peering/routing
        • How to setup:
          • Designate an appliance to act as your customer gateway (usually the on-prem router)
          • Create VPN connection in AWS and download config file for your customer gateway
          • Configure customer gateway with config file
      • VPN CloudHub
        • Connect locations in hub and spoke manner using Virtual Private Gateway
        • Allows remote locations to communicate with each other via the hub (Virtual Private Gateway in AWS)
        • Each remote location uses Site-to-Site VPN connection to connect to hub
        • Reuses existing internet connection
        • Supports BGP routes to direct traffic
          • e.g. use MPLS first then CloudHub VPN as backup
        • How to setup:
          • Assign multiple Customer Gateways to a Virtual Private Gateway, each with their own BGP ASN and unique IP ranges
      • Third-party software VPN
        • You provide your own VPN endpoint/software
        • Use this option if you must manage both ends of VPN connection
        • How to setup:
          • Install VPN software via Marketplace appliance or on EC2 instance
    • TIL... AWS has increased the options
      • Managed VPN is now known as "AWS Site-to-Site VPN"
      • New option: "AWS Client VPN"
        • Fully managed, highly available software-only VPN
        • Supports OpenVPN-based clients
      • We'll discuss "AWS Client VPN" in-depth in a future episode
    • Our choice for this episode: let's setup a third-party software VPN solution
      • Rationale:
        • Not too much $$$
        • Pretty sophisticated solution that's easy to manage

Links

End Song
Zero Gravity 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:

]]> Wed, 04 Dec 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3470 You may know that it is best practice to use private subnets for your cloud network. But, have you actually implemented them? They can be challenging to setup, especially if you have an existing VPC. And using private subnets creates a new dilemma... how do you even connect to these resources? Jon sometimes complains that Mobycast makes him eat his "security broccoli". Well, its time we add "networking cauliflower" to the mix to ensure that he (and you!) have a well-balanced cloud-native diet. In this episode of Mobycast, we kick off a three-part series detailing step-by-step how to incorporate private subnets for your cloud network. After listening to these episodes, you'll be able to setup your VPC like a true networking ninja! You may know that it is best practice to use private subnets for your cloud network. But, have you actually implemented them? They can be challenging to setup, especially if you have an existing VPC. And using private subnets creates a new dilemma... h AWS, Amazon Web Services, VPC, virtual private cloud, VPN, virtual private network, NAT, network address translation, public subnet, private subnet, bastion host No AWS re:Invent 2019 - A Preview Show 88 88 AWS re:Invent 2019 - A Preview Show full f370092f-c354-4ae9-abd6-28029270fb85 https://share.transistor.fm/s/f98c50ea Support Mobycast
https://glow.fm/mobycast

In this episode, we cover the following topics:

  • AWS re:Invent general overview
    • December 2nd thru December 6th
    • 2,500+ sessions, spread over 6 venues, spanning 2.5 miles of the Las Vegas Strip
  • Discuss the 4 primary types of content and the pros/cons of each
    • Sessions, chalk talks, workshops and builders sessions
  • Our general observations of themes to expect this year
    • Hint: Kubernetes is hot
  • We point out some of the sessions we are particularly looking forward to
  • re:Invent is not all work, you get to play too
    • re:play
    • Other parties and where to find them
  • Our predictions for new product/service announcements at re:Invent 2019
  • We also talk about Apple's recent launch of a new MacBook Pro (goodbye butterfly keyboard!)

Links

End Song

Flowerchild (Lost Lake Remix) by Owen Ni
 

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

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

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

In this episode, we cover the following topics:

  • AWS re:Invent general overview
    • December 2nd thru December 6th
    • 2,500+ sessions, spread over 6 venues, spanning 2.5 miles of the Las Vegas Strip
  • Discuss the 4 primary types of content and the pros/cons of each
    • Sessions, chalk talks, workshops and builders sessions
  • Our general observations of themes to expect this year
    • Hint: Kubernetes is hot
  • We point out some of the sessions we are particularly looking forward to
  • re:Invent is not all work, you get to play too
    • re:play
    • Other parties and where to find them
  • Our predictions for new product/service announcements at re:Invent 2019
  • We also talk about Apple's recent launch of a new MacBook Pro (goodbye butterfly keyboard!)

Links

End Song

Flowerchild (Lost Lake Remix) by Owen Ni
 

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

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

]]> Wed, 27 Nov 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3681 Let's get ready to rumble! It's that time of year when we head to Las Vegas with 50,000 of our closest friends for the biggest AWS event of the year: re:Invent. Five days long, with more than 2,500 sessions, taking place in 6 huge venues spread over 2.5 miles, re:Invent is a heavyweight of a conference. If you don't plan ahead, re:Invent will take you down in a TKO. In this episode of Mobycast, Jon and Chris are in your corner, breaking down this year's event with the tips, tricks and secrets you need to make the most of re:Invent. Let's get ready to rumble! It's that time of year when we head to Las Vegas with 50,000 of our closest friends for the biggest AWS event of the year: re:Invent. Five days long, with more than 2,500 sessions, taking place in 6 huge venues spread over 2. AWS re:Invent, re:Invent, reinvent, AWS conference, AWS, Amazon Web Services, Amazon No Serverless Containers with ECS Fargate - Part 3 87 87 Serverless Containers with ECS Fargate - Part 3 full 33087736-d933-4acb-b042-37f85a7b8ac7 https://share.transistor.fm/s/aaf8f788 Support Mobycast
https://glow.fm/mobycast

Show Details

In this episode, we cover the following topics:

  • Container networking
    • ECS networking mode
      • Configures the Docker networking mode to use for the containers in the task
        • Specified as part of the task definition
      • Valid values:
        • none
          • Containers do not have external connectivity and port mappings can't be specified in the container definition
        • bridge
          • Utilizes Docker's built-in virtual network which runs inside each container instance
            • Containers on an instance are connected to each other using the docker0 bridge
            • Containers use this bridge to communicate with endpoints outside of the instance using primary ENI of instance they are running on
            • Containers share networking properties of the primary ENI, including the firewall rules and IP addressing
            • Containers are addressed by combination of IP address of primary ENI and host port to which they are mapped
          • Cons:
            • You cannot address these containers with the IP address allocated by Docker
              • It comes from pool of locally scoped addresses
            • You cannot enforce finely grained network ACLs and firewall rules
        • host
          • Bypass Docker's built-in virtual network and maps container ports directly to the EC2's NIC directly
          • You can't run multiple instantiations of the same task on a single container instance when port mappings are used
        • awsvpc
          • Each task is allocated its own ENI and IP address
            • Multiple applications (including multiple copies of same app) can run on same port number without conflict
          • You must specify a NetworkConfiguration when you create a service or run a task with the task definition
      • Default networking mode is bridge
      • host and awsvpc network modes offer the highest networking performance
        • They use the Amazon EC2 network stack instead of the virtualized network stack provided by the bridge mode
        • Cannot take advantage of dynamic host port mappings
        • Exposed container ports are mapped directly...
          • host: to corresponding host port
          • awsvpc: to attached elastic network interface port
    • Task networking (aka awsvpc mode networking)
      • Benefits
        • Each task has its own attached ENI
          • With primary private IP address and internal DNS hostname
        • Simplifies container networking
          • No host port specified
            • Container port is what is used by task ENI
            • Container ports must be unique in a single task definition
        • Gives more control over how tasks communicate
          • With other tasks
            • Containers share a network namespace
            • Communicate with each other over localhost interface
              • e.g. curl 127.0.0.1:8080
          • With other services in VPC
          • Note: containers that belong to the same task can communicate over the localhost interface
        • Take advantage of VPC Flow Logs
        • Better security through use of security groups
          • You can assign different security groups to each task, which gives you more fine-grained security
      • Limitations
        • The number of ENIs that can be attached to EC2 instances is fairly small
          • E.g. c5.large EC2 may have up to 3 ENIs attached to it
            • 1 primary, and 2 for task networking
            • Therefore, you can only host 2 tasks using awsvpc mode networking on a c5.large
        • However, you can increase ENI density using "VPC trunking"
    • VPC trunking
      • Allows for overcoming ENI density limits
      • Multiplexes data over shared communication link
      • How it works
        • Two ENIs are attached to the instance
          • Primary ENI
          • Trunk ENI
            • Note that enabling trunking consumes an additional IP address per instance
        • Your account, IAM user, or role must opt in to the awsvpcTrunking account setting
      • Benefits
        • Up to 5x-17x more ENIs per instance
        • E.g. with trunking, c5.large goes from 3 to 12 ENIs
          • 1 primary, 1 trunk, and 10 for task networking
  • Migrating a container from EC2 to Fargate
    • IAM roles
      • Roles created automatically by ECS
        • Amazon ECS service-linked IAM role, AWSServiceRoleForECS
          • Gives permission to attach ENI to instance
        • Task Execution IAM Role (ecsTaskExecutionRole)
          • Needed for:
            • Pulling images from ECR
            • Pushing logs to CloudWatch
      • Create a task-based IAM role
        • Required because we don't have an ecsInstanceRole anymore
        • Create a IAM policy that gives minimal privileges needed by task
          • Remember two categories of policies:
            • AWS Managed
            • Customer Managed
          • We are going to create a new customer managed policy that contains only the permissions our app needs
            • KMS Decrypt, S3 GETs from specific bucket
          • IAM -> Policies -> Create Policy -> JSON
        • Create role based on "Elastic Container Service Task" service role
          • This service role gives permission to ECS to use STS to assume role (sts:AssumeRole) and perform actions on its behalf
          • IAM -> Roles -> Create Role
            • "Select type of trusted entity": AWS Service
            • Choose "Elastic Container Service", and then "Elastic Container Service Task" use case
            • Next, then attach IAM policy we created to the role and save
    • Task definition file changes
      • Task-level parameters
        • Add FARGATE for requiredCompatibilities
        • Use awsvpc as the network mode
        • Specify cpu and memory limits at the task level
        • Specify Task Execution IAM Role (executionRoleARN)
          • Allows task to pull images from ECR and send logs to CloudWatch Logs
        • Specify task-based IAM role (taskDefinitionArn)
          • Needed to give task permissions to perform AWS API calls (such as S3 reads)
      • Container-level parameters
        • Only specify containerPort (do not specify hostPort)
      • See Task Definition example below
    • Create ECS service
      • Choose cluster
      • Specify networking
        • VPC, subnets
        • Create a security group for this task
          • Security group is attached to the ENI
          • Allow inbound port 80 traffic
        • Auto-assign public IP
      • Attach to existing application load balancer
        • Specify production listener (port/protocol)
        • Create a new target group
          • When creating target group, you specify "target type"
            • Instance
            • IP
            • Lambda function
          • For awsvpc mode (and by default, Fargate), you must use the IP target type
        • Specify path pattern for ALB listener, health check path
          • Note: you cannot specify host-based routing through the console
            • You can update that after creating the service through the ALB console
    • Update security groups
      • Security group for ALB
        • Allow outbound port 80 to the security group we attached to our ENI
      • Security group for RDS
        • Allow inbound port 3306 from the security group for our ENI
    • Create Route 53 record
      • ALIAS pointing to our ALB
    • Log integration with SumoLogic
      • Update task to send logs to stdout/...
]]> Support Mobycast
https://glow.fm/mobycast

Show Details

In this episode, we cover the following topics:

  • Container networking
    • ECS networking mode
      • Configures the Docker networking mode to use for the containers in the task
        • Specified as part of the task definition
      • Valid values:
        • none
          • Containers do not have external connectivity and port mappings can't be specified in the container definition
        • bridge
          • Utilizes Docker's built-in virtual network which runs inside each container instance
            • Containers on an instance are connected to each other using the docker0 bridge
            • Containers use this bridge to communicate with endpoints outside of the instance using primary ENI of instance they are running on
            • Containers share networking properties of the primary ENI, including the firewall rules and IP addressing
            • Containers are addressed by combination of IP address of primary ENI and host port to which they are mapped
          • Cons:
            • You cannot address these containers with the IP address allocated by Docker
              • It comes from pool of locally scoped addresses
            • You cannot enforce finely grained network ACLs and firewall rules
        • host
          • Bypass Docker's built-in virtual network and maps container ports directly to the EC2's NIC directly
          • You can't run multiple instantiations of the same task on a single container instance when port mappings are used
        • awsvpc
          • Each task is allocated its own ENI and IP address
            • Multiple applications (including multiple copies of same app) can run on same port number without conflict
          • You must specify a NetworkConfiguration when you create a service or run a task with the task definition
      • Default networking mode is bridge
      • host and awsvpc network modes offer the highest networking performance
        • They use the Amazon EC2 network stack instead of the virtualized network stack provided by the bridge mode
        • Cannot take advantage of dynamic host port mappings
        • Exposed container ports are mapped directly...
          • host: to corresponding host port
          • awsvpc: to attached elastic network interface port
    • Task networking (aka awsvpc mode networking)
      • Benefits
        • Each task has its own attached ENI
          • With primary private IP address and internal DNS hostname
        • Simplifies container networking
          • No host port specified
            • Container port is what is used by task ENI
            • Container ports must be unique in a single task definition
        • Gives more control over how tasks communicate
          • With other tasks
            • Containers share a network namespace
            • Communicate with each other over localhost interface
              • e.g. curl 127.0.0.1:8080
          • With other services in VPC
          • Note: containers that belong to the same task can communicate over the localhost interface
        • Take advantage of VPC Flow Logs
        • Better security through use of security groups
          • You can assign different security groups to each task, which gives you more fine-grained security
      • Limitations
        • The number of ENIs that can be attached to EC2 instances is fairly small
          • E.g. c5.large EC2 may have up to 3 ENIs attached to it
            • 1 primary, and 2 for task networking
            • Therefore, you can only host 2 tasks using awsvpc mode networking on a c5.large
        • However, you can increase ENI density using "VPC trunking"
    • VPC trunking
      • Allows for overcoming ENI density limits
      • Multiplexes data over shared communication link
      • How it works
        • Two ENIs are attached to the instance
          • Primary ENI
          • Trunk ENI
            • Note that enabling trunking consumes an additional IP address per instance
        • Your account, IAM user, or role must opt in to the awsvpcTrunking account setting
      • Benefits
        • Up to 5x-17x more ENIs per instance
        • E.g. with trunking, c5.large goes from 3 to 12 ENIs
          • 1 primary, 1 trunk, and 10 for task networking
  • Migrating a container from EC2 to Fargate
    • IAM roles
      • Roles created automatically by ECS
        • Amazon ECS service-linked IAM role, AWSServiceRoleForECS
          • Gives permission to attach ENI to instance
        • Task Execution IAM Role (ecsTaskExecutionRole)
          • Needed for:
            • Pulling images from ECR
            • Pushing logs to CloudWatch
      • Create a task-based IAM role
        • Required because we don't have an ecsInstanceRole anymore
        • Create a IAM policy that gives minimal privileges needed by task
          • Remember two categories of policies:
            • AWS Managed
            • Customer Managed
          • We are going to create a new customer managed policy that contains only the permissions our app needs
            • KMS Decrypt, S3 GETs from specific bucket
          • IAM -> Policies -> Create Policy -> JSON
        • Create role based on "Elastic Container Service Task" service role
          • This service role gives permission to ECS to use STS to assume role (sts:AssumeRole) and perform actions on its behalf
          • IAM -> Roles -> Create Role
            • "Select type of trusted entity": AWS Service
            • Choose "Elastic Container Service", and then "Elastic Container Service Task" use case
            • Next, then attach IAM policy we created to the role and save
    • Task definition file changes
      • Task-level parameters
        • Add FARGATE for requiredCompatibilities
        • Use awsvpc as the network mode
        • Specify cpu and memory limits at the task level
        • Specify Task Execution IAM Role (executionRoleARN)
          • Allows task to pull images from ECR and send logs to CloudWatch Logs
        • Specify task-based IAM role (taskDefinitionArn)
          • Needed to give task permissions to perform AWS API calls (such as S3 reads)
      • Container-level parameters
        • Only specify containerPort (do not specify hostPort)
      • See Task Definition example below
    • Create ECS service
      • Choose cluster
      • Specify networking
        • VPC, subnets
        • Create a security group for this task
          • Security group is attached to the ENI
          • Allow inbound port 80 traffic
        • Auto-assign public IP
      • Attach to existing application load balancer
        • Specify production listener (port/protocol)
        • Create a new target group
          • When creating target group, you specify "target type"
            • Instance
            • IP
            • Lambda function
          • For awsvpc mode (and by default, Fargate), you must use the IP target type
        • Specify path pattern for ALB listener, health check path
          • Note: you cannot specify host-based routing through the console
            • You can update that after creating the service through the ALB console
    • Update security groups
      • Security group for ALB
        • Allow outbound port 80 to the security group we attached to our ENI
      • Security group for RDS
        • Allow inbound port 3306 from the security group for our ENI
    • Create Route 53 record
      • ALIAS pointing to our ALB
    • Log integration with SumoLogic
      • Update task to send logs to stdout/...
]]> Wed, 20 Nov 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3514 You may not be an expert on container networking, but wouldn't you like to impress guests at your next party by explaining the difference between "host" and "bridge" networking? This week on Mobycast, Jon and Chris conclude their three-part series on serverless containers with AWS Fargate. We wrap our heads around container networking and its various networking modes, with particular emphasis on task networking (aka "awsvpc" mode). We finish by pulling together everything we learned over these 3 episodes to walk step-by-step through the migration of a container from EC2 to Fargate. After this episode, you'll be the life of the party! You may not be an expert on container networking, but wouldn't you like to impress guests at your next party by explaining the difference between "host" and "bridge" networking? This week on Mobycast, Jon and Chris conclude their three-part series on s AWS, Docker, Containers, ECS, VPC, Kubernetes No Bonus Episode! Docker Is Kind of Acquired By ... Who Is Mirantis? Bonus Episode! Docker Is Kind of Acquired By ... Who Is Mirantis? bonus 9a22987f-e72b-4d78-8fad-2481682e6ddf https://share.transistor.fm/s/708ced52 Support Mobycast
https://glow.fm/mobycast

Links


End Song
La Place by Iwa

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

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

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

Links


End Song
La Place by Iwa

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

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

]]> Sat, 16 Nov 2019 15:00:00 +0000 Mobycast.fm Mobycast.fm 1386 Docker sold its Docker Enterprise business to Mirantis last week. The internet has been abuzz with hot takes and laments for the once high flying unicorn. In this short bonus episode of Mobycast, Jon and Chris discuss what this really means for Docker, we use some logic to calculate what the likely sale price was, and we make a prediction for what will happen to what is left of Docker within the next year. Chris has been taking careful notes on Docker as a business for a few years now, so he has absolutely brilliant insight into what this sale means not just for Docker but for the cloud industry as a whole. Give this bonus episode a listen and wow your colleagues with your expert analysis on Monday when you roll into the office. Docker sold its Docker Enterprise business to Mirantis last week. The internet has been abuzz with hot takes and laments for the once high flying unicorn. In this short bonus episode of Mobycast, Jon and Chris discuss what this really means for Docker Docker, cloud, AWS, GCP, Hashicorp, Azure, Microsoft No Serverless Containers with ECS Fargate - Part 2 86 86 Serverless Containers with ECS Fargate - Part 2 full 0a33e3a4-368a-49e3-86d1-16c2ac8ee739 https://share.transistor.fm/s/7dbcfd48 Support Mobycast
https://glow.fm/mobycast

In this episode, we cover the following topics:

  • Identity and access management for ECS
    • Primary roles
      • ECS Container Instance IAM Role
        • ecsInstanceRole
        • IAM policy and role required by ECS agent to make ECS API calls on your behalf
      • ECS Service Scheduler IAM Role
        • ecsServiceRole
        • ECS service scheduler makes calls to EC2 and ELB APIs on your behalf
          • Register/deregister container instances with load balancers
      • ECS Task Execution IAM Role
        • ecsTaskExecutionRole
        • Also used by ECS agent to make AWS API calls on your behalf
        • Typical use cases
          • Your task uses Fargate and is...
            • pulling a container image from Amazon ECR
            • uses the awslogs log driver
          • Your tasks uses either Fargate or EC2 launch type and...
            • pulls images from private registry
            • the task definition is referencing sensitive data using Secrets Manager or Parameter Store
    • Secondary roles
      • ECS Service Auto Scaling IAM Role
        • ecsAutoscaleRole
        • Used by Application Auto Scaling service to describe CloudWatch alarms and registered services
          • Updates ECS services's desired count
      • CloudWatch Events IAM Role
        • ecsEventsRole
        • Required role when you have ECS scheduled tasks
        • Interacts with CloudWatch Events rules and targets
        • This IAM policy and role gives CloudWatch permissions to run ECS tasks on your behalf
      • ECS CodeDeploy IAM Role
        • ecsCodeDeployRole
        • Required when doing blue/green deployments (powered by CodeDeploy)
    • Best practice: Using task-based IAM roles
      • IAM role for Amazon ECS tasks
        • Allows you to specify an IAM role that can be used by the containers in a task
        • IAM role for task is specified using the taskRoleArn setting in task definition
      • Prefer more granular task-based IAM roles over instance roles
      • Each specific task definition or service should have its own role
      • Benefits of task-based IAM roles
        • Least privilege
          • By specifying access at the task-level (instead of at the instance-level), we can have fine-grained control
          • Only give the minimum required permissions for the tasks to operate
        • Credential isolation
          • Container can only use credentials assigned to it
        • Auditability
          • Access and event logging available via CloudTrail
          • CloudTrail logs show taskArn
      • Creating a task-based IAM role
        • First create IAM policy that specifies the minimal permissions needed by your containers
          • Or use an existing managed policy
        • Next create an IAM role for your task
          • Create role based on Amazon Elastic Container Service Task Role service role
        • Then attach your IAM policy to the task role
        • Example: Container needs to make S3 calls
          • Create a new IAM role for the task, and attach the "AmazonS3ReadOnlyAccess" policy to the role
          • Then use the role ARN in task definition

Links


End Song
Beauty in Rhythm (Fredy Grogan Remix) - 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:


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

In this episode, we cover the following topics:

  • Identity and access management for ECS
    • Primary roles
      • ECS Container Instance IAM Role
        • ecsInstanceRole
        • IAM policy and role required by ECS agent to make ECS API calls on your behalf
      • ECS Service Scheduler IAM Role
        • ecsServiceRole
        • ECS service scheduler makes calls to EC2 and ELB APIs on your behalf
          • Register/deregister container instances with load balancers
      • ECS Task Execution IAM Role
        • ecsTaskExecutionRole
        • Also used by ECS agent to make AWS API calls on your behalf
        • Typical use cases
          • Your task uses Fargate and is...
            • pulling a container image from Amazon ECR
            • uses the awslogs log driver
          • Your tasks uses either Fargate or EC2 launch type and...
            • pulls images from private registry
            • the task definition is referencing sensitive data using Secrets Manager or Parameter Store
    • Secondary roles
      • ECS Service Auto Scaling IAM Role
        • ecsAutoscaleRole
        • Used by Application Auto Scaling service to describe CloudWatch alarms and registered services
          • Updates ECS services's desired count
      • CloudWatch Events IAM Role
        • ecsEventsRole
        • Required role when you have ECS scheduled tasks
        • Interacts with CloudWatch Events rules and targets
        • This IAM policy and role gives CloudWatch permissions to run ECS tasks on your behalf
      • ECS CodeDeploy IAM Role
        • ecsCodeDeployRole
        • Required when doing blue/green deployments (powered by CodeDeploy)
    • Best practice: Using task-based IAM roles
      • IAM role for Amazon ECS tasks
        • Allows you to specify an IAM role that can be used by the containers in a task
        • IAM role for task is specified using the taskRoleArn setting in task definition
      • Prefer more granular task-based IAM roles over instance roles
      • Each specific task definition or service should have its own role
      • Benefits of task-based IAM roles
        • Least privilege
          • By specifying access at the task-level (instead of at the instance-level), we can have fine-grained control
          • Only give the minimum required permissions for the tasks to operate
        • Credential isolation
          • Container can only use credentials assigned to it
        • Auditability
          • Access and event logging available via CloudTrail
          • CloudTrail logs show taskArn
      • Creating a task-based IAM role
        • First create IAM policy that specifies the minimal permissions needed by your containers
          • Or use an existing managed policy
        • Next create an IAM role for your task
          • Create role based on Amazon Elastic Container Service Task Role service role
        • Then attach your IAM policy to the task role
        • Example: Container needs to make S3 calls
          • Create a new IAM role for the task, and attach the "AmazonS3ReadOnlyAccess" policy to the role
          • Then use the role ARN in task definition

Links


End Song
Beauty in Rhythm (Fredy Grogan Remix) - 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:


]]> Wed, 13 Nov 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3445 In episode #85 of Mobycast, we introduced AWS Fargate, which brings the serverless concept to running containers on ECS. We discussed the features and benefits of Fargate, as well as how it differs from normal EC2 launch types. Now it's time to dive deeper into some of the details you need to know to successfully run your containers on Fargate. In this episode of Mobycast, Jon and Chris continue their three-part series on serverless containers with an in-depth discussion of identity and access management for ECS. We learn about the various roles you will encounter, why they are needed and how to use them. We also share a best practice that will make you look like a security pro! In episode #85 of Mobycast, we introduced AWS Fargate, which brings the serverless concept to running containers on ECS. We discussed the features and benefits of Fargate, as well as how it differs from normal EC2 launch types. Now it's time to dive de AWS, Docker, Containers, ECS, VPC, Kubernetes No Serverless Containers with ECS Fargate - Part 1 85 85 Serverless Containers with ECS Fargate - Part 1 full 8d71bb13-56c8-4574-84eb-500d334f6541 https://share.transistor.fm/s/51eacef4 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


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:

]]> 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


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:

]]> Wed, 06 Nov 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3882 The Amazon Elastic Container Service (or ECS) is the container orchestration system built by AWS. ECS features tight integration with many AWS services, and is a powerful choice for running containers in the cloud. We first discussed ECS back in episode 3 of Mobycast. But so much has changed in the 18 months since then, bringing many major improvements. One new feature is Fargate, which brings the serverless concept to containers. With Fargate, you no longer need to manage servers. You don't pay for idle CPU. And there is the promise of seamless scaling. Sounds perfect, right? Well, as with most things that sound too good to be true, there are some limitations and gotchas. In this episode of Mobycast, Jon and Chris kick off a three-part series where we dive deep into Fargate. We learn the ins and outs of running containers without managing servers and discuss the trade-offs we make when ditching those servers. The Amazon Elastic Container Service (or ECS) is the container orchestration system built by AWS. ECS features tight integration with many AWS services, and is a powerful choice for running containers in the cloud. We first discussed ECS back in episod AWS, Docker, Containers, ECS, VPC, Kubernetes No Virtual Machines vs. Containers Revisited - Part 4 84 84 Virtual Machines vs. Containers Revisited - Part 4 full 2fd7d32d-ea14-4213-9ac0-a1897db82ba2 https://share.transistor.fm/s/ffd19de8 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


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:


Support Mobycast:
https://glow.fm/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


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:


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


]]> Wed, 30 Oct 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3406 In episode #83 of Mobycast, we learned that containers are normal Linux processes. But they take advantage of powerful operating system functionality that gives these processes their container superpowers. In particular, we learned about namespaces and control groups and how these features give rise to containers. This week on Mobycast, Jon and Chris wrap up their four-part series by discussing the runtimes and platforms used to run containers in production. We dive deep on ContainerD and RunC, arguably the most important container runtime out there. We also revisit our pseudo code example of how to build a container from scratch, bringing us full circle on our quest to understand the differences between virtual machines and containers. In episode #83 of Mobycast, we learned that containers are normal Linux processes. But they take advantage of powerful operating system functionality that gives these processes their container superpowers. In particular, we learned about namespaces and co aws, cloud, software, software architecture, docker, containers, vms, virtual machines, hypervisors, virtualization No Virtual Machines vs. Containers Revisited - Part 3 83 83 Virtual Machines vs. Containers Revisited - Part 3 full e08ad86f-c9f3-4406-bfc8-4aecd751e7f1 https://share.transistor.fm/s/3bac1965 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 <get_pid> > /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

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:

]]> 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 <get_pid> > /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

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:

]]> Wed, 23 Oct 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3501 Containers are just lightweight virtual machines, right? No, not really. There's much more to the story than that, so we decided to do a four-part series on virtual machines versus containers. In parts 1 and 2, we discussed virtual machines in detail and how they work. Now, in parts 3 and 4, we turn our attention to containers. Turns out, containers are not very complicated. They are just normal Linux processes with some isolation superpowers. In today's episode of Mobycast, Jon and Chris go into depth on containers, their history and the underlying operating system technologies that make them possible. If you ever wondered why you can't run Windows containers on a Linux host, this episode will clear up the mystery. Containers are just lightweight virtual machines, right? No, not really. There's much more to the story than that, so we decided to do a four-part series on virtual machines versus containers. In parts 1 and 2, we discussed virtual machines in detail a aws, cloud, software, software architecture, docker, containers, vms, virtual machines, hypervisors, virtualization No Virtual Machines vs. Containers Revisited - Part 2 82 82 Virtual Machines vs. Containers Revisited - Part 2 full 97344372-0e08-471f-a49d-0f84683f304d https://share.transistor.fm/s/89625545 Sponsors


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


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:

]]> Sponsors


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


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:

]]> Wed, 16 Oct 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 2971 Cloud computing would not be possible if not for virtual machines. They are the fundamental resource for cloud-native applications. Then along came Docker with its containers, and the virtualization scene got a bit more complicated and confusing. So, we kicked off a new series where we go deep on virtual machines and containers, aiming to clear up any confusion between these important technologies. In episode #81 of Mobycast, we discussed full virtualization, also known as virtual machines. We explained hypervisors, the fundamental technology that enables virtual machines. And then we took a detailed look at how Type 1 hypervisors work. In today's episode of Mobycast, Jon and Chris bring these concepts to life by examining several popular hypervisor implementations. Cloud computing would not be possible if not for virtual machines. They are the fundamental resource for cloud-native applications. Then along came Docker with its containers, and the virtualization scene got a bit more complicated and confusing. So, w AWS, Amazon Web Service, Docker, containerization, virtual machine, VM, containers, hypervisor, KVM, Hyper-V, Xen No Virtual Machines vs. Containers Revisited - Part 1 81 81 Virtual Machines vs. Containers Revisited - Part 1 full 4726c2f4-d860-4321-b55a-bc2a1f2355e9 https://share.transistor.fm/s/1d9185b8 Sponsor


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

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:

]]> Sponsor


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

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:

]]> Wed, 09 Oct 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 2878 Back in January 2018, Jon, Rich and Chris were having lunch together in Denver. The subject of virtualization came up, and Rich said he was confused on the difference between containers and virtual machines. As we answered Rich's question, we realized that explaining a complicated technical concept in a straight-forward manner would make for a great podcast format. And thus the idea of Mobycast was formed. When we first discussed "Virtual Machines vs. Containers" in episode 1, we got most of it right, but there were some inconsistencies and holes. We didn't prepare as well as we should have for that first episode, and frankly, it shows. Now, more than 80 episodes later, we have learned a lot and expect more of ourselves. So, it's time for a "do over" on episode 1. In this episode of Mobycast, Jon and Chris kick off a four-part series on virtual machines, containers and how they compare. We revisit this important subject to fill in the gaps, and dive a whole LOT deeper this time around. Back in January 2018, Jon, Rich and Chris were having lunch together in Denver. The subject of virtualization came up, and Rich said he was confused on the difference between containers and virtual machines. As we answered Rich's question, we realized tha aws, cloud, software, software architecture, docker, containers, vms, virtual machines, hypervisors, virtualization No Are You Well Architected? The Well-Architected Framework - Part 3 80 80 Are You Well Architected? The Well-Architected Framework - Part 3 full 6c7ed266-9bbb-4a07-8ece-279d4c0b2de7 https://share.transistor.fm/s/0dca16dd Sponsor


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

Whitepapers


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:


]]> Sponsor


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

Whitepapers


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:


]]> Wed, 02 Oct 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3313 Previously on Mobycast... In episodes #78 and #79, we broke down the AWS Well-Architected Framework, and covered the first three pillars of excellence: "Operational Excellence", "Security" and "Reliability". This week on Mobycast, Jon and Chris wrap up their three-part series and discuss the last two pillars of excellence, "Performance Efficiency" and "Cost Optimization". We then bring it all together by explaining how to perform a Well-Architected Review. Spoiler alert: the Well-Architected Tool is a fabulous resource that you need to have in your toolkit. Previously on Mobycast... In episodes #78 and #79, we broke down the AWS Well-Architected Framework, and covered the first three pillars of excellence: "Operational Excellence", "Security" and "Reliability". This week on Mobycast, Jon and Chris wrap up aws, cloud, software, software architecture, sre, well architected framework No Are You Well Architected? The Well-Architected Framework - Part 2 79 79 Are You Well Architected? The Well-Architected Framework - Part 2 full c80ecae9-81fc-4966-9c85-5bdf2140aa60 https://share.transistor.fm/s/959e2c16 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

Whitepapers


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:

]]> 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

Whitepapers


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:

]]> Wed, 25 Sep 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3880 In episode #78 of Mobycast, we introduced the AWS Well-Architected Framework, an indispensable resource of best practices when running workloads in the cloud. We explained that the framework defines five pillars of excellence, and we dug deep on the first pillar, "Operational Excellence". If you missed that episode, hit pause now and go listen to that one first. It's ok, we'll wait for you. Now, in this episode of Mobycast, Jon and Chris continue their three-part series on the AWS Well-Architected Framework and discuss the next two pillars of excellence: "Security" and "Reliability". In episode #78 of Mobycast, we introduced the AWS Well-Architected Framework, an indispensable resource of best practices when running workloads in the cloud. We explained that the framework defines five pillars of excellence, and we dug deep on the first aws, cloud, software, software architecture, sre, well architected framework No Are You Well Architected? The Well-Architected Framework - Part 1 78 78 Are You Well Architected? The Well-Architected Framework - Part 1 full 07210dc9-f438-49c9-9817-bec1e74ede54 https://share.transistor.fm/s/83cc731b 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

Whitepapers


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:

]]> 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

Whitepapers


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:

]]> Wed, 18 Sep 2019 13:00:00 +0000 Mobycast.fm Mobycast.fm 3320 Just as the Twelve-Factor App methodology was born from real world experience of deploying successful apps at Heroku, architects at AWS created the Well-Architected Framework to document best practices they observed when running workloads in the cloud. Originally announced as a whitepaper in October 2015, the Well-Architected Framework got center stage treatment at re:Invent 2016 during Werner Vogels' keynote address. Since then, it has evolved to become an indispensable resource when building and running workloads in AWS. But the Well-Architected Framework is massive, consisting of 6 core whitepapers that total over 400 pages. It would be easy to dismiss it as just another boring set of documents. But doing so would be a big mistake. There is a lot of gold to be found if you are willing to do some digging. In this episode of Mobycast, Jon and Chris kick off a three-part series where we grab our shovels and dig deep into the Well-Architected Framework and explain how you can best take advantage of this important resource. Just as the Twelve-Factor App methodology was born from real world experience of deploying successful apps at Heroku, architects at AWS created the Well-Architected Framework to document best practices they observed when running workloads in the cloud. aws, cloud, software, software architecture, sre, well architected framework No The Twelve-Factor App: 12 Best Practices for Microservices 77 77 The Twelve-Factor App: 12 Best Practices for Microservices full 87f6ec4d-df28-4faf-baec-33d9debd6b03 https://share.transistor.fm/s/7d279f2b
  • 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:



    ]]>
  • 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:



    ]]>     Wed, 11 Sep 2019 07:00:00 +0000 Mobycast.fm Mobycast.fm 3104 The 12 factor app methodology was created by developers at Heroku after their experience working with hundreds of thousands of apps on the Heroku platform. They noticed that successful apps shared a core set of things in common. First published in 2012, the 12 Factor App attempts to distill these commonalities into 12 principals. But the 12 Factor App is now over 7 years old which is several lifetimes in the technology world. Is it still applicable to today’s modern, cloud-native applications? In this episode of Mobycast, Jon and Chris go through the 12 factors explaining each one in detail and debating its relevance to today’s cloud-native applications. The 12 factor app methodology was created by developers at Heroku after their experience working with hundreds of thousands of apps on the Heroku platform. They noticed that successful apps shared a core set of things in common. First published in 2012, t software, aws, cloud No     An Encryption Deep Dive - Part Four 76 76 An Encryption Deep Dive - Part Four full https://mobycast.castos.com/podcasts/44/episodes/an-encryption-deep-dive-part-four-1 https://share.transistor.fm/s/66554a69 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.

    ]]>     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.

    ]]>     Wed, 04 Sep 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 3156 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. 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. aws, cloud, software, development, programming No     An Encryption Deep Dive - Part Three 75 75 An Encryption Deep Dive - Part Three full 87eae491-5aca-4deb-a6e9-5627020fd14e https://share.transistor.fm/s/1782fbb3 In Episode 75 of Mobycast, we continue with part three of our series on encryption. In particular, we discuss end-to-end encryption in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 75 of Mobycast, we continue with part three of our series on encryption. In particular, we discuss end-to-end encryption in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 28 Aug 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1963 In Episode 75 of Mobycast, we continue with part three of our series on encryption. In particular, we discuss end-to-end encryption in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 75 of Mobycast, we continue with part three of our series on encryption. In particular, we discuss end-to-end encryption in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed syste aws, cloud, software, development, programming No     An Encryption Deep Dive - Part Two 74 74 An Encryption Deep Dive - Part Two full 13be8dd8-88d9-4e6e-8f47-ee71626c35cb https://share.transistor.fm/s/c038eb01 In episode 74 of Mobycast, we continue with part two of our series on encryption. In particular, we'll discuss Transport Layer Security in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 74 of Mobycast, we continue with part two of our series on encryption. In particular, we'll discuss Transport Layer Security in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 21 Aug 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 2204 In episode 74 of Mobycast, we continue with part two of our series on encryption. In particular, we'll discuss Transport Layer Security in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 74 of Mobycast, we continue with part two of our series on encryption. In particular, we'll discuss Transport Layer Security in practice. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed s aws, cloud, software, development, programming No     An Encryption Deep Dive - Part One 73 73 An Encryption Deep Dive - Part One full 6b65d7af-fc6c-4aea-9fe9-82c7ff2224d9 https://share.transistor.fm/s/5b2e1e08 In episode 73 of Mobycast, we start a new series on encryption and dive into the essentials. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 73 of Mobycast, we start a new series on encryption and dive into the essentials. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 14 Aug 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 2543 In episode 73 of Mobycast, we start a new series on encryption and dive into the essentials. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 73 of Mobycast, we start a new series on encryption and dive into the essentials. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Growth Hacking for Remote and International Developers - Part 2 72 72 Growth Hacking for Remote and International Developers - Part 2 full 052db150-ab36-432e-9f00-17076867dc97 https://share.transistor.fm/s/8a98769e In Episode 72 of Mobycast, we dive into part two of our discussion on growing high performing remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 72 of Mobycast, we dive into part two of our discussion on growing high performing remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 07 Aug 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 2563 In Episode 72 of Mobycast, we dive into part two of our discussion on growing high performing remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 72 of Mobycast, we dive into part two of our discussion on growing high performing remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Growth Hacking for Remote and International Developers - Part 1 71 71 Growth Hacking for Remote and International Developers - Part 1 full c6498b92-5208-4521-94b4-907374e010b1 https://share.transistor.fm/s/267fe138 In episode 71 of Mobycast, Jon and Chris discuss lessons learned while working with remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 71 of Mobycast, Jon and Chris discuss lessons learned while working with remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 31 Jul 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 1820 In episode 71 of Mobycast, Jon and Chris discuss lessons learned while working with remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 71 of Mobycast, Jon and Chris discuss lessons learned while working with remote and international engineering teams. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Microservices Bootcamp 3 - Micro Frontends 70 70 Microservices Bootcamp 3 - Micro Frontends full 92e21bf3-827e-4df3-8d70-c74afd43b3f8 https://share.transistor.fm/s/f5a52ce1 In Episode 70 of Mobycast, we wrap up our bootcamp on Microservices with the discussion on Micro Frontends. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 70 of Mobycast, we wrap up our bootcamp on Microservices with the discussion on Micro Frontends. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 24 Jul 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 2235 In Episode 70 of Mobycast, we wrap up our bootcamp on Microservices with the discussion on Micro Frontends. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 70 of Mobycast, we wrap up our bootcamp on Microservices with the discussion on Micro Frontends. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Microservices Part 2: Sizing, Decomposition, and Dismantling the Monolith 69 69 Microservices Part 2: Sizing, Decomposition, and Dismantling the Monolith full d3ae5747-c9a4-46cb-bf16-aedfd7bcccce https://share.transistor.fm/s/bf1fdd98 In Episode 69 of Mobycast, we get hands-on with part two of our Microservices bootcamp and discuss sizing, decomposition, and dismantling monolith. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 69 of Mobycast, we get hands-on with part two of our Microservices bootcamp and discuss sizing, decomposition, and dismantling monolith. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Thu, 18 Jul 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 2493 In Episode 69 of Mobycast, we get hands-on with part two of our Microservices bootcamp and discuss sizing, decomposition, and dismantling monolith. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 69 of Mobycast, we get hands-on with part two of our Microservices bootcamp and discuss sizing, decomposition, and dismantling monolith. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed sy aws, cloud, software, development, programming No     Microservices Boot Camp Part 1 68 68 Microservices Boot Camp Part 1 full 36bf2ed8-d8c5-40ba-97a0-57748fc4b1fa https://share.transistor.fm/s/2e2c82e1 In episode 68 of Mobycast, Jon and Chris kick off part one of our Microservices bootcamp, answering the essential questions of what, why, and how. Welcome to Mobycast, a weekly conversation about Cloud native development, AWS, and building distributed systems.

    ]]>     In episode 68 of Mobycast, Jon and Chris kick off part one of our Microservices bootcamp, answering the essential questions of what, why, and how. Welcome to Mobycast, a weekly conversation about Cloud native development, AWS, and building distributed systems.

    ]]>     Wed, 10 Jul 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 2232 In episode 68 of Mobycast, Jon and Chris kick off part one of our Microservices bootcamp, answering the essential questions of what, why, and how. Welcome to Mobycast, a weekly conversation about Cloud native development, AWS, and building distributed systems. In episode 68 of Mobycast, Jon and Chris kick off part one of our Microservices bootcamp, answering the essential questions of what, why, and how. Welcome to Mobycast, a weekly conversation about Cloud native development, AWS, and building distributed sys aws, cloud, software, development, programming No     Real World AWS - Using Custom CloudWatch Metrics to Monitor Disk Space 67 67 Real World AWS - Using Custom CloudWatch Metrics to Monitor Disk Space full 24713c88-b2d3-4c57-8834-a178838602cf https://share.transistor.fm/s/f7c28c1d In Episode 67 of Mobycast, Jon and Chris discuss using custom CloudWatch metrics to monitor disk space. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 67 of Mobycast, Jon and Chris discuss using custom CloudWatch metrics to monitor disk space. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 03 Jul 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 2133 In Episode 67 of Mobycast, Jon and Chris discuss using custom CloudWatch metrics to monitor disk space. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 67 of Mobycast, Jon and Chris discuss using custom CloudWatch metrics to monitor disk space. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Using Feature Flags to Increase Velocity and Decrease Risk in a Modern CI:CD Delivery Pipeline 66 66 Using Feature Flags to Increase Velocity and Decrease Risk in a Modern CI:CD Delivery Pipeline full 19711740-b87b-4c5a-8c50-1117b5de812e https://share.transistor.fm/s/e11810dc In Episode 66 of Mobycast, Jon and Chris discuss using feature flags to increase velocity and decrease risk in your CI/CD pipeline. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 66 of Mobycast, Jon and Chris discuss using feature flags to increase velocity and decrease risk in your CI/CD pipeline. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 26 Jun 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1904 In Episode 66 of Mobycast, Jon and Chris discuss using feature flags to increase velocity and decrease risk in your CI/CD pipeline. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 66 of Mobycast, Jon and Chris discuss using feature flags to increase velocity and decrease risk in your CI/CD pipeline. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Practical AWS - Hosting a Personal Blog the Hard Way, Then the Easy Way 65 65 Practical AWS - Hosting a Personal Blog the Hard Way, Then the Easy Way full 87cfb53f-4d9e-476e-be52-6334334ea8f9 https://share.transistor.fm/s/4a3ee6d5 In Episode 65 of Mobycast, Chris walks us through the setup of his personal blog using Ghost. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 65 of Mobycast, Chris walks us through the setup of his personal blog using Ghost. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 19 Jun 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1806 In Episode 65 of Mobycast, Chris walks us through the setup of his personal blog using Ghost. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 65 of Mobycast, Chris walks us through the setup of his personal blog using Ghost. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Post Gluecon Thoughts and How Aurora Serverless Works 64 64 Post Gluecon Thoughts and How Aurora Serverless Works full 34ea769a-39d9-4cab-b2be-50c7efc434d3 https://share.transistor.fm/s/ab25421d In Episode 64 of Mobycast, Jon shares his thoughts on Gluecon 2019 and then dives into one of his favorite sessions which focused on AWS’ Aurora Serverless. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 64 of Mobycast, Jon shares his thoughts on Gluecon 2019 and then dives into one of his favorite sessions which focused on AWS’ Aurora Serverless. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 12 Jun 2019 12:04:00 +0000 Mobycast.fm Mobycast.fm 1865 In Episode 64 of Mobycast, Jon shares his thoughts on Gluecon 2019 and then dives into one of his favorite sessions which focused on AWS’ Aurora Serverless. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 64 of Mobycast, Jon shares his thoughts on Gluecon 2019 and then dives into one of his favorite sessions which focused on AWS’ Aurora Serverless. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distr aws, cloud, software, development, programming No     Service-to-Service Authentication for Microservice APIs 63 63 Service-to-Service Authentication for Microservice APIs full a0ceb940-08f1-4bd7-b94b-90a8eed22a50 https://share.transistor.fm/s/df22b3bb In Episode 63 of Mobycast, Jon and Chris discuss service-to-service authentication for microservice APIs. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 63 of Mobycast, Jon and Chris discuss service-to-service authentication for microservice APIs. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 05 Jun 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 2577 In Episode 63 of Mobycast, Jon and Chris discuss service-to-service authentication for microservice APIs. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 63 of Mobycast, Jon and Chris discuss service-to-service authentication for microservice APIs. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Practical Istio (A Dockercon 2019 Recap) 62 62 Practical Istio (A Dockercon 2019 Recap) full 22e64d92-a9a0-43c9-ae3d-8c0915687185 https://share.transistor.fm/s/6afc4486 In episode 62 of Mobycast, we recap another DockerCon 2019 session. This one focuses on Practical Istio by Zack Butcher. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 62 of Mobycast, we recap another DockerCon 2019 session. This one focuses on Practical Istio by Zack Butcher. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 29 May 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 2036 In episode 62 of Mobycast, we recap another DockerCon 2019 session. This one focuses on Practical Istio by Zack Butcher. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 62 of Mobycast, we recap another DockerCon 2019 session. This one focuses on Practical Istio by Zack Butcher. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Just What is a "Service Mesh", and If I Get One Will It Make Everything OK? (A Dockercon 2019 Recap) 61 61 Just What is a "Service Mesh", and If I Get One Will It Make Everything OK? (A Dockercon 2019 Recap) full 6b130035-3261-4daf-b4ed-5e0dcfabd4ef https://share.transistor.fm/s/b8471019 In episode 61 of Mobycast, we recap another DockerCon 2019 session titled "Just What Is A 'Server Mesh,' And If I Get One Will It Make Everything OK?" by Elton Stoneman. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 61 of Mobycast, we recap another DockerCon 2019 session titled "Just What Is A 'Server Mesh,' And If I Get One Will It Make Everything OK?" by Elton Stoneman. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 22 May 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1844 In episode 61 of Mobycast, we recap another DockerCon 2019 session titled "Just What Is A 'Server Mesh,' And If I Get One Will It Make Everything OK?" by Elton Stoneman. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 61 of Mobycast, we recap another DockerCon 2019 session titled "Just What Is A 'Server Mesh,' And If I Get One Will It Make Everything OK?" by Elton Stoneman. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and b aws, cloud, software, development, programming No     Node.js Rocks in Docker for Dev and Ops (Part 2) 60 60 Node.js Rocks in Docker for Dev and Ops (Part 2) full 86619687-8f49-45a6-982e-18f11f653bb8 https://share.transistor.fm/s/fa737cf4 In episode 60 of Mobycast, we conclude our series on Bret Fisher's DockerCon session, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 60 of Mobycast, we conclude our series on Bret Fisher's DockerCon session, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 15 May 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1905 In episode 60 of Mobycast, we conclude our series on Bret Fisher's DockerCon session, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 60 of Mobycast, we conclude our series on Bret Fisher's DockerCon session, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Node.js Rocks in Docker for Dev and Ops (A Dockercon 2019 Recap) 59 59 Node.js Rocks in Docker for Dev and Ops (A Dockercon 2019 Recap) full 11d390d8-ddbc-452a-be9c-9cffb5d95060 https://share.transistor.fm/s/33fb9b9e In Episode 59 of Mobycast, Jon and Chris break down Bret Fisher’s DockerCon 2019 session which was titled, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 59 of Mobycast, Jon and Chris break down Bret Fisher’s DockerCon 2019 session which was titled, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 08 May 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1544 In Episode 59 of Mobycast, Jon and Chris break down Bret Fisher’s DockerCon 2019 session which was titled, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 59 of Mobycast, Jon and Chris break down Bret Fisher’s DockerCon 2019 session which was titled, Node.js Rocks in Docker for Dev and Ops. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed sy aws, cloud, software, development, programming No     Practical Issues with RDS Replicas 58 58 Practical Issues with RDS Replicas full 4f0a447f-1244-4584-8924-30614f490897 https://share.transistor.fm/s/507a126d In episode 58 of Mobycast, Jon and Chris discuss the practical issues with RDS replicas. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 58 of Mobycast, Jon and Chris discuss the practical issues with RDS replicas. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 01 May 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1423 In episode 58 of Mobycast, Jon and Chris discuss the practical issues with RDS replicas. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 58 of Mobycast, Jon and Chris discuss the practical issues with RDS replicas. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     DockerCon 2019 - A Preview Show 57 57 DockerCon 2019 - A Preview Show full b72e3c63-52b7-4d51-94bb-241d716b428b https://share.transistor.fm/s/4c120558 In episode 57 of Mobycast, we look ahead towards DockerCon 2019, discuss what to expect and throw down a few predictions. Welcome to Mobycast, a weekly conversation about cloud native development, AWS, and building distributed systems.

    ]]>     In episode 57 of Mobycast, we look ahead towards DockerCon 2019, discuss what to expect and throw down a few predictions. Welcome to Mobycast, a weekly conversation about cloud native development, AWS, and building distributed systems.

    ]]>     Wed, 24 Apr 2019 12:07:00 +0000 Mobycast.fm Mobycast.fm 1467 In episode 57 of Mobycast, we look ahead towards DockerCon 2019, discuss what to expect and throw down a few predictions. Welcome to Mobycast, a weekly conversation about cloud native development, AWS, and building distributed systems. In episode 57 of Mobycast, we look ahead towards DockerCon 2019, discuss what to expect and throw down a few predictions. Welcome to Mobycast, a weekly conversation about cloud native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     How to Become a Great Software Developer (Part 2) 56 56 How to Become a Great Software Developer (Part 2) full dae373bd-6dd7-48e5-b8a3-b70b91f0cb84 https://share.transistor.fm/s/30a9619c In Episode 56 of Mobycast, we conclude our mini series on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 56 of Mobycast, we conclude our mini series on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 17 Apr 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1420 In Episode 56 of Mobycast, we conclude our mini series on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 56 of Mobycast, we conclude our mini series on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     How to Become a Great Software Developer (Part 1) 55 55 How to Become a Great Software Developer (Part 1) full 175dd2a9-a4c9-4073-9468-c6c14d766568 https://share.transistor.fm/s/fab18f38 In Episode 55 of Mobycast, we start a new miniseries on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 55 of Mobycast, we start a new miniseries on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 10 Apr 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1818 In Episode 55 of Mobycast, we start a new miniseries on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 55 of Mobycast, we start a new miniseries on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     DNS 101 54 54 DNS 101 full 6e488e0c-811f-4891-9eb7-324ff237fae1 https://share.transistor.fm/s/57e2923c In Episode 54 of Mobycast, Jon and Chris teach a primer on DNS and explain exactly what happens when you type the URL into the browser. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In Episode 54 of Mobycast, Jon and Chris teach a primer on DNS and explain exactly what happens when you type the URL into the browser. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 03 Apr 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1531 In Episode 54 of Mobycast, Jon and Chris teach a primer on DNS and explain exactly what happens when you type the URL into the browser. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In Episode 54 of Mobycast, Jon and Chris teach a primer on DNS and explain exactly what happens when you type the URL into the browser. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. aws, cloud, software, development, programming No     Health Checks for Services, Containers and Daemons 53 53 Health Checks for Services, Containers and Daemons full 76fa8463-a4da-43fc-8d74-14b63a30ef0c https://share.transistor.fm/s/781cbd0b Wed, 27 Mar 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1784 In episode 53 of Mobycast, Jon and Chris discuss health checks for services, containers,  and daemons. Welcome to Mobycast, a weekly conversation about cloud-native development,  AWS, and building distributed systems. In episode 53 of Mobycast, Jon and Chris discuss health checks for services, containers,  and daemons. Welcome to Mobycast, a weekly conversation about cloud-native development,  AWS, and building distributed systems. aws, cloud, software, development, programming No Real World Architecture in the Cloud Using Event-Driven Techniques to Build a PDF Rendering Pipeline 52 52 Real World Architecture in the Cloud Using Event-Driven Techniques to Build a PDF Rendering Pipeline full b01284b6-fcee-45d4-87db-e76b2b28ccc7 https://share.transistor.fm/s/568a7305 In episode 52 of Mobycast, we discuss a real world example of using event-driven techniques to add a new feature to an existing application. Welcome to Mobycast, a weekly conversation about cloud native developments, AWS, and building distributed systems.

    ]]>     In episode 52 of Mobycast, we discuss a real world example of using event-driven techniques to add a new feature to an existing application. Welcome to Mobycast, a weekly conversation about cloud native developments, AWS, and building distributed systems.

    ]]>     Wed, 20 Mar 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1615 In episode 52 of Mobycast, we discuss a real world example of using event-driven techniques to add a new feature to an existing application. Welcome to Mobycast, a weekly conversation about cloud native developments, AWS, and building distributed systems. In episode 52 of Mobycast, we discuss a real world example of using event-driven techniques to add a new feature to an existing application. Welcome to Mobycast, a weekly conversation about cloud native developments, AWS, and building distributed systems. aws, cloud, software, development, programming No     Evolve or Die - The Importance of Continuous Learning 51 51 Evolve or Die - The Importance of Continuous Learning full b725be23-4756-4c99-b0be-8342b5e57d00 https://share.transistor.fm/s/d71921ad In episode 51 of Mobycast, we talk about the importance of continuous learning for both the software developer as well as the organization in general. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     In episode 51 of Mobycast, we talk about the importance of continuous learning for both the software developer as well as the organization in general. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems.

    ]]>     Wed, 13 Mar 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1515 In episode 51 of Mobycast, we talk about the importance of continuous learning for both the software developer as well as the organization in general. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. In episode 51 of Mobycast, we talk about the importance of continuous learning for both the software developer as well as the organization in general. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed aws, cloud, software, development, programming No     Open Source Tension - Who Should Profit? 50 50 Open Source Tension - Who Should Profit? full 90f19bb7-9362-4c97-b4b2-fd7e525932cd https://share.transistor.fm/s/ca51b97f In Episode 50 of Mobycast, we discuss the tension between creators of open-source projects and those that use the software commercially. Welcome to Mobycast, a weekly conversation about cloud-native development.

    ]]>     In Episode 50 of Mobycast, we discuss the tension between creators of open-source projects and those that use the software commercially. Welcome to Mobycast, a weekly conversation about cloud-native development.

    ]]>     Wed, 06 Mar 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 2097 In Episode 50 of Mobycast, we discuss the tension between creators of open-source projects and those that use the software commercially. Welcome to Mobycast, a weekly conversation about cloud-native development. In Episode 50 of Mobycast, we discuss the tension between creators of open-source projects and those that use the software commercially. Welcome to Mobycast, a weekly conversation about cloud-native development. aws, cloud, software, development, programming No     Building RESTful APIs (Part 2) 49 49 Building RESTful APIs (Part 2) full 46fa7d67-edf3-4f64-9710-b9ef9acc837c https://share.transistor.fm/s/166a089f In episode 49 of Mobycast, we continue our conversation on building RESTful APIs. In particular, we discuss authentication and error handling. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 49 of Mobycast, we continue our conversation on building RESTful APIs. In particular, we discuss authentication and error handling. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 27 Feb 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 2530 In episode 49 of Mobycast, we continue our conversation on building RESTful APIs. In particular, we discuss authentication and error handling. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 49 of Mobycast, we continue our conversation on building RESTful APIs. In particular, we discuss authentication and error handling. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Microservice RESTful APIs - Tips & Guidelines for Crafting Beautiful, Simple APIs 48 48 Microservice RESTful APIs - Tips & Guidelines for Crafting Beautiful, Simple APIs full a94b2956-c91f-426d-97c0-23dcd268788f https://share.transistor.fm/s/d2232c9b In Episode 48 of Mobycast, we discuss tips and guidelines for creating beautiful simple APIs. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 48 of Mobycast, we discuss tips and guidelines for creating beautiful simple APIs. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 20 Feb 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1194 In Episode 48 of Mobycast, we discuss tips and guidelines for creating beautiful simple APIs. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 48 of Mobycast, we discuss tips and guidelines for creating beautiful simple APIs. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     Evaluating AWS Cognito For Your Architecture 47 47 Evaluating AWS Cognito For Your Architecture full 63792422-9b28-45b4-843e-af575e1b8a8b https://share.transistor.fm/s/fa1a66fd In episode 47 of Mobycast, we take a high level look at AWS Cognito and discuss when it's a good option for your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 47 of Mobycast, we take a high level look at AWS Cognito and discuss when it's a good option for your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 13 Feb 2019 12:05:00 +0000 Mobycast.fm Mobycast.fm 1120 In episode 47 of Mobycast, we take a high level look at AWS Cognito and discuss when it's a good option for your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 47 of Mobycast, we take a high level look at AWS Cognito and discuss when it's a good option for your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Revisiting the Serverless Holy War 46 46 Revisiting the Serverless Holy War full c54849aa-e849-4cf8-baa3-c9ba5e8490a1 https://share.transistor.fm/s/beb31a83 In episode 46 of Mobycast, we revisit the holy war of serverless API development, whether or not it's a good idea for real-load projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 46 of Mobycast, we revisit the holy war of serverless API development, whether or not it's a good idea for real-load projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 06 Feb 2019 12:15:00 +0000 Mobycast.fm Mobycast.fm 1503 In episode 46 of Mobycast, we revisit the holy war of serverless API development, whether or not it's a good idea for real-load projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 46 of Mobycast, we revisit the holy war of serverless API development, whether or not it's a good idea for real-load projects. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Serverless Made More Modular - Lambda Layers and Runtime API 45 45 Serverless Made More Modular - Lambda Layers and Runtime API full 92b7de07-544f-42b9-b06b-659207666fb0 https://share.transistor.fm/s/ea66c69a In episode 45 of Mobycast, we discuss Lambda Layers, the Runtime API, and how to make serverless more modular. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 45 of Mobycast, we discuss Lambda Layers, the Runtime API, and how to make serverless more modular. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 30 Jan 2019 12:15:00 +0000 Mobycast.fm Mobycast.fm 3075 In episode 45 of Mobycast, we discuss Lambda Layers, the Runtime API, and how to make serverless more modular. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 45 of Mobycast, we discuss Lambda Layers, the Runtime API, and how to make serverless more modular. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     The Birth of NoSQL and DynamoDB - Part 5 43 43 The Birth of NoSQL and DynamoDB - Part 5 full 45880e7e-e728-4f21-810a-5bc435095c97 https://share.transistor.fm/s/1a15e944 In episode 43 of Mobycast, we conclude our series on the birth of NoSQL and DynamoDB. In particular, we take a deeper look at Leviathan, the NoSQL database created by Chris’ startup in the late 90s and we compare it to DynamoDB today. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 43 of Mobycast, we conclude our series on the birth of NoSQL and DynamoDB. In particular, we take a deeper look at Leviathan, the NoSQL database created by Chris’ startup in the late 90s and we compare it to DynamoDB today. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 23 Jan 2019 12:15:00 +0000 Mobycast.fm Mobycast.fm 1970 In episode 43 of Mobycast, we conclude our series on the birth of NoSQL and DynamoDB. In particular, we take a deeper look at Leviathan, the NoSQL database created by Chris’ startup in the late 90s and we compare it to DynamoDB today. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 43 of Mobycast, we conclude our series on the birth of NoSQL and DynamoDB. In particular, we take a deeper look at Leviathan, the NoSQL database created by Chris’ startup in the late 90s and we compare it to DynamoDB today. Welcome to Mobycast, aws, cloud, software, development, programming No     AWS Launches DocumentDB - Should Mongo Be Worried? 44 44 AWS Launches DocumentDB - Should Mongo Be Worried? full 25b2722f-8860-4f40-a206-19ffdc0ee731 https://share.transistor.fm/s/b043dbb7 In episode 44 of Mobycast, we discuss AWS's launch of DocumentDB, and whether or not Mongo should be worried.

    ]]>     In episode 44 of Mobycast, we discuss AWS's launch of DocumentDB, and whether or not Mongo should be worried.

    ]]>     Wed, 16 Jan 2019 12:01:00 +0000 Mobycast.fm Mobycast.fm 2194 In episode 44 of Mobycast, we discuss AWS's launch of DocumentDB, and whether or not Mongo should be worried. In episode 44 of Mobycast, we discuss AWS's launch of DocumentDB, and whether or not Mongo should be worried. aws, cloud, software, development, programming No     The Birth of NoSQL and Dynamo DB - Part 4 42 42 The Birth of NoSQL and Dynamo DB - Part 4 full 23add968-ab0f-4645-b9a2-2d93c622aeaf https://share.transistor.fm/s/0389ec77 In episode 42 of Mobycast, we continue our conversation on DynamoDB, this time diving deep into its architecture and components. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 42 of Mobycast, we continue our conversation on DynamoDB, this time diving deep into its architecture and components. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 09 Jan 2019 12:00:00 +0000 Mobycast.fm Mobycast.fm 1869 In episode 42 of Mobycast, we continue our conversation on DynamoDB, this time diving deep into its architecture and components. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 42 of Mobycast, we continue our conversation on DynamoDB, this time diving deep into its architecture and components. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     The Birth of NoSQL and DynamoDB - Part 3 41 41 The Birth of NoSQL and DynamoDB - Part 3 full ab6af5ab-69db-44dc-9674-029838d1b4e7 https://share.transistor.fm/s/06a5fffc In episode 41 of Mobycast, we continue our conversation on the birth of NoSQL and DynamoDB. In particular, we pull back the covers on DynamoDB, examine its architecture and discuss why it’s such a popular solution for internet-scale databases.

    ]]>     In episode 41 of Mobycast, we continue our conversation on the birth of NoSQL and DynamoDB. In particular, we pull back the covers on DynamoDB, examine its architecture and discuss why it’s such a popular solution for internet-scale databases.

    ]]>     Wed, 02 Jan 2019 12:00:00 +0000 Mobycast.fm Mobycast.fm 1232 In episode 41 of Mobycast, we continue our conversation on the birth of NoSQL and DynamoDB. In particular, we pull back the covers on DynamoDB, examine its architecture and discuss why it’s such a popular solution for internet-scale databases. In episode 41 of Mobycast, we continue our conversation on the birth of NoSQL and DynamoDB. In particular, we pull back the covers on DynamoDB, examine its architecture and discuss why it’s such a popular solution for internet-scale databases. aws, cloud, software, development, programming No     The Birth of NoSQL and DynamoDB - Part 2 40 40 The Birth of NoSQL and DynamoDB - Part 2 full eb8ef05f-728e-4c07-a0cb-9fbccbb0e817 https://share.transistor.fm/s/a8b258c8 In episode 40 of Mobycast, we learn about Chris's first venture-backed  startup circa 1998 and their goal to build a database for internet scale applications. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 40 of Mobycast, we learn about Chris's first venture-backed  startup circa 1998 and their goal to build a database for internet scale applications. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 26 Dec 2018 12:10:00 +0000 Mobycast.fm Mobycast.fm 1589 In episode 40 of Mobycast, we learn about Chris's first venture-backed  startup circa 1998 and their goal to build a database for internet scale applications. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 40 of Mobycast, we learn about Chris's first venture-backed  startup circa 1998 and their goal to build a database for internet scale applications. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software d aws, cloud, software, development, programming No     The Birth of NoSQL and DynamoDB - Part 1 39 39 The Birth of NoSQL and DynamoDB - Part 1 full ca6edee2-f851-4734-8d20-159605f522cd https://share.transistor.fm/s/1c623c3a In episode 39 of Mobycast, we lead a history lesson on the unique challenges of data at "internet scale" and how this gave rise to NoSQL.

    ]]>     In episode 39 of Mobycast, we lead a history lesson on the unique challenges of data at "internet scale" and how this gave rise to NoSQL.

    ]]>     Wed, 19 Dec 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1650 In episode 39 of Mobycast, we lead a history lesson on the unique challenges of data at "internet scale" and how this gave rise to NoSQL. In episode 39 of Mobycast, we lead a history lesson on the unique challenges of data at "internet scale" and how this gave rise to NoSQL. aws, cloud, software, development, programming No     When (and When Not) to use Open Source Libraries 38 38 When (and When Not) to use Open Source Libraries full 1db3e7d1-3ecb-4d38-a6de-a0b442729d71 https://share.transistor.fm/s/d8692be5 In episode 38 of Mobycast, we discuss when and when not to use open source libraries in your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In episode 38 of Mobycast, we discuss when and when not to use open source libraries in your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 12 Dec 2018 12:05:00 +0000 Mobycast.fm Mobycast.fm 1836 In episode 38 of Mobycast, we discuss when and when not to use open source libraries in your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In episode 38 of Mobycast, we discuss when and when not to use open source libraries in your projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     The Path to AWS Certification 37 37 The Path to AWS Certification full c81cb49d-e1d0-4e12-ad64-c7e522803171 https://share.transistor.fm/s/40a501f1 In episode 37 of Mobycast, we discuss the process of becoming AWS certified. Including a few tips on how to prepare and pass the exam. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In episode 37 of Mobycast, we discuss the process of becoming AWS certified. Including a few tips on how to prepare and pass the exam. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 05 Dec 2018 12:07:00 +0000 Mobycast.fm Mobycast.fm 1899 In episode 37 of Mobycast, we discuss the process of becoming AWS certified. Including a few tips on how to prepare and pass the exam. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In episode 37 of Mobycast, we discuss the process of becoming AWS certified. Including a few tips on how to prepare and pass the exam. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     Preparing for Re:Invent 2018 36 36 Preparing for Re:Invent 2018 full 6d0e05d8-244e-42bc-9cf8-4e4363879bc9 https://share.transistor.fm/s/7b05d276 In episode 36 of Mobycast, we look ahead to re:Invent 2018, discuss what to expect as well as offer a few practical tips to get the most value. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In episode 36 of Mobycast, we look ahead to re:Invent 2018, discuss what to expect as well as offer a few practical tips to get the most value. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 14 Nov 2018 12:11:00 +0000 Mobycast.fm Mobycast.fm 2619 In episode 36 of Mobycast, we look ahead to re:Invent 2018, discuss what to expect as well as offer a few practical tips to get the most value. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In episode 36 of Mobycast, we look ahead to re:Invent 2018, discuss what to expect as well as offer a few practical tips to get the most value. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     A Mobycast Retrospective 35 35 A Mobycast Retrospective full 78d2bc72-f276-4ae7-9ef6-2c178c5a3282 https://share.transistor.fm/s/22db2c19 In episode 35 of Mobycast, we’ll talk about the original goals for this podcast and where we plan to take it in the future. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. Let’s jump right in.

    ]]>     In episode 35 of Mobycast, we’ll talk about the original goals for this podcast and where we plan to take it in the future. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. Let’s jump right in.

    ]]>     Wed, 07 Nov 2018 12:55:00 +0000 Mobycast.fm Mobycast.fm 1310 In episode 35 of Mobycast, we’ll talk about the original goals for this podcast and where we plan to take it in the future. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. Let’s jump right in. In episode 35 of Mobycast, we’ll talk about the original goals for this podcast and where we plan to take it in the future. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. Let’s jump right in. aws, cloud, software, development, programming No     Event-Driven Architecture (Part 2) 34 34 Event-Driven Architecture (Part 2) full c5ab42a1-3d50-4882-9420-4a9c45597f40 https://share.transistor.fm/s/7a7c10bf In episode 34 of Mobycast, we dive into part 2 of our micro-series on Event-Driven Architecture. In particular, we discuss a few practical examples used at Kelsus. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 34 of Mobycast, we dive into part 2 of our micro-series on Event-Driven Architecture. In particular, we discuss a few practical examples used at Kelsus. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 31 Oct 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1160 In episode 34 of Mobycast, we dive into part 2 of our micro-series on Event-Driven Architecture. In particular, we discuss a few practical examples used at Kelsus. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 34 of Mobycast, we dive into part 2 of our micro-series on Event-Driven Architecture. In particular, we discuss a few practical examples used at Kelsus. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern softw aws, cloud, software, development, programming No     Event-Driven Architecture (Part 1) 33 33 Event-Driven Architecture (Part 1) full 8c901cf6-4bb5-47ba-8670-c11a8ca57b22 https://share.transistor.fm/s/ba3fb526 In episode 33 of Mobycast, we begin a new micro-series on Event-Driven Architecture. In
    particular, we discuss the how and the why as well as the Pub/Sub design pattern. Welcome to
    Mobycast, a weekly conversation about containerization, Docker and modern software
    deployment.

    ]]>     In episode 33 of Mobycast, we begin a new micro-series on Event-Driven Architecture. In
    particular, we discuss the how and the why as well as the Pub/Sub design pattern. Welcome to
    Mobycast, a weekly conversation about containerization, Docker and modern software
    deployment.

    ]]>     Wed, 24 Oct 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1261 In episode 33 of Mobycast, we begin a new micro-series on Event-Driven Architecture. Inparticular, we discuss the how and the why as well as the Pub/Sub design pattern. Welcome toMobycast, a weekly conversation about containerization, Docker and modern softwaredeployment. In episode 33 of Mobycast, we begin a new micro-series on Event-Driven Architecture. Inparticular, we discuss the how and the why as well as the Pub/Sub design pattern. Welcome toMobycast, a weekly conversation about containerization, Docker and modern so aws, cloud, software, development, programming No     Logging A-to-Z for Containerized Microservices (Part 3) 32 32 Logging A-to-Z for Containerized Microservices (Part 3) full e13c4d2d-a9d0-457a-bd69-698eac19bb14 https://share.transistor.fm/s/c9ab5869 In Episode 32 of Mobycast, we finished our series on application logging. In particular, we discuss how Kelsus leverages Sumo Logic to manage the logs of their projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 32 of Mobycast, we finished our series on application logging. In particular, we discuss how Kelsus leverages Sumo Logic to manage the logs of their projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 17 Oct 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1460 In Episode 32 of Mobycast, we finished our series on application logging. In particular, we discuss how Kelsus leverages Sumo Logic to manage the logs of their projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 32 of Mobycast, we finished our series on application logging. In particular, we discuss how Kelsus leverages Sumo Logic to manage the logs of their projects. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern aws, cloud, software, development, programming No     Logging A-to-Z for Containerized Microservices (Part 2) 31 31 Logging A-to-Z for Containerized Microservices (Part 2) full 24ea7750-dc86-4eb6-8502-6ecabe396b84 https://share.transistor.fm/s/a2393e5b In Episode 31 of Mobycast, we dive into Part 2 of our series on application logging. In particular, we discuss best practices as well as how to forward logs from your containers to other services. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 31 of Mobycast, we dive into Part 2 of our series on application logging. In particular, we discuss best practices as well as how to forward logs from your containers to other services. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 10 Oct 2018 12:58:00 +0000 Mobycast.fm Mobycast.fm 1534 In Episode 31 of Mobycast, we dive into Part 2 of our series on application logging. In particular, we discuss best practices as well as how to forward logs from your containers to other services. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 31 of Mobycast, we dive into Part 2 of our series on application logging. In particular, we discuss best practices as well as how to forward logs from your containers to other services. Welcome to Mobycast, a weekly conversation about container aws, cloud, software, development, programming No     Logging A-to-Z for Containerized Microservices 30 30 Logging A-to-Z for Containerized Microservices full 853d00fa-0eb0-431c-8f7a-c25ac09511c2 https://share.transistor.fm/s/a9a174d4 In episode 30 of Mobycast, Jon and Chris talk about how Kelsus handles application-level logging for the microservices running on ECS. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 30 of Mobycast, Jon and Chris talk about how Kelsus handles application-level logging for the microservices running on ECS. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 03 Oct 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1523 In episode 30 of Mobycast, Jon and Chris talk about how Kelsus handles application-level logging for the microservices running on ECS. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 30 of Mobycast, Jon and Chris talk about how Kelsus handles application-level logging for the microservices running on ECS. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     VPC on AWS (Part 3) 29 29 VPC on AWS (Part 3) full b0111840-78e9-4e7d-a169-2bc45294318a https://share.transistor.fm/s/26874b26 In episode 29 of Mobycast, we conclude our series on how to setup your VPC to run ECS workloads. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 29 of Mobycast, we conclude our series on how to setup your VPC to run ECS workloads. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 26 Sep 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1313 In episode 29 of Mobycast, we conclude our series on how to setup your VPC to run ECS workloads. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 29 of Mobycast, we conclude our series on how to setup your VPC to run ECS workloads. Welcome of Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Setting up Virtual Private Clouds on AWS (Part 2) 28 28 Setting up Virtual Private Clouds on AWS (Part 2) full 312ef117-ab82-42c1-a192-dffa3013288f https://share.transistor.fm/s/d0fb61cf In Episode 28 of Mobycast, we continue our conversation on VPC setup on AWS. In particular, we discuss availability and security considerations. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 28 of Mobycast, we continue our conversation on VPC setup on AWS. In particular, we discuss availability and security considerations. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 19 Sep 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1434 In Episode 28 of Mobycast, we continue our conversation on VPC setup on AWS. In particular, we discuss availability and security considerations. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 28 of Mobycast, we continue our conversation on VPC setup on AWS. In particular, we discuss availability and security considerations. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     Setting up Virtual Private Clouds on AWS (Part 1) 27 27 Setting up Virtual Private Clouds on AWS (Part 1) full ae1246a3-d641-4e72-b1b8-bd825a0f5bd9 https://share.transistor.fm/s/395001d5 In Episode 27 of Mobycast, we start a new micro-series discussing the setup of virtual private clouds on AWS. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 27 of Mobycast, we start a new micro-series discussing the setup of virtual private clouds on AWS. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 12 Sep 2018 11:35:00 +0000 Mobycast.fm Mobycast.fm 1515 In Episode 27 of Mobycast, we start a new micro-series discussing the setup of virtual private clouds on AWS. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 27 of Mobycast, we start a new micro-series discussing the setup of virtual private clouds on AWS. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     Docker Tips & Tricks (Part 3) 26 26 Docker Tips & Tricks (Part 3) full bb84dbb0-c633-48f3-83f8-27ac7ad5a73a https://share.transistor.fm/s/13629820 In episode 26 of Mobycast, we conclude our micro series on Docker tips and tricks. In particular, we discuss security and pruning. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 26 of Mobycast, we conclude our micro series on Docker tips and tricks. In particular, we discuss security and pruning. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 05 Sep 2018 11:00:00 +0000 Mobycast.fm Mobycast.fm 1186 In episode 26 of Mobycast, we conclude our micro series on Docker tips and tricks. In particular, we discuss security and pruning. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 26 of Mobycast, we conclude our micro series on Docker tips and tricks. In particular, we discuss security and pruning. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Docker Tips & Tricks (Part 2) 25 25 Docker Tips & Tricks (Part 2) full c79d4e16-e467-401b-9e6e-25391f24212f https://share.transistor.fm/s/997e512a In Episode 25 of Mobycast, we continue our micro-series on Docker Tips and Tricks. In particular, we discuss how to start up containers dependably and shut them down gracefully. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 25 of Mobycast, we continue our micro-series on Docker Tips and Tricks. In particular, we discuss how to start up containers dependably and shut them down gracefully. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 29 Aug 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1278 In Episode 25 of Mobycast, we continue our micro-series on Docker Tips and Tricks. In particular, we discuss how to start up containers dependably and shut them down gracefully. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 25 of Mobycast, we continue our micro-series on Docker Tips and Tricks. In particular, we discuss how to start up containers dependably and shut them down gracefully. Welcome to Mobycast, a weekly conversation about containerization, Docker and aws, cloud, software, development, programming No     Docker Tips & Tricks (Part 1) 24 24 Docker Tips & Tricks (Part 1) full 3fa7e24b-ed76-48e1-a6f2-57b96021fbbc https://share.transistor.fm/s/ab3b506f In episode 24 of Mobycast, we dive into a new micro series on Docker tips and tricks. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 24 of Mobycast, we dive into a new micro series on Docker tips and tricks. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 22 Aug 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1058 In episode 24 of Mobycast, we dive into a new micro series on Docker tips and tricks. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 24 of Mobycast, we dive into a new micro series on Docker tips and tricks. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Case Study: Troubleshooting Container Disk Space 23 23 Case Study: Troubleshooting Container Disk Space full 4f40f2e5-2a7d-441f-a6c7-ef9fed197f69 https://share.transistor.fm/s/843b6276 In episode 23 of Mobycast, Jon and Chris will dive into another Kelsus case study. This time, we chat about troubleshooting container disk space. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 23 of Mobycast, Jon and Chris will dive into another Kelsus case study. This time, we chat about troubleshooting container disk space. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 15 Aug 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1987 In episode 23 of Mobycast, Jon and Chris will dive into another Kelsus case study. This time, we chat about troubleshooting container disk space. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 23 of Mobycast, Jon and Chris will dive into another Kelsus case study. This time, we chat about troubleshooting container disk space. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Adventures in AWS Certification 22 22 Adventures in AWS Certification full 9a0b33d4-b5c3-4d82-a369-ba451753a675 https://share.transistor.fm/s/ef0b7edc In episode 22 of Mobycast, Chris recaps his experience attending a rare, and privileged workshop at the AWS offices in San Francisco. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 22 of Mobycast, Chris recaps his experience attending a rare, and privileged workshop at the AWS offices in San Francisco. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 08 Aug 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1682 In episode 22 of Mobycast, Chris recaps his experience attending a rare, and privileged workshop at the AWS offices in San Francisco. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 22 of Mobycast, Chris recaps his experience attending a rare, and privileged workshop at the AWS offices in San Francisco. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Effective Container Images (Part 2) 21 21 Effective Container Images (Part 2) full 0b0fb801-ff91-4569-ae2b-d199bcace542 https://share.transistor.fm/s/74ef6e9c In episode 21 of Mobycast, we picked around last week's conversation with part two of how to create effective container images. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 21 of Mobycast, we picked around last week's conversation with part two of how to create effective container images. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 01 Aug 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1737 In episode 21 of Mobycast, we picked around last week's conversation with part two of how to create effective container images. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 21 of Mobycast, we picked around last week's conversation with part two of how to create effective container images. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Effective Container Images (Part 1) 20 20 Effective Container Images (Part 1) full a5269ec3-37b4-4351-9f1b-add405dc09a3 https://share.transistor.fm/s/76f4ec06 In episode 20 of Mobycast, Chris recaps another DockerCon 2018 session, how to create effective container images by Abby Fuller. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 20 of Mobycast, Chris recaps another DockerCon 2018 session, how to create effective container images by Abby Fuller. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 25 Jul 2018 12:00:00 +0000 Mobycast.fm Mobycast.fm 1658 In episode 20 of Mobycast, Chris recaps another DockerCon 2018 session, how to create effective container images by Abby Fuller. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 20 of Mobycast, Chris recaps another DockerCon 2018 session, how to create effective container images by Abby Fuller. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Securing Containerized Deployments (Part 2) 19 19 Securing Containerized Deployments (Part 2) full 8c7215d8-d8bf-45ac-bb55-9708534139aa https://share.transistor.fm/s/1ac1adaa In episode 19 of Mobycast, Chris leads part two of a discussion about securing containerized deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 19 of Mobycast, Chris leads part two of a discussion about securing containerized deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 18 Jul 2018 13:30:00 +0000 Mobycast.fm Mobycast.fm 1708 In episode 19 of Mobycast, Chris leads part two of a discussion about securing containerized deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 19 of Mobycast, Chris leads part two of a discussion about securing containerized deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Securing Containerized Deployments (Part One) 18 18 Securing Containerized Deployments (Part One) full 7c62901b-d0e6-40fc-9f07-1324e5ebba21 https://share.transistor.fm/s/df7695a1 In episode 18 of Mobycast, Chris leads a DockerCon session roll up. In particular, we discussed securing container-based deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 18 of Mobycast, Chris leads a DockerCon session roll up. In particular, we discussed securing container-based deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 11 Jul 2018 00:22:00 +0000 Mobycast.fm Mobycast.fm 1396 In episode 18 of Mobycast, Chris leads a DockerCon session roll up. In particular, we discussed securing container-based deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 18 of Mobycast, Chris leads a DockerCon session roll up. In particular, we discussed securing container-based deployments. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Takeaways from Dockercon 2018 17 17 Takeaways from Dockercon 2018 full 42cf2214-f963-40c0-b211-e050e9ba5f45 https://share.transistor.fm/s/279b838b In episode 17 of Mobycast, Chris provides his main takeaways from dockercon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 17 of Mobycast, Chris provides his main takeaways from dockercon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 04 Jul 2018 12:51:00 +0000 Mobycast.fm Mobycast.fm 1525 In episode 17 of Mobycast, Chris provides his main takeaways from dockercon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 17 of Mobycast, Chris provides his main takeaways from dockercon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Troubleshooting Distributed Systems: A Case Study 16 16 Troubleshooting Distributed Systems: A Case Study full 0dcbbfe8-8e20-43a0-9042-f654cf6cfee7 https://share.transistor.fm/s/a5c2cbc3 In episode 16 of Mobycast, Jon and Chris discuss how they recently troubleshot a client’s distributed system. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 16 of Mobycast, Jon and Chris discuss how they recently troubleshot a client’s distributed system. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 27 Jun 2018 06:00:00 +0000 Mobycast.fm Mobycast.fm 1838 In episode 16 of Mobycast, Jon and Chris discuss how they recently troubleshot a client’s distributed system. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 16 of Mobycast, Jon and Chris discuss how they recently troubleshot a client’s distributed system. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     All About Docker Compose 15 15 All About Docker Compose full 1df5a337-e538-4540-a98e-418ca7b9c24d https://share.transistor.fm/s/bb82ddc6 In episode 15 of Mobycast, Jon and Chris teach me all about Docker Compose. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 15 of Mobycast, Jon and Chris teach me all about Docker Compose. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 20 Jun 2018 06:00:00 +0000 Mobycast.fm Mobycast.fm 1538 In episode 15 of Mobycast, Jon and Chris teach me all about Docker Compose. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 15 of Mobycast, Jon and Chris teach me all about Docker Compose. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Stop Worrying About Cloud Lock-in 14 14 Stop Worrying About Cloud Lock-in full b5c42493-8bd6-406d-b3db-8d9833947c86 https://share.transistor.fm/s/4035b961 In Episode 14 of Mobycast, Jon and Chris explained why you should stop worrying about cloud lock-in. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In Episode 14 of Mobycast, Jon and Chris explained why you should stop worrying about cloud lock-in. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 13 Jun 2018 06:52:00 +0000 Mobycast.fm Mobycast.fm 1455 In Episode 14 of Mobycast, Jon and Chris explained why you should stop worrying about cloud lock-in. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In Episode 14 of Mobycast, Jon and Chris explained why you should stop worrying about cloud lock-in. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     The Future of Serverless 13 13 The Future of Serverless full 27a48bb9-1858-4071-9e82-339b986e0099 https://share.transistor.fm/s/9d310a4b In episode 13 of Mobycast, Jon and Chris discussed the future of serverless. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 13 of Mobycast, Jon and Chris discussed the future of serverless. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 06 Jun 2018 00:00:00 +0000 Mobycast.fm Mobycast.fm 1560 In episode 13 of Mobycast, Jon and Chris discussed the future of serverless. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 13 of Mobycast, Jon and Chris discussed the future of serverless. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Key Takeaways from Gluecon 2018 12 12 Key Takeaways from Gluecon 2018 full 659f0577-7488-4f85-a237-d9cac64aea48 https://share.transistor.fm/s/e609556b In episode 12 of Mobycast, John discusses his key takeaways from GlueCon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     In episode 12 of Mobycast, John discusses his key takeaways from GlueCon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment.

    ]]>     Wed, 30 May 2018 07:30:00 +0000 Mobycast.fm Mobycast.fm 1565 In episode 12 of Mobycast, John discusses his key takeaways from GlueCon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. In episode 12 of Mobycast, John discusses his key takeaways from GlueCon 2018. Welcome to Mobycast, a weekly conversation about containerization, Docker and modern software deployment. aws, cloud, software, development, programming No     Will AWS be Crushed Under it's Own Weight? (Part 02) 11 11 Will AWS be Crushed Under it's Own Weight? (Part 02) full b9714978-73c2-4c1e-b8e4-9aab761188e4 https://share.transistor.fm/s/7d7b9f8d In Episode 11 of Mobycast, we continue last week’s conversation regarding the negative implications of AWS’ rapid growth. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In Episode 11 of Mobycast, we continue last week’s conversation regarding the negative implications of AWS’ rapid growth. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 23 May 2018 01:53:00 +0000 Mobycast.fm Mobycast.fm 1262 In Episode 11 of Mobycast, we continue last week’s conversation regarding the negative implications of AWS’ rapid growth. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In Episode 11 of Mobycast, we continue last week’s conversation regarding the negative implications of AWS’ rapid growth. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     Will AWS Be Crushed Under it’s Own Weight? (Part 01) 10 10 Will AWS Be Crushed Under it’s Own Weight? (Part 01) full 7e3d4008-d9cf-437f-ac18-4f2e3e215e6d https://share.transistor.fm/s/4ed03e94 In episode 10 of Mobycast, Jon and Chris consider a reality where AWS crushes under its own weight. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     In episode 10 of Mobycast, Jon and Chris consider a reality where AWS crushes under its own weight. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment.

    ]]>     Wed, 16 May 2018 00:00:00 +0000 Mobycast.fm Mobycast.fm 1390 In episode 10 of Mobycast, Jon and Chris consider a reality where AWS crushes under its own weight. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. In episode 10 of Mobycast, Jon and Chris consider a reality where AWS crushes under its own weight. Welcome to Mobycast, a weekly conversation about containerization, Docker, and modern software deployment. aws, cloud, software, development, programming No     AWS Services We're Evaluating 9 9 AWS Services We're Evaluating full c9d9590b-5db2-443c-84c6-ed26b87f28c0 https://share.transistor.fm/s/f30656ac In episode 9 of Mobycast, Jon and Chris discuss a few of the AWS services they’re currently evaluating.

    ]]>     In episode 9 of Mobycast, Jon and Chris discuss a few of the AWS services they’re currently evaluating.

    ]]>     Wed, 09 May 2018 06:00:00 +0000 Mobycast.fm Mobycast.fm 3450 In episode 9 of Mobycast, Jon and Chris discuss a few of the AWS services they’re currently evaluating. In episode 9 of Mobycast, Jon and Chris discuss a few of the AWS services they’re currently evaluating. aws, cloud, software, development, programming No     Core AWS Services 8 8 Core AWS Services full 846fb492-c7aa-4e33-9ab4-44f3af9bc2f3 https://share.transistor.fm/s/9ef5ac0a In episode 8 of Mobycast, Jon and Chris discussed the core AWS services they use regularly.

    ]]>     In episode 8 of Mobycast, Jon and Chris discussed the core AWS services they use regularly.

    ]]>     Wed, 02 May 2018 07:15:00 +0000 Mobycast.fm Mobycast.fm 3086 In episode 8 of Mobycast, Jon and Chris discussed the core AWS services they use regularly. In episode 8 of Mobycast, Jon and Chris discussed the core AWS services they use regularly. aws, cloud, software, development, programming No     How to Create Containers (Part 2) 7 7 How to Create Containers (Part 2) full c2c7755c-62d6-4e7b-b9ab-5cbf0ef605af https://share.transistor.fm/s/0f2f5299 In episode 7 of Mobycast, we continue with part 2 of a technical series around the creation of Containers. Specifically, Jon and Chris dive deep into Docker networking. 

    ]]>     In episode 7 of Mobycast, we continue with part 2 of a technical series around the creation of Containers. Specifically, Jon and Chris dive deep into Docker networking. 

    ]]>     Wed, 25 Apr 2018 07:15:00 +0000 Mobycast.fm Mobycast.fm 2553 In episode 7 of Mobycast, we continue with part 2 of a technical series around the creation of Containers. Specifically, Jon and Chris dive deep into Docker networking.  In episode 7 of Mobycast, we continue with part 2 of a technical series around the creation of Containers. Specifically, Jon and Chris dive deep into Docker networking.  aws, cloud, software, development, programming No     How to Create Containers (Part 1) 6 6 How to Create Containers (Part 1) full 069d8f21-f151-4e61-b304-135b978a5199 https://share.transistor.fm/s/d1bd8041 In episode six of Mobycast, we introduce Part 1 of a technical series around the creation of containers. Specifically Jon and Chris teach me about base images and volume mounts.

    ]]>     In episode six of Mobycast, we introduce Part 1 of a technical series around the creation of containers. Specifically Jon and Chris teach me about base images and volume mounts.

    ]]>     Wed, 18 Apr 2018 00:00:00 +0000 Mobycast.fm Mobycast.fm 1994 In episode six of Mobycast, we introduce Part 1 of a technical series around the creation of containers. Specifically Jon and Chris teach me about base images and volume mounts. In episode six of Mobycast, we introduce Part 1 of a technical series around the creation of containers. Specifically Jon and Chris teach me about base images and volume mounts. aws, cloud, software, development, programming No     Making the Business Case for Docker 5 5 Making the Business Case for Docker full d55df8b4-6f8c-4781-b4ab-be238a6abaca https://share.transistor.fm/s/f5504f20 Episode 5 of Mobycast focuses on building a business case for transitioning to Docker.

    ]]>     Episode 5 of Mobycast focuses on building a business case for transitioning to Docker.

    ]]>     Wed, 11 Apr 2018 09:00:00 +0000 Mobycast.fm Mobycast.fm 2641 Episode 5 of Mobycast focuses on building a business case for transitioning to Docker. Episode 5 of Mobycast focuses on building a business case for transitioning to Docker. aws, cloud, software, development, programming No     The CI/CD Pipeline 4 4 The CI/CD Pipeline full 3edf8870-2410-47a3-b38d-9426089a310b https://share.transistor.fm/s/9775ffd3 Chris Hickman and Jon Christensen of Kelsus discuss the company’s CI/CD toolchain - continuous integration (CI) and deployment (CD) - when it comes to containerization. Your CI/CD pipeline will look completely different after being dockerized.

    ]]>     Chris Hickman and Jon Christensen of Kelsus discuss the company’s CI/CD toolchain - continuous integration (CI) and deployment (CD) - when it comes to containerization. Your CI/CD pipeline will look completely different after being dockerized.

    ]]>     Wed, 04 Apr 2018 17:28:00 +0000 Mobycast.fm Mobycast.fm 3466 Chris Hickman and Jon Christensen of Kelsus discuss the company’s CI/CD toolchain - continuous integration (CI) and deployment (CD) - when it comes to containerization. Your CI/CD pipeline will look completely different after being dockerized. Chris Hickman and Jon Christensen of Kelsus discuss the company’s CI/CD toolchain - continuous integration (CI) and deployment (CD) - when it comes to containerization. Your CI/CD pipeline will look completely different after being dockerized. aws, cloud, software, development, programming No     An Introduction to Elastic Container Service (ECS) 3 3 An Introduction to Elastic Container Service (ECS) full 41e49ac2-1504-44c9-96e4-5c02724656e6 https://share.transistor.fm/s/75c8cdc0 Jon Christensen and Chris Hickman of Kelsus discuss Amazon’s Elastic Container Service (ECS) – how it works and why they use it. The term “container” comes from stacking containers on ships, and containers offer several advantages. But how does containerization relate to scaling on a large application?

    ]]>     Jon Christensen and Chris Hickman of Kelsus discuss Amazon’s Elastic Container Service (ECS) – how it works and why they use it. The term “container” comes from stacking containers on ships, and containers offer several advantages. But how does containerization relate to scaling on a large application?

    ]]>     Thu, 29 Mar 2018 19:17:00 +0000 Mobycast.fm Mobycast.fm 3619 Jon Christensen and Chris Hickman of Kelsus discuss Amazon’s Elastic Container Service (ECS) – how it works and why they use it. The term “container” comes from stacking containers on ships, and containers offer several advantages. But how does containerization relate to scaling on a large application? Jon Christensen and Chris Hickman of Kelsus discuss Amazon’s Elastic Container Service (ECS) – how it works and why they use it. The term “container” comes from stacking containers on ships, and containers offer several advantages. But how does containeri aws, cloud, software, development, programming No     Transitioning Legacy Applications to Docker 2 2 Transitioning Legacy Applications to Docker full c4dc3f22-f978-4a26-91f3-37156a5d1494 https://share.transistor.fm/s/3cafd4ad What goes on inside an organization when it decides to make the switch to Docker? What does a team and company go through? Chris Hickman and Jon Christensen of Kelsus discuss transitioning legacy applications to Docker. About two-three years ago, Chris joined a company that was in the midst of transitioning to Docker to handle its Amazon Web loads. He was tasked with learning how to dockerize all of the microservices deployed by the company inside AWS.

    ]]>     What goes on inside an organization when it decides to make the switch to Docker? What does a team and company go through? Chris Hickman and Jon Christensen of Kelsus discuss transitioning legacy applications to Docker. About two-three years ago, Chris joined a company that was in the midst of transitioning to Docker to handle its Amazon Web loads. He was tasked with learning how to dockerize all of the microservices deployed by the company inside AWS.

    ]]>     Thu, 29 Mar 2018 19:15:00 +0000 Mobycast.fm Mobycast.fm 3212 What goes on inside an organization when it decides to make the switch to Docker? What does a team and company go through? Chris Hickman and Jon Christensen of Kelsus discuss transitioning legacy applications to Docker. About two-three years ago, Chris joined a company that was in the midst of transitioning to Docker to handle its Amazon Web loads. He was tasked with learning how to dockerize all of the microservices deployed by the company inside AWS. What goes on inside an organization when it decides to make the switch to Docker? What does a team and company go through? Chris Hickman and Jon Christensen of Kelsus discuss transitioning legacy applications to Docker. About two-three years ago, Chris jo aws, cloud, software, development, programming No     Virtual Machines vs. Containers 1 1 Virtual Machines vs. Containers full 7ff4f911-d47c-4606-b107-2b363d23fa0c https://share.transistor.fm/s/a3aaa17f Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache discuss the differences between virtual machines (VMs) and containers. What are the pros? Cons? Similarities? Differences?

    ]]>     Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache discuss the differences between virtual machines (VMs) and containers. What are the pros? Cons? Similarities? Differences?

    ]]>     Thu, 29 Mar 2018 19:12:00 +0000 Mobycast.fm Mobycast.fm 2618 Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache discuss the differences between virtual machines (VMs) and containers. What are the pros? Cons? Similarities? Differences? Chris Hickman and Jon Christensen of Kelsus and Rich Staats from Secret Stache discuss the differences between virtual machines (VMs) and containers. What are the pros? Cons? Similarities? Differences? aws, cloud, software, development, programming No