Afleveringen

  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • Zijn er afleveringen die ontbreken?

    Klik hier om de feed te vernieuwen.

  • 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 outMain Architecture Components of Leviathan:API clientUpdate 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 usersBig difference between DynamoDB and Leviathan is request router and partition metadata system living on the server vs. living on the edgeLeviathan was a closed system with an instance for every network or data center; not designed to run as a software as a service, like DynamoDBLeviathan was strongly consistent, unlike DynamoDB’s eventually consistent modelDefinition and Different Types of TransactionsShepherd 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

    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 upUnderstand how a database is built to make architecture/component definitions less abstractDynamoDB 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 ConsistentWalkthrough of Workflow: What happens when, what does it mean when
DynamoDB architecture and components are designed to improve speed and scalabilitySplit 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

    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 dataDynamoDB has been around a long time, but people are finally using itDynamoDB and MongoDB are document or key value stores that offer scalability and event-driven programming to reduce complexityTechniques for keeping NoSQL database’s replicated data in syncImportance of indexes to understand query patternsDynamoDB’s Table Concept: Collection of documents/key value items; must have partition key to uniquely identify items in table and determine data distributionSort 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 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 regretsChris’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 architectureChris couldn’t use the code he had created for it while at Microsoft; but from that, he learned what he wouldn’t do againChris 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 S3Chris named his startup Viathan; had to do copyright, trademark, and domain name searchesData for the Microsoft project could be stored in files/XML documents; Viathan took a different approach and used relational databases instead of a file systemCompanies experienced problems at the beginning of the Internet; rest of ecosystem wasn’t developed and there weren’t enough people needing Internet solutions yetViathan went through several iterations that led to patents being issued and being considered as Prior artViathan’s technology couldn’t just be plugged in and turned on, applications had to be modified – a tough sellChris 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

  • 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 ShippingAmazon strives to prevent problems that it knows will happen again by realizing relational database management systems aren’t built/designed for the Internet/CloudInternet: Scale up vs. scale out via databases or servers; statefulness of databases prevents easy scalabilityNeed sharding and partitioning of data to have clusters that can be scaled up individuallyAmazon’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 newSolution: 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast

  • 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

    KelsusSecret Stache MediaAWS Fargatere:InventGlueconKubernetes
  • 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 [email protected].

  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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 availableSoft stateEventual consistencyWe 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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::AtomicityConsistencyIsolationDurabilityThe 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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 BuellerChris 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast
  • 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast

  • 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 ApplicationsVault - Unlocking the Cloud Operating Model: SecurityAWS Systems Manager Parameter StoreHow AWS Systems Manager Parameter Store Uses AWS KMSIntroducing AWS Secrets ManagerAWS Secrets ManagerHow AWS Secrets Manager Uses AWS KMSRotating Your AWS Secrets Manager SecretsTutorial: Specifying Sensitive Data Using Secrets Manager SecretsAWS Secrets Manager now supports VPC endpoint policiesHow to Manage Secrets for Amazon EC2 Container Service–Based Applications by Using Amazon S3 and Docker


    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:

    Web: https://mobycast.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast

  • 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 GroupAdd Encryption to an Unencrypted RDS DB InstanceAmazon 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.fmVoicemail: 844-818-0993Email: [email protected]: https://twitter.com/hashtag/mobycastReddit: https://reddit.com/r/mobycast