• Viability: Plain Docker Compose remains a viable option for production workloads in 2026, especially for single-node deployments, edge computing, or internal services that don't require the complexity of Kubernetes.
• Addressing Operational Gaps: Success depends on manually closing gaps that Compose leaves open:
  • Orphan Containers: Use the --remove-orphans flag during up and down commands to ensure containers removed from the YAML file are actually stopped and cleared.
  • Disk Management:
    • Implement log rotation in daemon.json (e.g., max-size: 10m) to prevent unbounded log files from filling disks.
    • Establish a schedule for pruning unused images and build caches (docker image prune).
    • Exercise caution with docker volume prune to avoid accidental data loss from detached volumes.
  • Health Checks: Native Docker health checks only report status; they do not automatically restart containers. Use a sidecar like docker-autoheal or a dedicated agent to act on "unhealthy" states.
  • Image Pinning: Avoid using mutable tags like :latest. Instead, pin images using their immutable SHA256 digests (image: myapp@sha256:...) to ensure consistency across different host pulls.
• Security Risks: Mounting /var/run/docker.sock provides a container with effective root privileges on the host. Minimize its use, consider rootless Docker, or use a socket proxy to limit API exposure.
• Scaling Updates: For managing multiple environments, tools like Watchtower (polling) or pull-based agents are necessary, as Docker has no native mechanism to "push" updates to remote Compose hosts.
• Growth Path: When requirements outgrow a single node, Kubernetes is the industry standard for migration. Docker Swarm is an alternative that reuses Compose syntax but has a smaller ecosystem.

使用Terraform和Helm进行云基础设施部署体现了现代DevOps实践在AI安全平台中的应用。这种基础设施即代码(IaC)方法确保了部署的可重复性和一致性，同时支持阿里云等特定云平台，显示了平台对生产环境的适应性。

令人惊讶的是：GitHub Actions的使用量在短短两年内增长了四倍多，从2023年的每周5亿分钟激增至现在的21亿分钟。这表明自动化CI/CD流程的采用速度远超预期，反映了DevOps实践在AI时代的加速演变。

• The author accidentally dropped their production database while using an AI agent (Claude Code) to manage AWS infrastructure via Terraform.
• The incident occurred because the author attempted to merge two separate projects into one, ignoring the AI’s advice to keep them separate to save on VPC costs.
• The AI agent generated a Terraform plan that included deleting existing resources to recreate them under the new unified structure.
• The author authorized a terraform apply and subsequently a terraform destroy without carefully reviewing the plan, mistakenly believing the agent was only cleaning up temporary resources.
• Because the author had not set up external backups and the automated RDS snapshots were deleted along with the instance, all data was initially lost.
• AWS Support was miraculously able to recover a snapshot, though the author now pays 10% more for AWS due to implementing more robust (and expensive) backup and security measures.
• The "lesson learned" highlights the dangers of "vibe engineering"—relying on AI agents to execute destructive commands without human oversight or a deep understanding of the underlying tools.

Hacker News Discussion

• Negligence Over AI Risk: Many commenters argue that the issue wasn't the AI itself, but the author's decision to bypass standard safety procedures, such as reviewing terraform plan before execution.
• Critique of "Vibe Engineering": Users criticized the trend of letting LLMs handle infrastructure (IaC) without the human operator understanding the deterministic tools they are using.
• Infrastructure Over-engineering: Several participants pointed out that the project seemed over-engineered with AWS and Terraform when a simple VPS or SQLite database might have sufficed and been easier to manage.
• AWS Data Recovery: Former AWS employees expressed surprise that support could recover the data, noting that AWS typically treats a user-initiated deletion as a final security command to wipe the data.
• The Importance of Staging: A recurring theme was that major migrations should be tested in a staging environment first; running unverified AI-generated scripts directly against production was labeled as "insanity."

Summary: I Like GitLab

• Initial Adoption: The author originally chose GitLab because it offered free private repositories when GitHub still charged for them, leading to a long-term workflow integration.
• Integrated Container Registry: One of the most valued features is the built-in Docker registry, which eliminates the need for separate accounts, external access tokens, and concerns about Docker Hub pull limits.
• CI/CD Maturity: GitLab's "config as code" (.gitlab-ci.yml) is praised for being versioned with the repo and offering extensive documentation, though the sheer volume of options can be overwhelming.
• Runner Flexibility: While shared runners are reliable for free workloads, the author finds setting up custom runners on private VPS instances to be straightforward.
• Performance Issues: The web interface is consistently described as sluggish and slow compared to GitHub, creating "constant friction" during long sessions.
• Feature Bloat: GitLab attempts to be an all-in-one DevOps platform; while the author only uses about 10% of the features, they acknowledge the benefit of having advanced tools (like security scanning) available if needed.
• Workflow Split: The author uses GitLab as a "digital workshop" for private, messy experiments and reserves GitHub for public-facing collaboration and visibility.

Hacker News Discussion

• Corporate Shift & Quality: Several users noted that since its IPO, GitLab seems to prioritize "enterprise checklist" features and AI over fixing long-standing bugs and improving general UI polish.
• The "Sluggishness" Debate: A major point of discussion was GitLab's slow performance. Some attribute this to the "Ruby on Rails tax," though others pointed out that GitHub and Shopify also use Rails successfully, suggesting the issue lies in GitLab's specific architecture.
• Rise of Alternatives: Many commenters mentioned switching to Forgejo or Gitea for self-hosting, citing significantly lower resource requirements (up to 90% less) and near-instant page loads.
• The "80/20" Problem: Critics argued that GitLab often builds 80% of a feature to satisfy marketing requirements but leaves the remaining 20% of "polish" unfinished, leading to a "meme" of finding 5-year-old open bug reports for basic issues.
• Storage Exploits: There was a technical side-discussion about the 10GB project limit; users noted that because the limit often applies per-layer rather than per-registry, it can sometimes be bypassed for very large images.
• Website Appreciation: Many participants took a tangent to praise the blog's design, specifically its minimalist, terminal-like aesthetic and "markdown-as-markdown" presentation.

• Article argues pre-commit hooks are fundamentally broken due to running on working tree, not index, failing to catch unstaged changes.
• Hooks interfere with rebases, interactive commits, and external branches without hooks, requiring frequent --no-verify usage.
• Demonstrates issues via Rust fizzbuzz example: formatting fixes don't stage, existing unformatted code blocks commits, rebases fail unexpectedly.
• Recommends pre-push hooks instead: run on index, keep fast/reliable (no network/credentials), quiet, manual setup via docs.
• Additional pitfalls: slow/unreliable implementations, modifying commits, not running on stashes; prefers commits over stashes for branching.

Hacker News Discussion

• Users debate pre-commit vs. pre-push/CI: enforce in CI for reliability, use hooks to reduce churn but not guarantee (e.g., secrets in pre-push).
• Workflows vary: WIP commits common, rebase/squash before push; hooks break rebases needing full checkouts (e.g., cargo clippy).
• Editor integration preferred for formatting/linting; force consistency in teams but allow bypass for power users.
• Alternatives: git filters for formatting, jj run for future; personal setups run heavy local checks but optional for contributors.
• Defenses of pre-commit frameworks (speed, environments) countered by author; prefer CI for shared enforcement over local hooks.

Brief summary

Authress avoided downtime during the AWS us-east-1 outage by implementing a multi-region, redundant infrastructure with automated DNS failover using custom health checks, edge-optimized routing, and robust anomaly detection, backed by rigorous testing and incremental deployments to minimize risk and impact. Their system design assumes failure is inevitable and focuses on quick detection, seamless failover, and minimizing single points of failure through automation and continuous validation.

Long summary

• Authress experienced a major AWS us-east-1 outage affecting DynamoDB and other critical AWS services.
• They run infrastructure in us-east-1 due to customer location demands, despite known risks.
• AWS services like CloudFront, Certificate Manager, Lambda@Edge, and IAM control planes are centralized in us-east-1, impacting availability during incidents.
• Aiming for a 5-nines SLA (99.999% uptime) requires more than relying on AWS SLAs alone, which are insufficient.
• Simple single-region architectures fail to meet high reliability due to frequent AWS incidents.
• Authress recognizes "everything fails all the time" and designs systems assuming failure.
• Retry strategies are mathematically analyzed; third-party components must have at least 99.7% reliability to be usable.
• Multi-region redundant infrastructure with DNS failover via AWS Route 53 health checks enables automatic failover.
• Custom health checks validate actual service health beyond default DNS checks.
• Edge-optimized architecture using CloudFront and Lambda@Edge improves latency and provides better failover options.
• DynamoDB Global Tables replicate data across regions to support failover.
• Rigorous testing and validation, including application-level tests, mitigate risks of bugs in production.
• Incremental deployment (customer buckets) limits impact by rolling out changes gradually.
• Asynchronous validation tests check consistency across databases after deployments.
• Anomaly detection is used to identify meaningful incidents impacting business logic, beyond mere HTTP error codes.
• Customer support feedback is integrated into incident detection to catch undetected or gray failures.
• Security measures include rate limiting, AWS WAF with IP reputation lists, and blocking suspicious high-volume requests.
• Resource exhaustion prevention is critical, with rate limiting implemented at multiple infrastructure layers.
• Infrastructure as Code (IaC) deployment differences across regions and edge leads to challenges in consistency.
• Despite all these measures, achieving a true 5-nines SLA is extremely challenging but remains a core commitment.

Summary of HN discussion

https://news.ycombinator.com/item?id=45955565

• The discussion highlights concerns about automation and Infrastructure as Code (IaC) being potential failure points, emphasizing the challenge of safely updating these systems.
• Rollbacks are rarely automatic; often, knowing in advance to avoid certain rollouts is preferable as automated rollbacks can worsen failures.
• Simple, less complex infrastructure changes are preferred to reduce human error, which is the leading cause of incidents.
• There is skepticism about the reliability of Route 53 failover in practice, with concerns about its failure modes and the complexity of multi-cloud DNS failover.
• Some contributors suggest modular IaC approaches (Pulumi, Terragrunt) for safer, repeatable deployments but warn about added complexity.
• Retry logic in failures is criticized; retries may not improve reliability linearly due to correlated failures and overall system overload during outages.
• Latency and client timeout constraints limit the practical number of retries possible.
• DNS is acknowledged as a single point of failure with caching and failover timing challenges.
• Multi-cloud failover at DNS level is complex, costly, and not widely implemented due to infrastructure and coordination requirements.
• Gray failures (where the system reports healthy but customers experience issues) and the difficulty in knowing real incident impact without customer feedback are noted.
• Customer support is critical in incident detection since automated systems cannot catch every failure.
• Detailed monitoring via CloudFront and telemetry helps identify actual service issues during outages.
• Overall, the theme is the difficulty in achieving perfect reliability, the importance of simplicity, and the need for layered detection and response strategies to manage failures.

Configure Fargate tasks as gitlab runners, with many code samples.

tl;dw (best DevOps tools in 2023)

1. Low-budget cloud computing : Civo (close to Scaleway)
2. Infrastructure and Service Management: Crossplane
3. App Management - manifests : cdk8s (yes, not Kustomize or Helm)
4. App Management - k8s operators: tie between Knative and Crossplane
5. App Management - managed services: Google Cloud Run
6. Dev Envs: Okteto (yeap, not GitPod)
7. CI/CD: GitHub Actions (as it's simplest to use)
8. GitOps (CD): Argo CD (wins with Flux due to its adoption rate)
9. Policy Management: Kyverno (simpler to use than industry's most powerful tool: OPA / Gatekeeper)
10. Observability: OpenTelemetry (instrumentation of apps), VictoriaMetrics (metrics - yes not Prometheus), Grafana / Loki (logs), Grafana Tempo (tracing), Grafana (dashboards), Robusta (alerting), Komodor (troubleshooting)

운영환경 데이터베이스의 스냅샷을 떠서 개발용 데이터베이스를 갖추는 전문 도구이다. Postgres 을 지원한다. 초기단계의 제품이라 Postgres 관련 기능을 먼저 개발한 후에 MySQL 등도 지원할 모양이다.

DB marlin. 데이터베이스 전용 모니터링 솔루션. DataDog 보다 나을까? APM과 연계하는 편이 모니터링의 효과가 가장 좋을 듯 한데 전용 솔루션은 약하지 않을까?

Devops With Nix tips & practices.

GitLab Bot source code.

Unchecked if it supports .NET Framework.

Tutorial successfully combining NixOS & TerraformDev

This is important

DevOps team roles and responsibilities

In a DevOps team, everyone participates in software development and is responsible for its early release. Characteristic and different from other development methods is a process that we call Continuous Deployment. Which roles do we recognize within a team, and which skills are needed?

How "Staging" environment can be useful

Which Components of IT Infrastructure do we need for DevOps?

Many companies that want to move to DevOps eventually struggle with the question “What are the Components of IT Infrastructure we need? The use of DevOps stems from the desire to be able to release software more often and faster. The traditional Operations Team (OPS) however will not wholeheartedly embrace this because they would rather benefit from maintaining a stable infrastructure and its maintenance.

3 things MLOps can learn from DevOps

Deployment: Significance of Branching for Continuous Delivery

The deployment of software in DevOps is based on Continuous Delivery. Continuous Delivery enables all kinds of changes, including new features, configuration changes, bug fixes and experiments, to be put into production safely and quickly in a sustainable manner. A Branching strategy and Base Truncs play an important role in this.

What is End User Computing (EUC)? Thanks to the progressive introduction of DevOps, attention to the role of the end user in software development and testing has increased significantly. It is now important to think like an end user when we develop and test software. After all, that's what we're all doing it for.

It's possible to mount FastAPI applications within a FastAPI application

There are 5 types of UUIDs (source):

Type 1: stuffs MAC address+datetime into 128 bits

Type 3: stuffs an MD5 hash into 128 bits

Type 4: stuffs random data into 128 bits

Type 5: stuffs an SHA1 hash into 128 bits

Type 6: unofficial idea for sequential UUIDs

Typical random issues when deploying microservices

Microservices have quite many moving parts

9 things needed for deploying a microservice (listed below)

5 things needed for deploying a monolith (listed below)

Pros of microservices (not always all are applicable):

• Fault isolation
• Eliminating the technology lock
• Easier understanding
• Faster deployment
• Scalability

That is a very good quote!

One of the best ways to picture a difference between DevOps and MLOps

Top 2021 trends for DevOps, SRE.

Event-Driven vs Message-Driven

Reactive Systems:

• responsive - responds in a timely manner
• resilient - stays responsive in the face of failure
• elastic - system stays responsive under varying workload
• message driven - asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency

as a result, they are:

• flexible
• loosely-coupled
• scalable
• easy to develop and change
• more tolerant of failure
• highly responsive with interactive feedback

Components of resilience

Today's demands from users

What is the use of this part in a Docker entry point:

#!/bin/bash
set -e

... code ...

exec "$@"

• number of simultaneous connections (peak and average)

• the message rate/payload size.

Which sudo command to use:

• sudo -i <--- most practical, clean way to gain a root environment
• sudo -s <--- secure way that doesn't let touching the root environment

sudo -i vs sudo su. Simply, sudo -i is a much cleaner way of gaining root and a root environment without directly interacting with the root user

sudo -s vs sudo -i and sudo su. Simply, sudo -s is good for security reasons

Crucial difference between sudo su and su: the way password is provided

The su command is used to get a direct access to the root account

Comparison of data sources

• Data warehouses / lakes (such as Snowflake or Redshift) tend to hold a lot of information but with low data freshness (hours or days). They can be a gold mine, but are most useful for large-scale batch aggregations with low freshness requirements, such as “number of lifetime transactions per user.”
• Transactional data sources (such as MongoDB or MySQL) usually store less data at a higher freshness and are not built to process large analytical transformations. They’re better suited for small-scale aggregations over limited time horizons, like the number of orders placed by a user in the past 24 hrs.
• Data streams (such as Kafka) store high-velocity events and provide them in near real-time (within milliseconds). In common setups, they retain 1-7 days of historical data. They are well-suited for aggregations over short time-windows and simple transformations with high freshness requirements, like calculating that “trailing count over the last 30 minutes” feature described above.
• Prediction request data is raw event data that originates in real-time right before an ML prediction is made, e.g. the query a user just entered into the search box. While the data is limited, it’s often as “fresh” as can be and contains a very predictive signal. This data is provided with the prediction request and can be used for real-time calculations like finding the similarity score between a user’s search query and documents in a search corpus.

Two popular MLOps platforms: Sagemaker and Kubeflow

How the typical ML production pipeline may look like:

Unfortunately, it ties hands of Data Scientists and takes a lot of time to experiment and eventually ship the results to production

Most intuitive difference between automation and orchestration

Automation is like a subset of orchestration.

Orchestration suggest moving many parts, and automation usually refers to a singular task or a small number of strongly related tasks.

First sighting: https://stackoverflow.com/questions/22666163/tls-with-selfsigned-certificate

Tabular comparison of 4 deployment options:

1. Travis-CI/Circle-CI
2. Cloud + Jenkins
3. Bitbucket Pipelines/Github Actions
4. Automated Cloud Platforms

I have always believed the Ops was short for Operations, not Operators.

https://en.wikipedia.org/wiki/DevOps even confirms that belief.

Continuous Delivery of Deployment (quick summary)

Continuous Integration (quick summary)

Good CD build

Good CI build

Idea of Continuous Delivery

Continous Delivery

Continuous Integration is not about tools

Things to be checked by Continous Integration

Continuous Integration prevents other team members from wasting time through a pull of faulty code

DevOps process

• Continuous Integration - code gets integrated several times a day (checked by automated pipeline(server))
• Continuous Delivery - introducing changes with every commit, making code ready for production
• Continuous Deployment - deployment in production is automatic, without explicit approval from a developer

another version of the image: and one more:

Basic prerequisites to learn DevOps:

• Basic understanding of Linux/Unix system concepts and administration
• Familiarity with command-line interface
• Knowing how build and deployment process works
• Familiarity with text editor
• Setting up a home lab environment with VirtualBox
• Networking in VirtualBox
• Setting up multiple VMs in VirtualBox
• Basics of Vagrant
• Linux networking basics
• Good to know basic scripting
• Basics of applications - Java, NodeJS, Python
• Web servers - Apache HTTPD, G-Unicorn, PM2
• Databases - MySQL, MongoDB

DevOps benefits:

• Improves deployment frequency
• Helps with faster time to market
• Lowers the failure rate of new releases
• Increased code quality
• More collaboration between the teams and departments
• Shorter lead times between fixes
• Improves the mean time to recovery

Operations (1/2 of DevOps):

• administrative processes
• support for both hardware and software for clients, as well as internal to the company
• infrastructure management
• quality assurance
• monitoring

You can set CI with a few clicks using Travis CI and creating a .travis.yml file in your repo:

language: node_js
node_js: node

before_script:
  - npm install -g typescript
  - npm install codecov -g

script:
  - yarn lint
  - yarn build
  - yarn test
  - yarn build-docs

after_success:
  - codecov

You can set CI with a few clicks using Travis CI and creating a .travis.yml file in your repo:

language: node_js
node_js: node

before_script:
  - npm install -g typescript
  - npm install codecov -g

script:
  - yarn lint
  - yarn build
  - yarn test
  - yarn build-docs

after_success:
  - codecov

CI - Continuous Integration helps to check the code when it :

• does not work (but someone didn’t test it and pushed haphazardly),
• does work only locally, as it is based on local installations,
• does work only locally, as not all files were committed.

Codecov lets you generate a score on your tests:

Continuous Deployment

airbrake -- monitoring service

Mais um caso prático que vai te mostrar a importância da preparação de um ambiente de desenvolvimento que facilita a vida de todos e garante entregas contínuas e de qualidade. O assunto é transversal a vários tópicos de nossa certificação DevOps Tools.

Se você acha que DevOps é modinha, coisa nova, assista a palestra do Daniel e do Guilherme, uma dupla sempre motivadora.

Continuous Integration e Delivery são também tópicos importantes da certificação LPI DevOps Tools, mas como o João Brito vai falar nessa palestra, é importante entender o porque do uso dessas ferramentas.

701.4 Continuous Integration and Continuous Delivery (weight: 5)

Docker, Grafana e Ansible fazem parte da palestra do Allan e também são tópicos cobertos na prova DevOps Tools do Linux Professional Institute.

705.1 IT Operations and Monitoring (weight: 4)

Operações e monitoramento têm um tópico específico entre as exigências do LPI na certificação DevOps. A Amanda irá contar como implementar métricas com ferramentas de código aberto. Fica de olho!

705.1 IT Operations and Monitoring (weight: 4)

A carreira de DevOps é bastante atrativa e desafiante, mas requer uma mudança na cultura predominante. Veja o que a Aurora tem a dizer sobre isso.

Há falte de profissionais prontos para o mercado que exige DevOps. Compare o que o Mateus precisa com os tópicos que cobrimos em nossa certificação LPI DevOps Tools. Aproveite para seguir os tópicos em https://wiki.lpi.org/wiki/DevOps_Tools_Engineer_Objectives_V1 para criar seu programa de estudos para se tornar um bom profissional DevOps.

Microservices é um dos temas cobertos pela certificação DevOps Tools do Linux Professional Institute e também é um assunto determinante na escolha de ferramentas do cinto de utilidade de um profissional DevOps. Aproveite para conversar com o Tiago sobre a sua experiência com o uso do Docker, assunto que também cai na prova.

Tópicos (dentre outros):

701.1 Modern Software Development (weight: 6) 701.4 Continuous Integration and Continuous Delivery (weight: 5) 702.1 Container Usage (weight: 7)

Comentei, aqui no programa do DevOpsDays Porto Alegre, as palestras que podem te motivar e dar mais informações sobre os tópicos cobertos em nossa prova de certificação DevOps Tools. Visite https://wiki.lpi.org/wiki/DevOps_Tools_Engineer_Objectives_V1 para a lista completa dos tópicos.

Lembra de clicar no título para ver mais anotações nas palavras ou frases em destaque!

Será que vai ter algum sorteio do LPI? Gruda lá na trilha! ;-)

Está aí um assunto sob o qual quero aprender! Não é explicitamente coberto pelos tópicos de certificação DevOps, mas dá uma olhada nos assuntos cobrindo ssh e security (procura também por vault em https://wiki.lpi.org/wiki/DevOps_Tools_Engineer_Objectives_V1).

Sempre é bom conhecer casos reais de empresas (e perguntar muito) para conhecer bem o que é o trabalho de um DevOps, especialmente se você é novato ou está querendo ser um profissional desse tipo.

Excelente para você entender, na prática, sobre Cloud Deployment (um de nossos importantes subtópicos!). Além disso, vai sair da palestra com mais ferramentas para seu cinto de utilidades!

Ainda que esse não seja um assunto cobrado diretamente na prova, essas são ferramentas que devem fazer parte do cinto de utilidades de um bom DevOps. E busca por "container" nos nossos tópicos, nesse link, que tu vais descobrir a importância de conhecer bem sobre o assunto.

Assunto amplamente cobrado pelo subtópico 705.2 - Log Management and Analysis. Dá uma olhada também nesse post de nosso blog.

Uau! Muitos assuntos da prova LPI DevOps são explorados nessa palestra. Fica de olho no tópico: 702 Container Management.

Ainda que os tópicos da prova LPI DevOps não cubram apenas o Git para a integração contínua (ele é usado especialmente em Source Code Management), é muito importante conhecer bem os conceitos de integração e entrega contínua cobertos nessa palestra. Eles estão nesse tópico:

701.4 Continuous Integration and Continuous Delivery

Que tal aproveitar a trilha DevOps Tools do TDC para se preparar para a prova LPI Devops? Minhas anotações nessa página conectam os assuntos desenvolvidos nas palestras com os tópicos da prova.

Em cada uma das palestras expanda o assunto (clicando no título delas) para ver mais anotações que fiz.

Veja esse tópico específico: 701.4 Continuous Integration and Continuous Delivery (weight: 5), especialmente o assunto:

• Understand how Jenkins models continuous delivery pipelines and implement a declarative continuous delivery pipeline in Jenkins

Mais informações também no nosso blog.

Parte do 1.o assunto no tópico 705 Service Operations: 705.1 IT Operations and Monitoring (weight: 4)

Understand the architecture of Prometheus, including Exporters, Pushgateway, Alertmanager and Grafana

Mais informações também nesse post de nosso blog.

Parte do 1.o assunto no tópico 705 Service Operations: 705.1 IT Operations and Monitoring (weight: 4)

Understand the architecture of Prometheus, including Exporters, Pushgateway, Alertmanager and Grafana

Mais informações também nesse post de nosso blog.

Vamos aproveitar para falar sobre carreiras e certificações nesse intervalo?

Ainda que aqui os tópicos da certificação não cubram exatamente esse assunto, monitorar a saúde de um sistema e suas aplicações é missão do profissional DevOps. Atente para os tópicos:

701 Software Engineering 701.1 Modern Software Development (weight: 6)

e

705.2 Log Management and Analysis (weight: 4)

How do we get involved in the pilot?

Typically Terraform violates the spirit of this principle. Though each deploy may be defined (typically as an environment) in the same repo, the codebase is different. We work around this making heavy use of modules to limit divergence between deploys.

Direct annotations don't work here.

Docker/DSL Pipeline vs Groovy native?

What is the divide?

I see this same near-total lack of overlap. There is a different language, mindset, and approach.