DEV Community: Rodel Talampas

Local Kubernetes Setup

Rodel Talampas — Sat, 04 Jul 2026 08:56:03 +0000

I started learning Kubernetes or Kube a few years ago but never really written a documentation on how I started. I am not an expert, if you are going to ask, but I know my ways.

In this short document, I used helm and minikube as my tools. If you are using Windows as your OS (or wants a Linux GUI instead), the Docker Desktop alone is your friend. Just enable Kubernetes and it will download everything you need as a start. But if you are a linux terminal fan like me, then this is a guide.

Let's start.

Prerequisites

docker client : There are many ways to install the docker client. I'd like to install it from apt directory (ubuntu fan here). This guide can help.
kube client (kubectl) : Similarly, you can install kubectl in different ways. I install it using homebrew.
helm : I was introduced to helm version 2 but recently changed to helm version 3. And its a big change. I would advise to use helm 3.
minikube : This is your local kubernetes cluster.

Basic Docker Commands

build : docker build -t myapptag -f myapp/Dockerfile .
run : docker run -p <container port>:<host port> myapptag

Server Running Locally

To start the local server minikube run the following

minikube start

Make sure to switch to the minikube context

kubectl config <minikube context>

Enable inbound or internal ingress access

minikube addons enable ingress

Helm Chart

A Helm Chart is a package for deploying applications to a Kubernetes cluster.
If Docker images are like compiled applications, then Helm Charts are like installers that know how to deploy and configure those applications on Kubernetes.

Without Helm, you need to use kubectl commands multiple times

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl apply -f ingress.yaml
kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl apply -f hpa.yaml

With Helm, you just need to run 1

helm install my-app ./my-chart

What is inside a Helm Chart?

A typical chart looks like this:

my-chart/
├── Chart.yaml          # Chart metadata
├── values.yaml         # Default configuration
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── configmap.yaml
│   └── hpa.yaml
└── charts/             # Dependencies

Chart.yaml

Defines information about the package to be deployed

apiVersion: v2
name: my-app
description: My application
version: 1.0.0
appVersion: "2.5.1"

values.yaml

Contains configurable settings.

replicaCount: 3

image:
  repository: mycompany/my-app
  tag: latest

service:
  type: ClusterIP
  port: 80

Instead of hardcoding values into Kubernetes YAML, templates reference them:

image:
  repository: {{ .Values.image.repository }}
  tag: {{ .Values.image.tag }}

Templates

Helm uses the Go template engine.

Example Deployment:

spec:
  replicas: {{ .Values.replicaCount }}

containers:
- image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

When you install the chart:

helm install myapp . \
  --set replicaCount=5 \
  --set image.tag=v2

Helm generates:

replicas: 5

image:
  mycompany/my-app:v2

Managing Helm Charts

Install:

helm install my-app .

Upgrade:

helm upgrade my-app .

Rollback:

helm rollback my-app <revision>

Uninstall:

helm uninstall my-app

Codex - a.k.a. ChatGPT's AI Agent

Rodel Talampas — Thu, 02 Jul 2026 08:24:49 +0000

Codex is OpenAI's AI coding agent, and ChatGPT is the interface you can use to interact with it. That's the difference.

As a software engineer, software development has gone through drastic shifts over the decades. We moved from assembly language to high-level programming languages, from waterfall to Agile, from on-premise infrastructure to cloud computing, and from manual deployments to DevOps and continuous delivery.

The next major shift is the emergence of AI coding agents.

Rather than simply generating code snippets, modern coding agents can understand an entire codebase, plan changes, execute them, run tests, fix issues, and explain their reasoning. One of the leading tools in this space is Codex.

What is Codex?

Codex is an AI-powered software engineering agent designed to help developers work directly with their source code.

Unlike traditional AI assistants that answer questions or generate isolated functions, Codex operates much more like another engineer on your team. It can:

Explore an existing repository
Understand project architecture
Make changes across multiple files
Execute commands
Run tests
Fix compilation errors
Refactor code
Generate documentation
Create pull-request-ready changes

Instead of asking "How do I implement JWT authentication?", you can ask Codex:

"Implement JWT authentication across this Express application using our existing middleware patterns."

Codex then performs the work inside your repository rather than simply describing how it could be done.

From AI Assistant to AI Engineer

Many developers have used AI chatbots to generate code snippets.

That workflow typically looks like this:

Developer
      │
      ▼
Copy code into ChatGPT
      │
      ▼
Receive code
      │
      ▼
Paste into IDE
      │
      ▼
Fix compilation errors
      │
      ▼
Repeat

Codex changes the workflow entirely.

Developer
      │
      ▼
Describe the task
      │
      ▼
Codex explores repository
      │
      ▼
Implements changes
      │
      ▼
Runs tests
      │
      ▼
Fixes issues
      │
      ▼
Produces ready-to-review changes

The interaction becomes goal-oriented instead of code-oriented.

Understanding the Entire Codebase

One of Codex's biggest strengths is repository awareness.

Rather than treating every prompt independently, Codex understands:

project structure
frameworks
existing coding conventions
dependency management
architecture
naming conventions
testing framework
deployment configuration

For example, in a large Node.js monorepo, Codex can recognize:

apps/
packages/
shared/
infra/
docs/
.github/

It understands how these components interact and modifies only the areas relevant to the requested task.

This dramatically reduces the amount of context developers need to manually provide.

Working Like a Real Engineer

A typical software task rarely involves writing one function.

Consider a request such as:

"Add audit logging whenever an invoice is approved."

A human engineer would likely:

locate the approval endpoint
identify the service layer
update the database model
modify unit tests
update integration tests
document the API
verify linting
run the test suite

Codex follows a remarkably similar workflow. Rather than generating a single function, it works through the complete implementation.

Skills and Project Memory

One of the most useful capabilities of Codex is its support for project-specific guidance.

Teams can provide instructions that describe:

coding standards
architectural principles
testing requirements
security practices
repository structure
naming conventions

This allows Codex to behave consistently across an organization.

For example, instructions may specify:

Always use dependency injection.
Never access the database directly from controllers.
Write unit tests before integration tests.
Use repository pattern.
Follow Domain-Driven Design boundaries.
Never commit generated files.

Instead of repeating these instructions in every prompt, Codex learns them from project configuration.

What is an AGENTS.md

Many teams create an AGENTS.md file that acts as an operating manual for AI coding agents. An AGENTS.md file can include:

project overview
architecture
folder structure
coding conventions
build commands
testing commands
deployment process
common pitfalls
review checklist

For example:

# Project Rules

- Node.js 22
- TypeScript only
- Use Prisma ORM
- No direct SQL
- Unit tests required
- Follow Clean Architecture
- Run npm test before completion

The better this document is maintained, the more consistently Codex performs.

Practical Use Cases

Codex excels at repetitive and complex engineering tasks.

Some examples I've used Codex for include:

Feature development

REST APIs
GraphQL resolvers
UI components
database migrations

Refactoring

rename services
split large classes
introduce dependency injection
improve architecture

Bug fixing

investigate failing tests
locate regressions
repair compilation errors
resolve lint issues

Documentation

generate API documentation
update README files
explain complex modules
document infrastructure

Testing

create unit tests
generate mocks
improve coverage
fix broken test suites

Infrastructure

AWS CDK
Terraform
GitHub Actions
Docker
Kubernetes

Strengths

Codex offers several advantages over traditional AI-assisted coding.

1. Repository Awareness

It understands your project's structure instead of treating every prompt in isolation.

2. Multi-file Editing

Real-world features often require coordinated changes across many files. Codex can handle those changes in one workflow.

3. Command Execution

Codex can build projects, execute tests, run linters, and validate its own work.

4. Consistency

When provided with project instructions, it follows the team's engineering standards.

5. Reduced Context Switching

Developers spend less time copying code into chat windows and more time reviewing completed work.

Am Not trusting AI Agents 100%

I am discussing the uses of Codex and yet, I still don't trust it. Conflicting? Probably. Despite its capabilities, Codex (and all AI Agents) is not a replacement for seasoned software engineers.

Human judgment remains essential for:

system architecture
product design
business requirements
security decisions
trade-off analysis
stakeholder communication
technical leadership

The best results come from treating Codex as an engineering partner rather than an autonomous replacement.

The Future of Software Engineering

AI coding agents represent a significant evolution in software development.

Just as integrated development environments replaced text editors, and CI/CD transformed software delivery, AI agents are reshaping how engineers interact with code.

Rather than focusing on writing every line manually, developers increasingly define objectives, review implementations, and guide architectural decisions while AI handles much of the repetitive engineering work.

Codex exemplifies this shift. It combines repository understanding, code generation, automated validation, and project-specific guidance into a workflow that feels less like using an autocomplete tool and more like collaborating with another engineer.

For organizations willing to invest in clear architecture, strong engineering practices, and well-maintained project documentation, AI coding agents like Codex can significantly accelerate development while allowing engineers to concentrate on solving the problems that require human creativity, judgment, and experience.

Best Practices

Teams adopting Codex tend to achieve better results when they:

Keep repositories well organized.
Maintain clear documentation.
Define coding standards.
Write comprehensive tests.
Provide architectural guidance through AGENTS.md.
Review AI-generated changes before merging.
Use small, well-defined tasks.
Encourage iterative collaboration rather than one-shot prompts.

These practices improve not only AI-generated code but also the overall quality of the software project.

Google SRE Review - Points Taken

Rodel Talampas — Thu, 02 Jul 2026 07:56:03 +0000

This is a continuation of my Google SRE Review - Cheat Sheet. You may want to continue reading this or jump on to the cheat sheet first.

Every person will have their own ideas and perceptions. These are my own.

Few chapter and points that sticked to my mind were:

Service Level Objectives (SLOs)

Probably the most important chapter to me. Defining measurable metrics that tells you about the service you are providing.

Many teams say:

"We need 100% uptime."

Google instead asks:

"How reliable does the service actually need to be?"

This introduces:

SLIs (Service Level Indicators)
SLOs (Service Level Objectives)
Error Budgets

Example:

Instead of saying

"Never have downtime"

you might define

Availability SLO = 99.95%
Latency SLO = 95% of requests under 200 ms

Now engineering decisions become measurable rather than emotional.

Eliminating Toil

Removing repetitive manual work before it consumes the team - sounds familiar?

Google defines toil as repetitive operational work that:

is manual
provides no lasting value
scales linearly with service growth
should be automated

Examples:

restarting services
cleaning queues
rotating logs manually
clicking deployment buttons
manual failovers

If someone performs the same task every week, the system—not the person—is the problem.

This chapter changed how many engineering organizations think about operational work.

Monitoring Distributed Systems

This chapter provides an excellent practical advice.

It explains the famous "Golden Signals":

latency
traffic
errors
saturation

Even today these are the foundation of monitoring systems.

This chapter also explains why dashboards aren't enough—you need actionable alerts.

When to have Alerts

One of the most applicable chapters for all engineers. The book argues against alerting on infrastructure metrics like:

CPU > 80%
Memory > 90%

Instead alert when users are actually affected.

For example:

Alert if:

checkout success rate drops
API latency exceeds the SLO
login failures increase

rather than merely because CPU is high.

Responding to Incidents

What to do when incidents happen? This covers:

incident commanders
communication
postmortems
blameless culture

The most important thing that struct me is "The blameless postmortem philosophy".
This has become an industry standard. Fix the issue than blame someone.

Capacity Planning

How should we (not only Google) predict:

storage growth
CPU usage
memory requirements
traffic growth

before any system fails.

Summary

The biggest lesson isn't technical.

It's this:
Reliability is an engineering problem—not an operations problem.

Instead of hiring more operators, Google (We should) writes more software.

Instead of more runbooks:

automate deployments
automate failover
automate recovery
automate scaling

That's a philosophy you can apply whether you run ten servers or ten thousand.

Google SRE Review - Cheat Sheet

Rodel Talampas — Thu, 02 Jul 2026 07:18:48 +0000

If you're a software engineer, architect, engineering manager, or platform engineer, I consider the Google SRE Book to be one of the handful of books that fundamentally changes how you think about running production systems. It's available for free online: Google Site Reliability Engineering Book.

Unlike many infrastructure books, it isn't about Kubernetes, AWS, or a particular technology. It's about the engineering principles behind operating systems at massive scale.

What makes it different?

Google's definition of SRE is: "What happens when you ask a software engineer to design an operations team."

Instead of treating operations as manual work, the philosophy is:

automate everything possible
measure reliability objectively
accept that failures will happen
continuously improve the system rather than firefight it

That mindset has influenced companies such as Netflix, LinkedIn, Spotify, Airbnb, and many cloud-native organizations.

The Review

This is a table-format companion to the SRE book table of contents. It is meant for quick scanning, not deep reading.

Core Model

Theme	Short Version
Reliability	Treat it as an engineering requirement, not a support outcome.
SRE	Run operations with software engineers and automation.
Risk	Define acceptable failure instead of pretending failure can be eliminated.
Error budgets	Use measurable limits to balance reliability and velocity.
Toil	Remove repetitive manual work before it consumes the team.
Incidents	Respond fast, learn systematically, and improve the system.

Part I - Introduction

Page	What It Says	Why It Matters
Foreword	Reliability work deserves the same rigor as product engineering.	Sets the book’s tone: operations is a discipline.
Preface	Explains the book’s audience and purpose.	Frames the book as a practical operating model, not theory.
Chapter 1 - Introduction	Contrasts classic ops with Google’s SRE approach.	Introduces the “engineers run production” idea.
Chapter 2 - The Production Environment at Google, from the Viewpoint of an SRE	Describes scale, change, and complexity in production.	Shows why manual operations break at scale.

Part II - Principles

Page	What It Says	Why It Matters
Chapter 3 - Embracing Risk	Reliability is risk management with explicit trade-offs.	Makes it possible to choose speed without guessing.
Chapter 4 - Service Level Objectives	SLIs, SLOs, and error budgets define acceptable performance.	Turns reliability into measurable policy.
Chapter 5 - Eliminating Toil	Toil is scalable only by headcount, not software.	Forces teams to invest in automation.
Chapter 6 - Monitoring Distributed Systems	Monitor user-visible symptoms and service health.	Helps catch the failures users actually feel.
Chapter 7 - The Evolution of Automation at Google	Automation evolves from scripts to resilient systems.	Reduces human burden and error rate.
Chapter 8 - Release Engineering	Safe releases rely on testing, staging, rollout, and rollback.	Makes shipping a reliability activity.
Chapter 9 - Simplicity	Simpler systems are easier to run and recover.	Complexity is a reliability tax.

Part III - Practices

Page	What It Says	Why It Matters
Chapter 10 - Practical Alerting	Alerts should be actionable and low-noise.	Prevents pager fatigue and ignored signals.
Chapter 11 - Being On-Call	On-call load must remain sustainable.	Protects both response quality and team health.
Chapter 12 - Effective Troubleshooting	Troubleshooting is structured hypothesis testing.	Reduces time wasted on random guessing.
Chapter 13 - Emergency Response	Incident response needs clear roles and communication.	Keeps teams coordinated under pressure.
Chapter 14 - Managing Incidents	Incidents should be run with process, not improvisation.	Improves recovery speed and consistency.
Chapter 15 - Postmortem Culture: Learning from Failure	Postmortems should be blameless and action-driven.	Converts outages into engineering improvements.
Chapter 16 - Tracking Outages	Outage data should be tracked and analyzed.	Exposes patterns that individual incidents hide.
Chapter 17 - Testing for Reliability	Test the failure modes, not just the happy path.	Finds problems before customers do.
Chapter 18 - Software Engineering in SRE	SRE must build tools and systems, not just operate them.	Software leverage is what makes SRE scalable.
Chapter 19 - Load Balancing at the Frontend	Balance traffic at the edge to improve service behavior.	Helps with latency, availability, and resilience.
Chapter 20 - Load Balancing in the Datacenter	Balance traffic inside the datacenter too.	Prevents hotspots and uneven failure impact.
Chapter 21 - Handling Overload	Use backpressure, shedding, and prioritization.	Avoids catastrophic collapse under high demand.
Chapter 22 - Addressing Cascading Failures	Prevent local failures from spreading.	Limits blast radius and protects the rest of the system.
Chapter 23 - Managing Critical State: Distributed Consensus for Reliability	Shared state needs correctness under fault.	Critical coordination requires hard reliability guarantees.
Chapter 24 - Distributed Periodic Scheduling with Cron	Scheduled work at scale has timing and duplication risks.	Even simple jobs need operational design.
Chapter 25 - Data Processing Pipelines	Pipelines should recover cleanly from partial failure.	Makes large-scale processing dependable.
Chapter 26 - Data Integrity: What You Read Is What You Wrote	Data correctness is part of reliability.	Silent corruption is a production incident.
Chapter 27 - Reliable Product Launches at Scale	Launches need planning, monitoring, and rollback.	Turns product launches into managed risk events.

Part IV - Management

Page	What It Says	Why It Matters
Chapter 28 - Accelerating SREs to On-Call and Beyond	Ramp SREs quickly and deliberately.	Improves team capacity without lowering quality.
Chapter 29 - Dealing with Interrupts	Interrupts damage deep work and throughput.	Protects engineering time from fragmentation.
Chapter 30 - Embedding an SRE to Recover from Operational Overload	Embed SREs to stabilize overloaded teams.	Sometimes the fix is changing the operating model.
Chapter 31 - Communication and Collaboration in SRE	Reliability depends on trust and shared language.	Reduces friction across teams.
Chapter 32 - The Evolving SRE Engagement Model	SRE relationships should change as services mature.	Aligns support model with system reality.

Part V - Conclusions

Page	What It Says	Why It Matters
Chapter 33 - Lessons Learned from Other Industries	Other industries have useful reliability lessons.	Broadens the model beyond software.
Chapter 34 - Conclusion	Reliability comes from engineering discipline and automation.	Reasserts the book’s main argument.

Fast Takeaways

Takeaway	Meaning
Reliability is explicit	Define it, measure it, and manage it.
Automation wins	Manual ops do not scale cleanly.
Error budgets matter	They are the mechanism for trade-offs.
Incidents are data	Learn from them instead of just recovering.
Simplicity helps	Fewer moving parts means fewer failure modes.

Dynatrace monitoring for AWS Lambda

Rodel Talampas — Thu, 02 Jul 2026 06:46:49 +0000

There are many ways to setup the dynatrace agent for Lambdas. The list can be seen below:

I don't have a preferred way to do so, but looking at the way we build our lambdas, the most efficient for us is a combination of environment variables and serverless framework.

Prerequisites

As of 3 Sept 2021, Dynatrace only supports the OneAgent for Lambda which runtime based on Amazon Linux 2 image.

Trace Python, Node.js, and Java Lambda functions
Lambda runtimes - AWS Lambda

Environment Variables

The following base environment variables need to be set into the Lambda’s environment

AWS_LAMBDA_EXEC_WRAPPER = /opt/dynatrace
DT_TENANT = vpc123456
DT_CLUSTER_ID = 1234456789 # Dynatrace Cluster Id
DT_CONNECTION_BASE_URL = https://vpc123456.live.dynatrace.com
DT_CONNECTION_AUTH_TOKEN = dt0a01.vpc123456.b19e9577f4cqerew43f9721ba4282a0d8004ae36bbba9983421231aaa4e
DT_LOGGING_DESTINATION: stdout

To add log monitoring there are language-specific values that need to added:

DT_LOGGING_NODEJS_FLAGS: Exporter=true,LambdaSensor=true
DT_LOGGING_PYTHON_FLAGS  dynatrace=True
DT_LOGGING_JAVA_FLAGS=log-Transformer=true,log-EmbeddedJarClassLoader=true,log-OpenTelemetryUtils=true,log-AsyncClassRetransformer=true,log-ClassValue=true

If the lambda is coded in NodeJS, use DT_LOGGING_NODEJS_FLAGS accordingly, and so on.
These are hard-coded values that really never change unless we change our Dynatrace Tenancy.

Dynatrace Agent

The Dynatrace agent is nothing but a simple Lambda Layer. There are 3 Programming Languages supported at the moment: Java, NodeJS, and Python. Each has its own Lambda Layer ARN. The AWS Region also plays a part on the ARN String Formulation. The 725887861453 being the Dynatrace AWS Account.

NodeJS = arn:aws:lambda:ap-southeast-2:725887861453:layer:Dynatrace_OneAgent_1_215_1_20210326-040705_nodejs:1
Java = arn:aws:lambda:ap-southeast-2:725887861453:layer:Dynatrace_OneAgent_1_215_161_20210428-142723_java:1
Python = arn:aws:lambda:ap-southeast-2:725887861453:layer:Dynatrace_OneAgent_1_215_2_20210326-095702_python:1

Serverless Framework

Depending on how you configure your serverless framework, files to be updated depends on that. In our case, we split out stages (or environment) and serverless yaml.

stages.yml | env.yml

default_env: &default_env
  apm_exec_wrapper: '/opt/dynatrace'
  apm_tenant: vpc123456
  apm_cluster_id: 1234456789 
  apm_base_url: https://vpc123456.live.dynatrace.com
  apm_auth_token: dt0a01.vpc123456.b19e9577f4cqerew43f9721ba4282a0d8004ae36bbba9983421231aaa4e
  apm_layer: arn:aws:lambda:ap-southeast-2:725887861453:layer:Dynatrace_OneAgent_1_215_1_20210326-040705_nodejs:1
  apm_log_dest: stdout
  apm_log_flags: 'Exporter=true,LambdaSensor=true'

On every environment key, add the following line <<: *default_env:

qa:
  <<: *default_env
  ...
  ...

show:
  <<: *default_env
  ...
  ...

prod:
  <<: *default_env
  ...
  ...

This will tell each environment to use the same settings as the default_env.

serverless.yml

Create a custom layer if not yet created, add the following lines

custom:
  # custom environment 
  environment: ${file(./stages.yml):${opt:stage}}
  # dynatrace environment variables
  apm_exec_wrapper: ${file(./stages.yml):${opt:stage}.apm_exec_wrapper}
  apm_tenant: ${file(./stages.yml):${opt:stage}.apm_tenant}
  apm_cluster_id: ${file(./stages.yml):${opt:stage}.apm_cluster_id}
  apm_base_url: ${file(./stages.yml):${opt:stage}.apm_base_url}
  apm_auth_token: ${file(./stages.yml):${opt:stage}.apm_auth_token}
  apm_log_dest: ${file(./stages.yml):${opt:stage}.apm_log_dest}
  apm_log_flags: ${file(./stages.yml):${opt:stage}.apm_log_flags}
  # dynatrace lambda layer
  apm_layer: ${file(./stages.yml):${opt:stage}.apm_layer}

Plugin the Environment variables under the provider layer, create if none

provider:
  ...
  ...
  environment:
    ...
    ...
    # dynatrace environment variables
    AWS_LAMBDA_EXEC_WRAPPER: ${self:custom.environment.apm_exec_wrapper}
    DT_TENANT: ${self:custom.environment.apm_tenant}
    DT_CLUSTER_ID: ${self:custom.environment.apm_cluster_id}
    DT_CONNECTION_BASE_URL: ${self:custom.environment.apm_base_url}
    DT_CONNECTION_AUTH_TOKEN: ${self:custom.environment.apm_auth_token}
    DT_LOGGING_DESTINATION: ${self:custom.environment.apm_log_dest}
    DT_LOGGING_NODEJS_FLAGS: ${self:custom.environment.apm_log_flags}
  ...
  ...
  ...

On every function that is defined, add the Dynatrace Lambda Layer

functions:
  ...
  consume:
    handler: ...
    layers:
       - ${self:custom.apm_layer}
    ...
    ...

Dynatrace UI

When a Lambda is fully integrated into Dynatrace you will be able to see a direct link to the Lambda Cloudwatch Logs and it will be part of the Dynatrace Service.

Sending Custom / Error Events to Dynatrace

Rodel Talampas — Thu, 02 Jul 2026 06:32:14 +0000

Alert and Notifications can be sent to Dynatrace for a Single Source of Truth against Errors and Issues encountered within an organization's applications.

More detail can be found at Events API v1 - POST an event and
Events API v2 - POST an event.

Events can be sent to Dynatrace using the Events API. For this tutorial, we will be using Events API v2 as it is very easy to use. The Events API v1 though is more precise based on my opinion. Will look into it more in another documentation post.

Requirements:

Dynatrace API Token that can Ingest Events and Write Entities
Dynatrace Events API URL
Dynatrace Events API Json Body

API Token

API URL

The API URL is https://.live.dynatrace.com/api/v2/events/ingest.

Request Body

Basic Event structure is below.

{
  "eventType": "AVAILABILITY_EVENT",
  "title": "string",
  "startTime": 1,
  "endTime": 1,
  "timeout": 1,
  "entitySelector": "string",
  "properties": {}
}

eventType - is the type of event you want to post to Dynatrace
title - is the Name of the Problem that will be displayed on the Problems Page
startTime - start time of the event in UTC Milliseconds
endTime - the end time of the event in UTC Milliseconds
timeout - the amount of time, in seconds, the event will be highlighted on the Problems Page
entitySelector - set of entities you want the event to be associated with, this is an entity query selector format
properties - a map of entity properties

Only eventType and title are required and the rest are optional. If you want to attach the event to specific resources, entitySelector is your friend. If you don’t specify the timeout, 15 minutes is the default.

Sample Request

{
  "eventType": "ERROR_EVENT",
  "title": "Error Test",
  "timeout": 2,
  "entitySelector": "type(service),entityName(\"app-prod - app-lambda-instance\")",
  "properties": {}
}

Singleton Connection with Transactions in MongoDB

Rodel Talampas — Sat, 23 Sep 2023 00:05:47 +0000

I was looking at some patterns on how to use MongoDB Transactions but I want it to be a common wrapper and should be simple enough for nodejs beginners (like me) to understand. I saw some functions accepting another, function with multiple parameters, as a parameter, but you need to take care of overloading cases.

Thinking of a simple solution, why not just wrap all arguments into a single variable like a map. This may not work for others but certainly works on our case.

First, I need to make sure that I only have 1 DB Connection always. Hence I created a Singleton class.

const mongoose = require('mongoose');
...
...

// Define Singleton DB Connection Class
class Connection {
  constructor() {
    if (!Connection.instance) {
      mongoose.connect(config.mongoose.url, config.mongoose.options);
      this.conn = mongoose.connection;
      this.conn.on('error', () => logger.error.bind(console, 'connection error'));
      this.conn.on('open', () => logger.info(`Connected to MongoDB ${config.mongoose.url} for Transaction...`));
    }
  }
}

module.exports = new Connection();

I will use this class in every part of my systems and it will ensure that I won't be having multiple cases of DB connection.

Now to create a transaction wrapper, I do this. This is a self-managed transaction meaning I dont need to call commit and rollback. But if you want to manually handle each commit and rollback, you may do so here as well.

const db = require('./connection');

const withTransaction = async (fn) => async (map) => {
  const session = await db.conn.startSession();
  await session.withTransaction(fn(map), { session });
  session.endSession();
};

module.exports = withTransaction;

To call do something like this:

async function saveFunction(map) {
  //.. implementation
  const { var1, var2 } = map;
  // use the var1, var2 here ....
  // call mongodb CRUD here 
}

// service call
const save = async (map) => {
  withTransaction(saveFunction(map));
};

Hoping to get some comments so that I can improve this wrapper in the future.

Authorisation using NodeJS, AzureAD and MongoDB (Part 1 - Design)

Rodel Talampas — Tue, 17 Jan 2023 01:04:19 +0000

Application administrators use roles to group together permissions and assign them to individual users or groups of users. These permissions determine the actions that a user is able to take within a particular software. The roles that are assigned to a user depend on their tasks within the application itself. For instance, in a simple inventory application, users who are analysts might only need permissions to browse and download, but not to modify or change information. However, in an analyst group, a senior analyst may be granted full permissions to allow them to modify existing data or create/upload new inventory data.

In general, roles are used to make it easier to manage permissions by allowing administrators to assign a set of permissions to a user or group of users all at once, rather than having to assign individual permissions one at a time. This can make it more efficient to set up and manage access controls within an application.

A role is therefore defined as a collection of permissions that are grouped together and assigned to a user or group of users. A permission, on the other hand, is a specific action or set of actions that a user is allowed to take within a particular application.

I am designing an integration with AzureAD, and MongoDB collections using NodeJS. Roles/Groups will be created in AzureAD that will be synced in MongoDB for application usage. Each role will have its own permissions and Users can have one or more roles.

Data Definition

Permission Schema

const permissionSchema = mongoose.Schema(
  {
    permission: {
        type: String,
        unique: true,
        required: true
    }
  }
  {
    timestamps: true,
  }
);

const Permission = mongoose.model('Permission', permissionSchema);

Role Schema

const roleSchema = mongoose.Schema(
  {
    role: {
        type: String,
        unique: true,
        required: true
    },
    permissions: [
      {
        permissionId: {
          type: mongoose.Schema.Types.ObjectId,
          ref: 'Permission',
        },
      },
    ]
  }
  {
    timestamps: true,
  }
);

const Role = mongoose.model('Role', roleSchema);

User Schema

const userSchema = mongoose.Schema(
  {
    firstName: {
      type: String,
      required: true,
    },
    lastName: {
      type: String,
      required: true,
    },
    phone: {
      type: String,
      required: true,
    },
    email: {
      type: String,
      required: true,
      unique: true,
      lowercase: true,
    },
    roles: [
      {
        roleId: {
          type: mongoose.Schema.Types.ObjectId,
          ref: 'Role',
        }
      },
    ],
  },
  {
    timestamps: true,
  }
);

const User = mongoose.model('User', userSchema);

Management Process

Sync Process

On Load

GIT Flow

Rodel Talampas — Sun, 15 Jan 2023 03:58:58 +0000

Gitflow Workflow is a Git workflow that helps with continuous software development and implementing DevOps practices. It was first published and made popular by Vincent Driessen at nvie. The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects. This is suited for projects that releases are based on a schedule.

Gitflow workflow is not for everybody. But for those who loves and using it below are some shortcuts that can help you understand what is this workflow.

Installing git-flow plugin for git client is plain and simple. For mac-os, easiest to install is brew install git-flow.

Basic Commands and Configuration

git flow init
git flow feature start/finish
git flow release start/finish
git flow hotfix start/finish
git merge

Basic Configuration Flow

Concurrent Configuration Flow

The overall flow of Gitflow is:

A develop branch is created from main.
A release branch is created from develop.
Feature branches are created from develop.
When a feature is complete it is merged into the develop branch.
When the release branch is done it is merged into develop and main.
If an issue in main is detected a hotfix branch is created from main.
Once the hotfix is complete it is merged to both develop and main and/or feature branches.

Git vs Git Flow Commands

These are base guidelines that corresponds to some of the git commands used by the git-flow wrapper client. These commands are not fixed in stone. Depending on situations, there are steps that can be altered or change within the course of the development.

Create a develop branch on your local if one doesn’t exists in the repo.

Initialisation (specific for git flow only)

$ git flow init
Which branch should be used for bringing forth production releases?
   - develop
   - master
Which branch should be used for integration of the "next release"?
   - master
   - develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [../../.git/hooks]

Creating feature branches

git flow feature start <branch>

git checkout develop                     # this switches the branch to the develop branch, do a `git pull` to make sure it is latest
git checkout -b feature/<branch>         # this creates a branch named 'feature/<branch>'
git push --set-upstream origin feature/<branch>   # push changes to git repo to a new 'feature/<branch>'

Completed a feature

git flow feature finish <branch>

git checkout feature/<branch>            # this switches the branch to the 'feature/<branch>' if you are not in it, do a `git pull` to make sure it is latest
git checkout develop                     # this switches the branch to the develop branch, do a `git pull` to make sure it is latest
git merge feature/<branch>               # merge feature/branch to develop
git push                                 # push changes to git repo in develop branch

Creating a release branch

git flow release start <branch>

git checkout develop                     # this switches the branch to the develop branch, do a `git pull` to make sure it is latest
git checkout -b release/<branch>         # this creates a branch named 'release/<branch>'
git push --set-upstream origin release/<branch>   # push changes to git repo to a new 'release/<branch>' and this will trigger the BUILD to QA

Release Completed

git flow release finish <branch>

git checkout release/<branch>            # this switches the branch to the 'release/<branch>' if you are not in it, do a `git pull` to make sure it is latest
git checkout develop                     # this switches the branch to the develop branch, do a `git pull` to make sure it is latest
git merge release/<branch>               # merge release/branch to develop
git push                                 # push changes to git repo in develop branch
git checkout main                        # this switches the branch to the main branch, do a `git pull` to make sure it is latest
git merge release/<branch>               # merge release/branch to main
git push                                 # push changes to git repo in main branch
git push --tags                          # push tags
git push -d origin release/<branch>      # delete remote branch

Creating a hotfix

git flow hotfix start <branch>

git checkout main                        # this switches the branch to the main branch, do a `git pull` to make sure it is latest
git checkout -b hotfix/<branch>          # this creates a branch named 'hotfix/<branch>'
git push --set-upstream origin hotfix/<branch>   # push changes to git repo to a new 'hotfix/<branch>' and this will trigger the BUILD to QA

Hotfix Completed

git flow hotfix finish <branch>

git checkout hotfix/<branch>             # this switches the branch to the 'hotfix/<branch>' if you are not in it, do a `git pull` to make sure it is latest
git checkout develop                     # this switches the branch to the develop branch, do a `git pull` to make sure it is latest
git merge hotfix/<branch>                # merge hotfix/branch to develop
git push                                 # push changes to git repo in develop branch
git checkout main                        # this switches the branch to the main branch, do a `git pull` to make sure it is latest
git merge hotfix/<branch>                # merge hotfix/branch to main
git push                                 # push changes to git repo in main branch

Enabling PlantUML in Visual Studio Code

Rodel Talampas — Sun, 15 Jan 2023 03:42:45 +0000

PlantUML is a component that allows you to quickly write the following diagrams in plain and simple intuitive language - a.k.a. Diagram-As-Code.

Sequence diagram
Usecase diagram
Class diagram
Object diagram
Component diagram
Deployment diagram

There are many similar tools out there. PlantUML is free to use and was created using Java and GraphViz. A simple way of using it is to download the plantuml.jar and run it to open PlantUML's graphical user interface. There is no need to unpack or install anything.

Most developers use Visual Studio Code, why not install its plugin:

Browse the plugin and click install. After installing the plugin, there is a need to install GraphViz binary. You can follow the link to install it. For mac users, easy to run brew install graphviz.

When all done, create a test file test.puml and add the following code

@startuml Basic Sample
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

Person(admin, "Administrator")
System_Boundary(c1, "Sample System") {
    Container(web_app, "Web Application", "C#, ASP.NET Core 2.1 MVC", "Allows users to compare multiple Twitter timelines")
}
System(twitter, "Twitter")

Rel(admin, web_app, "Uses", "HTTPS")
Rel(web_app, twitter, "Gets tweets from", "HTTPS")
@enduml

Press Option + D in Mac or Alt-D for other OS's, should give the following output:

Blackbox - Secrets amongst your code

Rodel Talampas — Sun, 15 Jan 2023 03:29:21 +0000

One of the major concerns amongst developers is how to store shared secrets. Storing secrets in a config file along with your source code is problematic as it can compromise privacy. Storing it outside without proper process or documentation can tend to be forgotten (not saying this is not good as using SAAS tools like Vault is the way to go). But in case you have a limited budget and limited capability, using GPG is the way to go. Here comes Blackbox.

For any secrets you want to store alongside the source code, we should limit the risk of intentional or accidental sharing by encrypting secrets.

You should encrypt these data in your repositories:

SSH keys
Private keys
Usernames and passwords

Installation
Blackbox is a GPG-based encryption tool for Git. Assuming Homebrew is installed in a mac or linux machine, the command below is sufficient. Otherwise look for the Blackbox link above for more information

brew install blackbox

GPG Keys
GnuPG, also known as GPG, is a free, full implementation of the OpenPGP standard as outlined in RFC4880 (also known as PGP). It enables you to encrypt, sign and authenticate data and communication.

gpg --full-generate-key

When key has been generated, look through the messages that displayed on the screen and find your Key ID.

gpg: key <key_id> marked as ultimately trusted

Generate a revocation certificate for the primary public key. If your private key is compromised or lost, this revocation certificate may be published to notify others that the public key should no longer be used.

gpg --output revoke.asc --gen-revoke <key_id>

The revoke.asc file is stored in your user directory. Store the certificate key somewhere safe, ideally keypass or macpass.

Add your public key to the keys server so that others have verify it.

gpg --keyserver=pgp.key-server.io --armor --send-keys <key_id>

Browse to pgp.key-server.io and search for your name to see if your gpg key is there or not.

In case pgp.key-server.io is not registering your key, use other public known keyservers:

Using Blackbox

Make a repository a blackbox repo

$ blackbox_initialize 
Enable blackbox for this git repo? (yes/no) y
VCS_TYPE: git

NEXT STEP: You need to manually check these in:
      git commit -m'INITIALIZE BLACKBOX' .blackbox /talampas/development/repo/.gitignore

Add a new user in the blackbox repo

There is a need to look for the user's key to verify and add it in your keychain

gpg --keyserver keys.openpgp.org --search-key <personA@email.com | fingerprint>

Add the user as an admin of blackbox for that repo.

blackbox_addadmin <personA@email.com>

Update all secret files to incorporate the new key registered

blackbox_update_all_files

Do a commit / push for the repo

# the next two lines are not required if no other files where edited
git add .
git commit -m"Add new user - personA"
# Required to push changes
git push

Updating Blackbox Encrypted files

If there is a need to update the secrets in the encrypted file, follow the steps below

Open the file for editing

blackbox_edit_start <filename>.gpg

End the Editing process

blackbox_edit_end <filename>

Same as above, commit and push when you're done

Developer Setup for Mac

Rodel Talampas — Sun, 15 Jan 2023 02:49:44 +0000

You have a new MacBook! Congrats!

You need to setup your mac to be Developer Ready and don't know what to do. You are in the right place. I have compiled a list of installation scripts for a typical Developer to kick start a Developer Machine.

macOS Updates
Before installing any applications you require, it is a good idea to update the Operating System. As much as possible, I try to have the latest version of the MacOS with patches.

XCode
First step, you need to install XCode which is Apple's integrated development environment for MacOS. You can download it in the Apple Store free of charge. There is a command line instruction to install xcode. Open a new terminal and type the code below.

xcode-select --install

Homebrew
I pretty much use Homebrew or brew to install anything on my MacBook and Linux Machines. Run the following commands to download and install brew and upgrade it, though there should not be anything to upgrade. No harm doing though.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew upgrade

Python 3 and JQ
Next to Java, Python is probably my next go to programming language. I used python a lot to build client tools and serverless applications. JQ is a tool to parse JSON Strings and I predominantly use this with python and aws. VirtualEnv is my favorite environment configuration for python. Python virtualization is a must if you are going to develop using python. Python is also a requirement for some client tools like awscli.

brew install python3
curl https://bootstrap.pypa.io/get-pip.py | python3
pip install virtualenv
brew install jq

AWS
I work mostly with AWS Cloud hence I require AWS Client that uses Python. If you are not in AWS, you may skip this part. This command will help you install and upgrade your aws client. I have both added awscli and awscli-local.

brew install awscli
brew link awscli --overwrite 
pip install awscli-local

Docker Desktop
Since Mac-OS is not a linux distro, it is impossible to install docker base binaries. Don't fear though, docker created a desktop installer for mac here.

Localstack
Since AWS is a paid service, creating infrastructure usually cost $$$ if you are unable to use the free-tier. To test out my infrastructure-as-code scripts, I spin up a Mock AWS Service called localstack.

pip install localstack

Terminal
MacOS' terminal is nice, no complains about it. As a developer, sometimes I would like to work on multiple Terminals but within the same window. Hence, I require some Split functionality and iTerm2 has that capability. ZSH is the prefered console of MacOS terminal nowadays.

chsh -s /bin/zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
brew install iterm2

NodeJS
As much as I don't want to tackle NodeJS, this programming language is pretty much use anywhere from backend processing to UI development using frameworks such as react or angular or vue. Somehow, I got the hang of this programming framework as well. I've been using this in my side projects. Yarn is my favourite package manager. You can install any PM you want.

brew install node
brew install nvm
brew install yarn

Serverless Framework
Between AWS Severless Application Model (SAM) and Serverless Framework (SLS), I prefer the latter. Both framework patterns their syntax from AWS Cloudformation, but I firmly believe Serverless Framework is more mature. Don't get me wrong, I love AWS. SLS is my own choice.

curl -o- -L https://slss.io/install | bash

Infrastructure As Code
I've been using Cloudformation ever since I had moved to the cloud. But when I've learned Terraform, I seldom touch Cloudformation unless I am working with SLS above.

brew install terraform

Git and Git Flow
In one way or another, you might be using a Source Code Versioning System like github or gitlab. A git client is required.I have added a plugin called git flow for the purpose of following a release framework.

brew install git
brew install git-flow

Database Connectivity Tool
We use databases to persist data. I've used a lot of databases in my career, from MS SQL Server to Oracle to Postgres or MySQL. I don't have a clear favourite but for this tutorial, I will go with the easiest postgres. Take note, this is only a connection tool, you may ask how do you install your database? As I've mentioned above, I would containerise my databases, read it here.

brew install libpq

Miscellaneous Tools
The rest of the apps in this code block are optional. Some are required due to the fact that I am using it like gpg for encryption and java being my favourite programming language. It is to your discretion if you will install them or not. Atom here is a good IDE but since Microsoft bought Github, it is not being developed anymore and Visual Studio Code Express is the preferred IDE.

brew install atom
brew install kubectx
brew install gpg
brew install blackbox
brew install java
brew cask install eclipse-java
brew cask install postman
brew install macpass
brew install credstash

Full Script

For all the apps that can be installed using the terminal, I've compiled a full list below.

# Install Homebrew - preferred apps installation manager
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew upgrade

# Install Python 3
brew install python3
# update pip 
curl https://bootstrap.pypa.io/get-pip.py | python3
# install virtualenv for python, if you dont use python no need to install this
pip install virtualenv
# install jq
brew install jq

# Install AWS Client using Homebrew
brew install awscli
# if there is already an install client, ovewrite its softlink
brew link awscli --overwrite 
# install aws client for localstack
pip install awscli-local


# install docker using docker installer
brew cask install docker

# install localstack
pip install localstack

# preferred mac terminal
brew install iterm2

# CHANGE TO zsh, if you want too.
chsh -s /bin/zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# all about NODEJS
brew install node
brew install nvm
brew install yarn
# if your office has certificate restrictions, you may want to remove ssl restriction
yarn config set strict-ssl false

# for AWS lambda deployment, we prefer Serverless Framework
curl -o- -L https://slss.io/install | bash

# for Infrastructure as Code
brew install terraform

#install git
brew install git

# install git flow
brew install git-flow

# postgres tool
brew install libpq 

# this is my preferred editor, if you dont like it dont install it
brew install atom

# some passwords used for OPs are in keepass and macpass is the keepass version for mac
brew install macpass

# we do use kubernetes, this is required to connect to it
brew install kubectx

# install gpg 
brew install gpg

# install Java
brew install java
brew cask install eclipse-java
brew cask install postman

# password tools
brew install blackbox
brew install credstash