Git clone Gitlab Gitlab-Serverless 🙂
GitHub – wagoodman/dive: A tool for exploring each layer in a docker image
— Read on github.com/wagoodman/dive
Crowd Source Best DevOps tools diagram
Just kidding -:) No Karate SQL I am aware of..
Naturally you would use Kafka Streams if your code runs on Java where your code requires SQL like access to the data.
"Kafka Streams is the core API for stream processing on the JVM: Java, Scala, Clojure etc. It is based on a DSL (Domain Specific Language) that provides a declaratively-styled interface where streams can be joined, filtered, grouped or aggregated using the DSL itself. It also provides functionally-styled mechanisms — map, flatMap, transform, peek, etc"
(Building a Microservices Ecosystem with Kafka Streams and KSQL
Checkout KSQL, the Kafka Streams client for cases where you want to run SQL queries vs Kafka outside a JVM.
You can set a KSQL container as a side car along with your app container and let the app act upon regular Kafka Topic events, discarding the need for the app to deal with the data query logic needed to find relevant data off the stream.
Example: Your micro service needs to act upon a new customer order. Your sidecar container will run KSQL DSL select and stream only relevant event data to your app one at a time (configurable).
KSQL will get a copy of the same data across your micro services replicas.
Sounds like fun? Well because it is!
Maybe it should be called Karate SQL after all..
If you use AWS, and need Kafka (otherwise you would use AWS Kinesis), here is a nice basic starter automation for setting Kafka on AWS.
YES! ! AWS Secrets!!
I’d say secrets in parameter store are like Serverless credentials in Jenkins while secrets in secrets manager are like Serverless hashicorp vault. The difference for now is in the limits of use – SSM is free but would not work well when saturated with many calls – you are expected to use it moderately, while in AWS secrets you are not limited cause you pay. I believe in the future AWS secrets will be more feature-rich.
- Because they pre-set with correct permissions, no effort on your part
- You cannot delete those roles by mistake if an AWS service uses them
- Easier to audit use compared to roles you set yourself
More info here – look where the column for services linked roles says "Yes"
MongoDB gets mature aiming to grab at SQL markets.. adds support for ACID – allowing regular transactions reliability in parallel to its traditional support for fast noSQL abilities:
Info on ACID: https://en.m.wikipedia.org/wiki/ACID