• Evolving Quality: Local Large Language Models (LLMs) have achieved major milestones in accuracy, utility, and speed over the past six months, transitioning from simple "personalized Google" documentation lookups to handling localized agentic software development workflows.
• Hardware Requirements: Running larger models effectively requires high-spec hardware (e.g., Apple M-Series with 64 GB+ unified RAM) to maintain an expansive Key-Value (K-V) cache and avoid critical performance degradation.
• Top Performing Architecture: Recent open-weights families, such as Gemma 4 (specifically the gemma-4-26b-a4b and the faster gemma-4-12b-qat), have successfully reached roughly 75% of the accuracy and speed found in cloud-hosted frontier API models.
• Agentic Workflows: Local models can now successfully loop and interact with local environments to orchestrate non-trivial tasks like refactoring code, writing unit tests, and bootstrapping full application repositories.
• Secure Execution: Running developer-facing local agents poses local file system security risks, making a decoupled architecture—such as isolating the agent harness inside a containerized Docker Sandbox with restricted shell permissions—an essential security best practice.
• Persistent Ecosystem Bottlenecks: Despite massive progress, challenges remain around slow initial token pre-fill, limited context windows bounded by local hardware constraints, prompt template mismatches on release, and the heavy compute strain that maximizes GPU and RAM workloads.

Hacker News Discussion

• Operational Friction: Many users argue that local models remain painful to run effectively. They note a stark divide between smart but slow dense models (e.g., Qwen 27B, Gemma 31B) and fast but error-prone Mixture of Experts (MoE) models.
• The Quantization Trap: Commenters point out that many users run low-bit quantizations (like 4-bit) to save RAM, which effectively lobotomizes the model's capacity for complex tool calling. Industry recommendations favor a minimum of 5-bit for dense models and 6-bit for MoEs.
• Hardware & Comfort Trademarks: Running these workloads locally often transforms high-end laptops or desktops into loud, hot, and energy-churning machines, making the physical development environment uncomfortable.
• Privacy and Data Sovereignty: A heated debate emerged regarding hosted vs. local options. While some demand local setups due to data-collection practices and copyright concerns of major tech providers, others prefer private API gateways or hosted "open model clouds" (like OpenRouter or specialized European hosters like OVH) that guarantee Zero Data Retention (ZDR).

• Kubernetes (K8s) has become nearly universal across companies of all sizes, including early-stage startups that do not have immediate technical scaling needs.
• The shift toward K8s is primarily driven by organizational benefits rather than pure technical necessity:
  • It enforces uniform deployment processes across different applications.
  • It standardizes engineering knowledge, making the infrastructure architecture highly visible via YAML manifests rather than keeping it locked in individual developers' heads.
  • It provides end-to-end traceability and predictability through GitOps workflows (e.g., using Argo CD or Flux CD).
• The universal adoption has been accelerated because managed K8s offerings (such as AWS EKS, Google GKE, and Azure AKS) have matured significantly, and the engineering talent pool has heavily flipped in favor of K8s familiarity.
• Despite its organizational strengths, the author still recommends that early-stage startups start without Kubernetes because debugging cluster complexities can heavily drain energy that should be focused on building the core product.

Hacker News Discussion

• Many commenters warn that Kubernetes is far from "batteries-included." Setting up a basic functional cluster requires installing and self-managing numerous third-party controllers (like ingress, cert-manager, external-dns, and CoreDNS), creating significant hidden operational overhead.
• Maintaining Kubernetes involves a severe maintenance loop, forcing teams to perform major cluster and controller upgrades every few months while constantly navigating breaking changes and configuration churn.
• A common critique is the massive shift of complexity from application programming languages to configuration management (e.g., YAML, Helm, Kustomize), which is often harder to validate for correctness and can easily become a "Byzantine mesh" of plug-ins.
• Some participants argue that there is a massive gap in the market for a simpler alternative that allows declarative, containerized deployments to a pool of instances without the full operational complexity of K8s, though others counter that user demands for endless customization always inevitably drive simple tools to become complex orchestrators.
• Proponents note that while K8s doesn't stop engineers from making poor architectural decisions (like packaging unencrypted secrets inside images), it structurally makes it much easier to implement and adhere to best practices compared to traditional VPS or bare SSH workflows.

• Introduction and Context: The author reflects on his experiences after being affected by layoffs at Atlassian, where he worked for approximately 8 years. He shares details about the technical architecture he built, key achievements, and non-technical lessons learned to inspire others in similar situations.
• The Interview Process (8 Years Ago):
  • Began with an online coding quiz on HackerRank, which he aced with full marks.
  • The first technical round involved reading a Cloudflare white paper on custom domains for 10 minutes and then answering architectural questions regarding microservices and containers.
  • The second technical round was a live troubleshooting simulation of a real Atlassian incident (an application issue causing a Denial of Service). He also faced questions about latency-based DNS routing.
  • During the values interview, when asked what success would look like in 12 months, the interviewers outlined the need for an internal platform application to provide self-service load balancing for Atlassian dewelopers.
• Building the Open Service Broker (OSP):
  • In his first few weeks, the author built an application adhering to the Open Service Broker API specification to automate infrastructure provisioning in a Kubernetes environment.
  • Internal developers declared their infrastructure requirements using configuration files in version control, which build servers then uploaded to the broker.
  • The system was originally built in Python using the Connexion library (routing based on OpenAPI documents), later migrated to pure Flask, and eventually transitioned to FastPI.
  • The architecture utilized an asynchronous task queue model: FastAPI received requests, pushed task details to AWS SQS, and background workers handled tasks (like creating DNS records or CloudFront distributions) while writing status updates to DynamoDB.
• Transitioning to Envoy Proxy and Sovereign (Control Plane):
  • Atlassian decided to replace expensive corporate enterprise load balancers with Envoy Proxy, an open-source, cloud-native proxy.
  • The author built a custom Envoy management server/control plane named Sovereign (which was open-sourced on Bitbucket).
  • Built with FastAPI, Sovereign pulled dynamic context data from the broker's database and AWS S3 buckets, injected it into templates for Envoy resources (clusters, routes, listeners), and dynamically pushed updated configurations to running proxies over the wire.
• Infrastructure as Code and Image Automation (AMI):
  • The entire proxy infrastructure—comprising around 2,000 proxies across 13 AWS regions—was deployed using AWS CloudFormation templates defining VPCs, subnets, Network Load Balancers (NLBs), Security Groups, and Auto Scaling Groups.
  • To create standardized images, the team used HashiCorp Packer combined with SaltStack (a declarative configuration management tool similar to Ansible or Chef).
  • The resulting AMI had pre-installed and optimized components, including Envoy, network tuning configurations, security hardening layers, and observability agents for logging, tracing, and metrics.
• Mass Migration and Edge Centralization:
  • Following the initial framework setup, the team spent roughly two years migrating major Atlassian core products (Jira, Confluence, Bitbucket, Statuspage) and thousands of microservices behind this centralized edge infrastructure.
  • The platform locked down public exposures; microservices could no longer be accessed publicly by accident. Developers had to explicitly signal intent through the proxy configuration.
  • Centralizing these features saved millions of dollars and massive development time, sparing thousands of developers from having to independently implement features like authentication, authz, or rate limiting on their own backends.
• Sidecar Architecture and Custom Rust Tools:
  • While DDoS protection was offloaded to AWS CloudFront and Access Logs were captured natively via Envoy's HTTP Connection Manager filters, more complex features required a sidecar container model running locally on the proxy EC2 instances.
  • The author personally designed and wrote a custom authentication sidecar container from scratch using Rust ("the Lord's language").
  • Other specialized internal teams contributed separate sidecar containers for authorization and rate-limiting.
• Non-Technical Growth and Professional Lessons:
  • Diplomacy and Conflict Resolution: Working with various managers and diverse personalities for nearly a decade forced the author to dramatically mature his skills in persuasion, mentoring, and navigating interpersonal friction.
  • Code Churn and Long-Term Maintenance: The author notes that building software is easy, but maintaining its malleability over time is hard. Codebases develop highly predictable areas of continuous modification ("code churn"), which serve as code smells indicating growing complexity that must be actively refactored before coupling paralyzes development.
  • Mentoring vs. Training: The author successfully mentored an intern to achieve the highest possible performance rating and a return offer. However, he reflects on mentoring as a highly challenging balancing act—knowing how to guide someone without giving away answers or letting them get overly frustrated—distinguishing it from his everyday engineering strength of breaking down complex system architectures into easily digestible mental models for peers.

AI工具大幅提高了代码生产效率，但整个软件开发生命周期是基于较低的代码生产率设计的，这导致了新的瓶颈和挑战。

• 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.