Mobycast
A Podcast About Cloud Native Software Development, AWS, and Distributed Systems
Wed, July 08, 2020
Hands On AWS - Massively Scalable Image Hosting Using S3 and CloudFront - Part 2
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, July 01, 2020
Hands On AWS - Massively Scalable Image Hosting Using S3 and CloudFront - Part 1
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, April 15, 2020
Replay of Ep 43 - The Birth of NoSQL and DynamoDb – Part 5
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, April 08, 2020
Replay of Ep 42 - The Birth of NoSQL and DynamoDb – Part 4
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 Hickm
Wed, April 01, 2020
Replay of Ep 41 - The Birth of NoSQL and DynamoDb – Part 3
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, March 25, 2020
Replay of Ep 40 - The Birth of NoSQL and DynamoDb – Part 2
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, March 18, 2020
Replay of Ep 39 - The Birth of NoSQL and DynamoDB
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, March 11, 2020
Replay of Ep 14. Stop Worrying About Cloud Lock-in
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 Kelsus Secret Stache Media AWS Fargate re:Invent <
Trailer · Sun, March 08, 2020
Learn cloud native software development by podcast
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.
Wed, March 04, 2020
Automate all the things - Updating container secrets using CloudWatch Events + Lambda
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, February 26, 2020
Database Soup - Explaining ACID, BASE, CAP - Part 3
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, February 19, 2020
Database Soup - Explaining ACID, BASE, CAP - Part 2
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, February 12, 2020
Database Soup - Explaining ACID, BASE, CAP - Part 1
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, February 05, 2020
Your Most Important Skill
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, January 29, 2020
The Future of Containers - Part 3 - Unikernels
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, January 22, 2020
The Future of Containers - Part 2 - Making Sense of MicroVMs (continued)
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, January 15, 2020
The Future of Containers - Part 1 - Making Sense of MicroVMs
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, January 08, 2020
Psst... Secrets Handling for Cloud-Native Apps - Part 2
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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, January 01, 2020
Psst... Secrets Handling for Cloud-Native Apps - Part 1
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 Secrets Management for Cloud-Native Applications Vault - Unlocking the Cloud Operating Model: Security AWS Systems Manager Parameter Store How AWS Systems Manager Parameter Store Uses AWS KMS Introducing AWS Secrets Manager AWS Secrets Manager How AWS Secrets Manager Uses AWS KMS Rotating Your AWS Secrets Manager Secrets Tutorial: Specifying Sensitive Data Using Secrets Manager Secrets AWS Secrets Manager now supports VPC endpoint policies How to Manage Secrets for Amazon EC2 Container Service–Based Applications by Using Amazon S3 and Docker <b
Wed, December 25, 2019
VPC Ninja - Part 3 - Moving an ECS Application to Private Subnets
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 VPC with Public and Private Subnets (NAT) Changing the Launch Configuration for an Auto Scaling Group Add Encryption to an Unencrypted RDS DB Instance Amazon ECS-optimized AMIs 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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Bonus · Thu, December 19, 2019
That's a Wrap - AWS re:Invent 2019 Takeaways - Part 2
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 AWS re:Invent AWS re:Invent 2019 Session Vi
Wed, December 18, 2019
That's a Wrap - AWS re:Invent 2019 Takeaways - Part 1
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 AWS re:Invent AWS re:Invent 2019 Session Videos <a href="https:/
Wed, December 11, 2019
VPC Ninja - Part 2 - Private subnets with VPN (continued)
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 VPC with Public and Private Subnets (NAT) Software VPN OpenVPN SoftEther Openswan Amazon Web Services EC2 BYOL appliance quick start guide AWS Certificate Manager ZeroSSL 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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: <a href="https://reddit.co
Wed, December 04, 2019
VPC Ninja - Part 1 - Private Subnets with VPN
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
Wed, November 27, 2019
AWS re:Invent 2019 - A Preview Show
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 AWS re:Invent AWS re:Invent Twitter feed AWS re:Invent 2019 - How to re:Invent YouTube channel Startup Central is Headed to re:Invent! A Cloud Guru Guide to re:Invent Linux Academy Guide to re:Invent Las Vegas Monorail Unofficial - re:Invent Parties Twitter feed Unofficial - List of AWS re:Invent Conference and Vendor Parties Apple launches 16-inch MacBook Pro with 6 speakers and 'Magic Keyboard' 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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, November 20, 2019
Serverless Containers with ECS Fargate - Part 3
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 othe
Bonus · Sat, November 16, 2019
Bonus Episode! Docker Is Kind of Acquired By ... Who Is Mirantis?
Support Mobycast https://glow.fm/mobycast Links Techcrunch article Mirantis Docker 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: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, November 13, 2019
Serverless Containers with ECS Fargate - Part 2
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 bas
Wed, November 06, 2019
Serverless Containers with ECS Fargate - Part 1
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
Wed, October 30, 2019
Virtual Machines vs. Containers Revisited - Part 4
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 centralize
Wed, October 23, 2019
Virtual Machines vs. Containers Revisited - Part 3
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 fi
Wed, October 16, 2019
Virtual Machines vs. Containers Revisited - Part 2
Sponsors Circle CI Episode on CI/CD with Circle CI Show Details In this episode, we cover the following topics: Hypervisor implementations Hyper-V Type 1 hypervisor from Microsoft Architecture Implements isolation of virtual machines in terms of a partition Partition is logical unit of isolation in which each guest OS executes Parent partition Virtualization software runs in parent partition and has direct access to hardware Requires supported version of Windows Server There must be at least one parent partition Parent partition creates child partitions which host the guest OSes Done via Hyper-V "hypercall" API Parent partitions run a Virtualization Service Provider (VSP) which connects to the VMBus Handles device access requests from child partition Child partition Does not have direct access to hardware Has virtual view of processor and runs in Guest Virtual Address (not necessarily the entire virtual address space) Hypervisor handles interrupts to processor, and redirects to respective partition Any request to the virtual devices is redirected via the VMBus to the devices in the parent partition VMBus Logical channel which enables inter-partition communication KVM (Kernel-based Virtual Machine) Virtualization module in Linux kernel Turns Linux kernel into hypervisor Available in mainline Linux since 2007 Can run multiple VMs running unmodified Linux or Windows images Leverages hardware virtualization Via CPU virtualization extensions (Intel VT or AMD-V) But also provides paravirtualization support for Linux/FreeBSD/NetBSD/Windows using VirtIO API Architecture Kernel component Consists of: Loadable kernel module, kvm.ko, that provides the core virtualization infrastructure Processor specific module, kvm-intel.ko or kvm-amd.ko Userspace component QEMU (Quick Emulator) Userland program that does hardware emulation Used by KVM for I/O emulations AWS hypervisor choices & history AWS uses custom hardware for faster EC2 VM performance Original EC2 technology ran highly customized version of Xen hypervisor VMs can run using either paravirtualization (PV) or hardware virtual machine (HVM) HVM guests are fully virtualized VMs on top of hypervisor are not aware they are sharing with other VMs <li
Wed, October 09, 2019
Virtual Machines vs. Containers Revisited - Part 1
Sponsor Circle CI Episode on CI/CD with Circle CI Show Details In this episode, we cover the following topics: VMs vs containers - why revisit? Originally talked about this in episode 1 Got most of it right, but some inconsistencies/holes Let's revisit to fill in the gaps, and dive a whole LOT deeper this time around Types of virtualization Full virtualization ("virtual machines") Simulates enough hardware to allow an unmodified "guest" OS to be run in isolation Resources of computer are partitioned via hypervisor Examples: VMWare, Parallels, VirtualBox, Hyper-V Operating-system-level virtualization ("containers") Resources of computer are partitioned via the kernel "Guest" OSes share same running instance of OS as the host system Based on the virtualization, isolation, and resource management mechanisms provided by the Linux kernel namespaces and cgroups Examples: Docker, LXC, FreeBSD jails Hypervisors Also known as a Virtual Machine Manager (VMM) Creates and runs virtual machines It is a process that separates OS and apps from underlying physical hardware Multiple VMs share virtualized hardware resources When you create a new VM, the following happens: Hypervisor allocates memory and CPU space for VMs exclusive use Complete OS is installed onto the VM The VM's OS communicates with the hypervisor to perform tasks Host OS is able to see all physical hardware, whereas guest OS (VM) can only see hardware to which hypervisor has granted access Two types of hypervisors Type 1 (also called "native" or "bare metal" hypervisors) Run directly on the host’s hardware to control the hardware and manage the guest VMs runs in ring 0 Are an OS themselves (simple OS on top of which you run VMs) the physical machine the hypervisor is running on serves only for virtualization purposes Exceptions: Hyper-V, KVM Examples Xen, Microsoft Hyper-V, VMware ESX/ESXi Type 2 (also called "hosted" hypervisors) Run on conventional OS, just like other apps Guest OS runs as a process on the host Hypervisor separates the guest OS from the host OS Examples VirtualBox, Parallels Protection levels (rings) x86 family of CPUs provide a range of protection levels also known as rings Ring 0 has the highest level privilege (kernel/supervisor) Ring 3 lowest level (applications) </ul
Wed, October 02, 2019
Are You Well Architected? The Well-Architected Framework - Part 3
Sponsor Circle CI Episode on CI/CD with Circle CI Show Details In this episode, we cover the following topics: Pillars in depth Performance Efficiency "Ability to use resources efficiently to meet system requirements and maintain that efficiency as demand changes and technology evolves" Design principles Easy to try new advanced technologies (by letting AWS manage them, instead of standing them up yourself) Go global in minutes Use serverless architectures Experiment more often Mechanical sympathy (use the technology approach that aligns best to what you are trying to achieve) Key service: CloudWatch Focus areas Selection Services: EC2, EBS, RDS, DynamoDB, Auto Scaling, S3, VPC, Route53, DirectConnect Review Services: AWS Blog, AWS What's New Monitoring Services: CloudWatch, Lambda, Kinesis, SQS Tradeoffs Services: CloudFront, ElastiCache, Snowball, RDS (read replicas) Best practices Selection Choose appropriate resource types Compute, storage, database, networking Trade Offs Proximity and caching Cost Optimization "Ability to run systems to deliver business value at the lowest price point" Design principles Adopt a consumption model (only pay for what you use) Measure overall efficiency Stop spending money on data center operations Analyze and attribute expenditures Use managed services to reduce TCO Key service: AWS Cost Explorer (with cost allocation tags) Focus areas Expenditure awareness Services: Cost Explorer, AWS Budgets, CloudWatch, SNS Cost-effective resources Services: Reserved Instances, Spot Instances, Cost Explorer Matching supply and demand Services: Auto Scaling Optimizing over time Services: AWS Blog, AWS What's New, Trusted Advisor Key points Use Trusted Advisor to find ways to save $$$ The Well-Architected Review Centered around the question "Are you well architected?" The Well-Architected review provides a consistent approach to review workload against current AWS best practices and gives advice on how to architect for the cloud Benefits of the review Build and deploy faster Lower or mitigate risks Make informed decisions Learn AWS best practices The AWS Well-Architected Tool Cloud-based service available from the AWS
Wed, September 25, 2019
Are You Well Architected? The Well-Architected Framework - Part 2
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 yo
Wed, September 18, 2019
Are You Well Architected? The Well-Architected Framework - Part 1
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
Wed, September 11, 2019
The Twelve-Factor App: 12 Best Practices for Microservices
The Twelve-Factor App methodology Drafted by developers at Heroku based upon their observations of what made good apps First presented by Adam Wiggins circa 2011 (then published in 2012) The Factors 1 - Codebase: one codebase tracked in revision control, many deploys 2 - Dependencies: explicitly declare and isolate dependencies 3 - Config: strict separation of config from code 4 - Backing services: foster loose coupling by treating backing services as attached resources 5 - Build, release, run: strictly separate build and run stages 6 - Processes: processes are stateless and share-nothing 7 - Port binding: export services via port binding 8 - Concurrency: scale out via the process model 9 - Disposability: processes are disposable, they can be started or stopped at a moment’s notice 10 - Dev/prod parity: Keep development, staging, and production as similar as possible 11 - Logs: treat logs as event streams, don't manage log files 12 - Admin processes: admin and utility code ships with app code to avoid synchronization issues What's Missing? 7 years since first being published, what changes should be made to make it more relevant for today? Some have argued for adding 3 additional factors: Telemetry Security "API First"-philosophy For a full transcription of this episode, please visit the episode webpage . End song: Flowerchild (Roy England Remix) by Owen Ni - Make Mistakes We'd love to hear from you! You can reach us at: Web: https://mobycast.fm Voicemail: 844-818-0993 Email: ask@mobycast.fm Twitter: https://twitter.com/hashtag/mobycast Reddit: https://reddit.com/r/mobycast
Wed, September 04, 2019
An Encryption Deep Dive - Part Four
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, August 28, 2019
An Encryption Deep Dive - Part Three
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, August 21, 2019
An Encryption Deep Dive - Part Two
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, August 14, 2019
An Encryption Deep Dive - Part One
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, August 07, 2019
Growth Hacking for Remote and International Developers - Part 2
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, July 31, 2019
Growth Hacking for Remote and International Developers - Part 1
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, July 24, 2019
Microservices Bootcamp 3 - Micro Frontends
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.
Thu, July 18, 2019
Microservices Part 2: Sizing, Decomposition, and Dismantling the Monolith
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.
Wed, July 10, 2019
Microservices Boot Camp Part 1
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, July 03, 2019
Real World AWS - Using Custom CloudWatch Metrics to Monitor Disk Space
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, June 26, 2019
Using Feature Flags to Increase Velocity and Decrease Risk in a Modern CI:CD Delivery Pipeline
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, June 19, 2019
Practical AWS - Hosting a Personal Blog the Hard Way, Then the Easy Way
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, June 12, 2019
Post Gluecon Thoughts and How Aurora Serverless Works
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, June 05, 2019
Service-to-Service Authentication for Microservice APIs
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, May 29, 2019
Practical Istio (A Dockercon 2019 Recap)
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, May 22, 2019
Just What is a "Service Mesh", and If I Get One Will It Make Everything OK? (A Dockercon 2019 Recap)
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, May 15, 2019
Node.js Rocks in Docker for Dev and Ops (Part 2)
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, May 08, 2019
Node.js Rocks in Docker for Dev and Ops (A Dockercon 2019 Recap)
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, May 01, 2019
Practical Issues with RDS Replicas
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, April 24, 2019
DockerCon 2019 - A Preview Show
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, April 17, 2019
How to Become a Great Software Developer (Part 2)
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, April 10, 2019
How to Become a Great Software Developer (Part 1)
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, April 03, 2019
DNS 101
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, March 27, 2019
Health Checks for Services, Containers and Daemons
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.
Wed, March 20, 2019
Real World Architecture in the Cloud Using Event-Driven Techniques to Build a PDF Rendering Pipeline
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, March 13, 2019
Evolve or Die - The Importance of Continuous Learning
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, March 06, 2019
Open Source Tension - Who Should Profit?
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, February 27, 2019
Building RESTful APIs (Part 2)
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, February 20, 2019
Microservice RESTful APIs - Tips & Guidelines for Crafting Beautiful, Simple APIs
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, February 13, 2019
Evaluating AWS Cognito For Your Architecture
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, February 06, 2019
Revisiting the Serverless Holy War
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, January 30, 2019
Serverless Made More Modular - Lambda Layers and Runtime API
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, January 23, 2019
The Birth of NoSQL and DynamoDB - Part 5
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, January 16, 2019
AWS Launches DocumentDB - Should Mongo Be Worried?
In episode 44 of Mobycast, we discuss AWS's launch of DocumentDB, and whether or not Mongo should be worried.
Wed, January 09, 2019
The Birth of NoSQL and Dynamo DB - Part 4
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, January 02, 2019
The Birth of NoSQL and DynamoDB - Part 3
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, December 26, 2018
The Birth of NoSQL and DynamoDB - Part 2
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, December 19, 2018
The Birth of NoSQL and DynamoDB - Part 1
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, December 12, 2018
When (and When Not) to use Open Source Libraries
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, December 05, 2018
The Path to AWS Certification
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, November 14, 2018
Preparing for Re:Invent 2018
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, November 07, 2018
A Mobycast Retrospective
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, October 31, 2018
Event-Driven Architecture (Part 2)
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, October 24, 2018
Event-Driven Architecture (Part 1)
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, October 17, 2018
Logging A-to-Z for Containerized Microservices (Part 3)
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, October 10, 2018
Logging A-to-Z for Containerized Microservices (Part 2)
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, October 03, 2018
Logging A-to-Z for Containerized Microservices
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, September 26, 2018
VPC on AWS (Part 3)
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, September 19, 2018
Setting up Virtual Private Clouds on AWS (Part 2)
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, September 12, 2018
Setting up Virtual Private Clouds on AWS (Part 1)
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, September 05, 2018
Docker Tips & Tricks (Part 3)
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, August 29, 2018
Docker Tips & Tricks (Part 2)
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, August 22, 2018
Docker Tips & Tricks (Part 1)
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, August 15, 2018
Case Study: Troubleshooting Container Disk Space
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, August 08, 2018
Adventures in AWS Certification
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, August 01, 2018
Effective Container Images (Part 2)
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, July 25, 2018
Effective Container Images (Part 1)
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, July 18, 2018
Securing Containerized Deployments (Part 2)
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, July 11, 2018
Securing Containerized Deployments (Part One)
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, July 04, 2018
Takeaways from Dockercon 2018
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, June 27, 2018
Troubleshooting Distributed Systems: A Case Study
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, June 20, 2018
All About Docker Compose
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, June 13, 2018
Stop Worrying About Cloud Lock-in
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, June 06, 2018
The Future of Serverless
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, May 30, 2018
Key Takeaways from Gluecon 2018
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, May 23, 2018
Will AWS be Crushed Under it's Own Weight? (Part 02)
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, May 16, 2018
Will AWS Be Crushed Under it’s Own Weight? (Part 01)
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, May 09, 2018
AWS Services We're Evaluating
In episode 9 of Mobycast, Jon and Chris discuss a few of the AWS services they’re currently evaluating.
Wed, May 02, 2018
Core AWS Services
In episode 8 of Mobycast, Jon and Chris discussed the core AWS services they use regularly.
Wed, April 25, 2018
How to Create Containers (Part 2)
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, April 18, 2018
How to Create Containers (Part 1)
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, April 11, 2018
Making the Business Case for Docker
Episode 5 of Mobycast focuses on building a business case for transitioning to Docker.
Wed, April 04, 2018
The CI/CD Pipeline
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.
Thu, March 29, 2018
An Introduction to Elastic Container Service (ECS)
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, March 29, 2018
Transitioning Legacy Applications to Docker
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, March 29, 2018
Virtual Machines vs. Containers
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?
loading...