Amazon RDS is a fully managed Relational Database Service on AWS. Amazon Aurora is a MySQL and Postgres compatible database with much better performance at scale due to the enhancements and rewriting AWS has put in. For more context on Aurora, here is my earlier post.
Aurora RDS has several practical configurations applicable to pretty much all production workloads (Multi region, Multi-flavored read replicas FTW!). The ones I like the most are Aurora Global Database, and Aurora Serverless.
Imagine a fully managed database in the cloud that needs minimal upfront setup, scales on demand, and saves $$ by pausing when not in use. In a nutshell, thats exactly what Aurora Serverless is.
In this post I will talk about the fundamental concepts, use cases, setting up a cluster, taking it for a spin, and tips/gotchas.
While setting up a Consul cluster, I decided to dig a bit deeper into the whole
/var/run/docker.sockphenomenon. While it is fairly common that a lot of Service Meshes like Consul, and System Monitoring Services like Newrelic and DataDog ask to mount
/var/run/docker.sock, I must admit I’ve always been curious about this particular socket (vs. taking the mount step for granted). These are my notes from calling Docker Server by curl-ing the socket.
Slides from my tech talk at Marqeta.
Simple script to manage multiple AWS credentials when using the CLI or SDKs.
At re:Invent 2018, AWS announced Lambda Layers, bringing Lambda construct closer to that of an AMI. Put simply, layers are dependencies that can be made available to the function at runtime. Currently there can be 5 layers associated with a function. Layers help with isolating common dependencies, as well as keeping the runtime consistent in terms of versions - just like the AMIs do. Layers are immutable, and are versioned. While this post is focused on Python, the concept of layers applies uniformly regardless of the language (although I feel this is more useful for dynamic languages compared to languages like Java, where the whole artifact is packaged as a part of the deployment artifact). The dependencies are zipped up, uploaded as new layer, or a new version of an existing layer. They can be tied to runtimes (via labels) for validation as well.
In this post I’ll walk through creating a Python layer, and associating it with a function. I’ll use the CLI, aws-shell to accomplish this.