Career choices


I've been in CS for about a year now and I've discovered that i can't stand frontend, I respect everyone who takes this side of SE as their life commitment but its not for me , however can a software engineer take on Cloud and Devops roles too alongside the backend tasks if that what interest him a do not touch frontend end at all ? Meaning can he combine these two areas and be highly paid without needing to know frontend ?

https://redd.it/1nu0m8o
@r_devops

To all the devs out there, how do u guys like to be sold?

Do not say test and see myself i know you do, but what else what kind of messaging and marketing is you like. I know you guys won't get on a sales call. you need to try first or build yourself. But if i have to sell you. How are you buying people??

https://redd.it/1nu23j0
@r_devops

Introducing Upyng – A Powerful Offline Utility App for DevOps & Techies!

Hey everyone,

I’ve been working on something I’m really excited to share – my app Upyng. It’s currently available for macOS, and I’m actively working on bringing it to Windows and Linux by October 15.

Originally, I planned to launch Upyng as an online website, but I ran into issues integrating Google Ads. Since the entire project is built using Flutter, I decided to pivot and build proper desktop apps instead. This turned out to be a great decision — now everything works completely offline, with no dependency on third-party websites.

Upyng brings together several commonly used developer and debugging tools into one clean, fast, and modern app, so you don’t have to juggle multiple sites or separate utilities.

Current features include:
• Regex tester
• JSON / YAML / XML / CSV formatter & viewer
• Grok tester
• Text compare
• Cron helper
• QR code generator

For this launch month, Upyng is available at a reduced price until October 31. After that, the price will increase, so it’s a good time to grab it early and support the project.

Current status:
• Available now: macOS
• Coming October 15: Windows & Linux

Mac App Store link—> https://apps.apple.com/in/app/upyng-devtools-more/id6752918289?mt=12

I’d love to get your feedback, suggestions, and support to help shape Upyng’s future development.

Thanks so much,
— Suraj


https://redd.it/1nu2nh9
@r_devops

Switching from Data Science to Cloud Engineering? Need opinions from people in the industry

Hi everyone,
I’ve been learning and practicing data science and ML for the last 6 months. I also hold Cisco and IBM certifications in this field, and I feel somewhat comfortable with the basics now.

But recently, I’ve noticed that almost everyone is getting into data science/ML, and the competition seems extremely high. That’s why I’m considering shifting my focus toward cloud computing and cloud engineering roles — something that feels more engineering-focused and potentially in higher demand.

For those of you already working in tech (especially in cloud or data-related roles):

Do you think it’s worth pivoting from data science to cloud engineering at this stage?

What’s the job market like for cloud engineers compared to data science right now?

Are there clear entry-level paths/resources you’d suggest?


Any honest suggestions or experiences would be really helpful. Thanks a lot!

https://redd.it/1nu4n3h
@r_devops

Bare metal OpenStack vs K8s-first for a self-service regional cloud?

Hi folks, I currently run a private DC with paying customers from direct b2b sales lines. I’d want to flip to self-service (sign up, provision, pay). I’m torn between:

A) Bare metal (Ubuntu 24.04) → OpenStack control plane (Ansible, Galera) → tenants via Terraform
B) Bare metal (Ubuntu 24.04) → Kubernetes mgmt layer → OpenStack on top → Terraform for tenants

3 questions:
1. From an operations POV, is OpenStack directly on metal simpler to run/upgrade, or is K8s-first more maintainable long term?
2. What’s your favorite portal + IAM + billing combo for dev-friendly self-service (API keys, projects/quotas, usage graphs)?
3. What guardrails are non-negotiable for open signups (quotas, egress controls, WAF/DDoS, rate limits, abuse detection)?

Bonus: Opinions on OVN vs OVS, Ceph design, Cells v2/regions, SSO/OIDC, blue/green upgrades, and GPU/MIG quotas welcome.

🙏

https://redd.it/1nu744r
@r_devops

Managing test analytics & flaky test detection - tools?

We have a growing suite, and flakiness is a nightmare. CI logs aren’t enough to see patterns. Are there analytics dashboards that track flaky tests over time?


https://redd.it/1nu7zkk
@r_devops

im a backend wants to extend my knowledge to devops and infrastructure

i made a book list , but think this list is overkill , im here to ask for recommendations how to approach that ?

my list is

The Linux Command Line" by William Shotts 2019

Deoplyment From scratch

fundamentals devops software delivery 

Learn docker in month of launch 

Learn kubernetes in month of launch 

Release it .
system performance 


\- i have some experience with docker

https://redd.it/1nu97i8
@r_devops

DevOps Audit/Auditor

Hi all,

I need to find a DevOps /SaaS auditor, any clue how I would find one?

Thanks

Ssushi

https://redd.it/1nua0jz
@r_devops

FluxCD webhook receivers setup in large orgs

Hi there,

As I was implementing fluxcd at a large org I wondered how many of you using flux proactively used the webhook component to send event and trigger reconciliations for git repositories, image automation, kustomizations, etc.

In a development environment, one would want quick updates when building a new image or editing manifests, needing the ImageUpdateAutomation to commit quickly and then trigger a GitRepository and Kustomization reconciliation hence the use case of Receivers. It would also allow for greater update intervals wich could help reducing resource usage (in the forge and the controllers) in a setup with tens of GitRepositories, Kustomizations and lots of clusters... but then again, how do you use that efficiently in a multi cluster setup since the application being built knows neither the namespace(s) it should be deployed in nor the destination flux instances.

I went quite far in this rabbit hole, even wondering if I should somehow build some kind of Receiver router that would then dispatch received events to the correct flux instances using some CRDs, etc. but then I thought I might not be the only one with this use case (it seemed pretty standard) so I should ask the community how they're doing it.

Please advise!

https://redd.it/1nub7ax
@r_devops

I see enterprises make these 3 cloud mistakes constantly. What's the biggest 'oops' you've ever seen?

**Your Monolith is Groaning, and Your CFO is Asking Questions.**

Let's be honest. Your on-premise servers are running hot, scaling for the holiday rush is a year-long panic attack, and every new feature deployment feels like open-heart surgery. You know the cloud is the answer, but the path from your current state to a nimble, cloud-native enterprise application seems foggy and filled with buzzwords.

This isn't another high-level whitepaper. This is a practical, no-BS guide to getting it done right. I'll cover the critical decisions, the tools that actually work, and the traps that'll burn your budget.

# Part 1: The "Why" - The No-Fluff Benefits of the Cloud

Forget "digital transformation." Here's what you actually get.

* Stop Guessing Your Capacity: Remember ordering servers 6 months in advance? Now you can scale your resources up or down in minutes. Pay for what you use, not what you might use.
* Go Faster (Seriously): With the right setup, your developers can go from writing code to deploying it in a single afternoon. This isn't a fantasy; it's what a well-oiled CI/CD pipeline in the cloud provides.

Global Reach, Local Speed: With a few clicks, you can deploy your application in data centers from Virginia to Frankfurt to Tokyo, giving users a low-latency experience anywhere in the world.

# Part 2: Your Enterprise Cloud Roadmap: A 5-Step Practical Guide

**Step 1: Choose Your Playground (AWS vs. Azure vs. GCP)**

This is the first holy war you'll encounter. All three are excellent, but they have different personalities.

|Factor|AWS (Amazon Web Services)|Azure (Microsoft)|GCP (Google Cloud Platform)|
|:-|:-|:-|:-|
|**The Vibe**|The undisputed market leader. Has a service for everything. The "default choice."|The enterprise champion. Deep integration with Microsoft products (Windows Server, Office 365, Active Directory).|The data & container expert. King of Kubernetes, Big Data, and AI/ML services.|
|**Best For...**|Companies wanting the widest array of services and the largest community support.|Enterprises heavily invested in the Microsoft ecosystem.|Companies focused on data analytics, machine learning, and container orchestration.|
|**Watch Out For**|The sheer number of services can be overwhelming. The billing can get complex fast.|The user interface can sometimes feel less intuitive than the others.|Smaller market share means a slightly smaller talent pool in some areas.|

*Pro-Tip: Don't get paralyzed by choice. For most general-purpose enterprise apps, any of the three will work. Make the decision based on your team's existing expertise and your company's strategic alliances (e.g., if you're a Microsoft shop, Azure is a natural fit).*

**Step 2: Pick Your Architecture (Don't Just Default to Microservices)**

How you structure your app is the most critical decision you'll make.

Monolith: Your entire application is a single, unified unit.

* Pro: Simple to develop, test, and deploy initially.
* Con: Becomes a nightmare to update and scale as it grows. A bug in one small part can bring down the entire app. This is likely what you're moving away from.

Microservices: Your application is broken down into small, independent services that communicate with each other via APIs.

* Pro: Highly scalable and resilient. Teams can work on different services independently. You can use different tech stacks for different services.
* Con: Way more complex. You have to manage a distributed system, which adds challenges in networking, monitoring, and data consistency. **~~Don't adopt microservices just because it's trendy.~~**

Serverless (Functions as a Service): You don't manage any servers. You just write code (functions) that runs in response to events (like an API call or a file upload).

* Pro: Ultimate scalability and cost-efficiency (you truly pay for what you use, down to the millisecond).
* Con: Can lead to vendor lock-in. Not suitable for long-running, computationally intensive tasks.

*Pro-Tip: Start with a

"well-structured monolith" or a few key microservices. Avoid breaking everything down into 100 tiny services from day one. Evolve your architecture; don't try to perfect it on the first attempt.*

**Step 3: Embrace Automation (Your DevOps Playbook)**

The cloud's power is wasted if your deployment process is still manual.

CI/CD is Non-Negotiable: Set up a Continuous Integration/Continuous Deployment pipeline from day one. Every code change should automatically be built, tested, and deployed.

* Tools: GitHub Actions (great if you're on GitHub), GitLab CI (excellent all-in-one solution), Jenkins (the old, powerful workhorse).

Infrastructure as Code (IaC): Define your servers, databases, and networks in code. This makes your infrastructure repeatable, version-controlled, and easy to manage.

* Tools: Terraform (the cloud-agnostic standard), AWS CloudFormation (AWS-specific).

**Step 4: Lock It Down (Security is NOT an Afterthought)**

The cloud provider secures the cloud, but you are responsible for security in the cloud. This is the "Shared Responsibility Model." Don't get caught out.

* Identity & Access Management (IAM): Grant the least privilege necessary. Don't give a junior developer admin access to your production database.
* Network Security: Use Virtual Private Clouds (VPCs) and subnets to isolate your resources from the public internet.
* Encrypt Everything: Encrypt your data both at rest (in the database) and in transit (over the network).

**Step 5: Tame the Beast (Cloud Cost Management)**

Your biggest post-launch surprise will be the bill. Get ahead of it.

Tag Everything: Tag every resource (server, database, etc.) with its owner, project, and environment (dev, staging, prod). This is the only way to know where your money is going.

Set Billing Alerts: Create alerts that notify you when your spending exceeds a certain threshold.

Shut Down Dev/Test Environments: Don't run development and testing servers 24/7. Automate noscripts to shut them down on nights and weekends. This alone **can save you 60-70% on non-production costs.**

# Part 3: The "Oops" File - 3 Common Cloud Pitfalls to Avoid

**The Blind "Lift and Shift":** Just moving your old, inefficient monolith from your on-premise server to a cloud server (like an EC2 instance) is the fastest way to get a massive bill with zero benefits. You're just renting a more expensive data center.

1. **Ignoring Cost Governance:** Teams will spin up resources and forget about them. Without a clear governance and tagging strategy, your cloud bill will spiral out of control.
2. **The "It's the Cloud's Problem" Security Myth:** Assuming AWS/Azure/GCP handles all security is a recipe for disaster. You are still responsible for configuring firewalls, managing user access, and securing your application code.

# TL;DR & Conclusion

Moving your enterprise application to the cloud isn't just a technical shift; it's a cultural one.

* **Start Small:** Don't try to boil the ocean. Begin with a single application.
* **Choose Wisely:** Pick your cloud and architecture based on your team and needs, not just trends.
* **Automate Everything:** Your CI/CD pipeline and IaC are your best friends.
* **Govern Costs & Security:** From day one, treat cost and security as primary features.

*The journey is complex, but the payoff, in speed, scalability, and resilience, is undeniable.*

https://redd.it/1nud3km
@r_devops

How the hell are you all handling AI jailbreak attempts?

We have public facing customer support AI assistant, and lately it feels like every day someone’s trying to break it. Am talking multi layer prompts, hidden instructions in code blocks, base64 payloads, images with steganographically hidden text and QR codes.

While we’ve patched a lot, I’m worried about the ones we’re not catching. We’ve looked at adding external guardrails and red teaming tools, but I’d love to hear from anyone who’s been through this at scale.

How do you detect and block these attacks without rendering the platform unusable for normal users? And how do you keep up when the attack patterns evolve so fast?

https://redd.it/1nudj4x
@r_devops

The first malicious MCP server just dropped, what does this mean for agentic systems?

The postmark-mcp incident has been on my mind. For weeks it looked like a totally benign npm package, until v1.0.16 quietly added a single line of code: every email processed was BCC’d to an attacker domain. That’s \~3k–15k emails a day leaking from \~300 orgs.

What makes this different from yet another npm hijack is that it lived inside the Model Context Protocol (MCP) ecosystem. MCPs are becoming the glue for AI agents, the way they plug into email, databases, payments, CI/CD, you name it. But they run with broad privileges, they’re introduced dynamically, and the agents themselves have no way to know when a server is lying. They just see “task completed.”

To me, that feels like a fundamental blind spot. The “supply chain” here isn’t just packages anymore, it’s the runtime behavior of autonomous agents and the servers they rely on.

So I’m curious: how do we even begin to think about securing this new layer? Do we treat MCPs like privileged users with their own audit and runtime guardrails? Or is there a deeper rethink needed of how much autonomy we give these systems in the first place?

https://redd.it/1nuechz
@r_devops

When 99.9% SLA sounds good… until you do the math

Had an interesting conversation last week about a potential enterprise deal. The idea was floated to promise 99.9% uptime as part of the SLA. On the surface it sounded fine, everyone in the room nodded along.

Then I did the math: 99.9% translates to about 43 minutes of downtime per month. The awkward part? We'd already used that up during a P1 incident the previous Saturday. I ended up being the one to point it out, and the room went dead silent.

What really made me shake my head was when someone suggested maybe we should aim for 99.99% instead, just to grab the deal. To me, adding another feels absurd when we can barely keep up with the three nines.

In the end, we dropped the idea of including the SLA for this account, but it definitely could have gone the other way.

Curious if anyone else has had to be the "reality check" in one of these conversations?

https://redd.it/1nue6oy
@r_devops

GitHub Copilot + Bedrock adding Claude 4.5 Sonnet: will you switch models
https://www.reddit.com/gallery/1nufe3n

https://redd.it/1nug7nv
@r_devops

Trunk based or Gitflow?

Hey guys any thoughts about enforcing these into ci/cd? What are your thoughts and for a fast phase environment what’s better?

https://redd.it/1nuhujm
@r_devops

Job at Bottomline as systems engineer

Hi Everyone,

I have ~4.5 years of experience as a DevOps Engineer. Currently, I’m working at SAP as a DevOps Engineer. However, the role isn’t “true DevOps” in the sense of building CI/CD pipelines or creating Kubernetes clusters. It’s more focused on cloud operations like monitoring k8s clusters, upgrading components, and handling on-call. The positives are that I have good freedom, flexibility, an average package, and extra on-call allowances.

Now I have an offer from Bottomline as a Systems Engineer II with a better package (though benefits aren’t as strong as SAP). Bottomline isn’t as big as SAP. it’s a growing company. The role is more like a Kubernetes admin within their central infrastructure team, but it also involves AWS, GitOps, Terraform, etc. The team is spread across the US and UK, so I’d be covering either Shift 1 or Shift 2 without additional allowance, and week-offs might vary.

The team seems good and welcoming, which is a plus.

I’m in a confused state... so, should I stick with SAP (stability, brand, flexibility) or move to Bottomline (hands-on infra/devops work, higher pay, smaller company, shift challenges) or wait for othet opportunities?

Any advice would be really appreciated.

https://redd.it/1nufbsz
@r_devops

Beginner looking for guidance to learn DevOps – Where should I start?

Hi everyone,

I’m a complete beginner and want to get into **DevOps**. I have some basic knowledge of coding/development, but I feel overwhelmed by how broad DevOps is (CI/CD, Docker, Kubernetes, Cloud, Monitoring, etc.).

Could you please guide me on:

* **Where to start as a beginner?** (Linux, Git, Docker, Cloud basics?)
* **Recommended learning path** (what skills/tools should I prioritize first?)
* Any **free/affordable resources** (courses, YouTube channels, documentation, books)
* How much coding knowledge is actually required for DevOps?
* Any **projects or hands-on practice ideas** to build real skills?

My goal is to gradually build a strong foundation and eventually be job-ready for DevOps/SRE roles.

Any advice, roadmap suggestions, or resource links would be super helpful! 🙏

Thanks in advance.

https://redd.it/1nun9c5
@r_devops

Academic Repository Study - Quick 5 Minute Survey

We are master's students at the University of Texas currently working on a research project on how developers and teams choose and adopt their artifact repositories (e.g., Nexus Repository, Artifactory, GitHub Packages, etc.).
We're hoping to better understand:
• What developers consider “must-haves” when choosing a repository manager
• Pain points or frustrations with current tools
• How different environments (work, school, open-source) shape those choices
If you’ve worked with any artifact repository, whether as a student, hobbyist, or in a professional team, we'd be super grateful if you could fill out this quick survey (5 minutes). We will be raffling a $100 gift card at the end of the survey period.

https://forms.gle/3BSCZu51GLFxgUXy5

Your input will help us identify what really matters to devs when they're picking a repository manager and hopefully make your experience better in the future!
(Mods, please let me know if this post isn’t appropriate here and I’ll take it down or if I need to verify the authenticity of the post)



https://redd.it/1nup56c
@r_devops

Why doesn't the sub have a profile pic?

Serious honest question

https://redd.it/1nuqtqt
@r_devops

My company is moving to container only now. But higher ups are deciding we will not containerize any database.

Citing "the access to filesystem and performance are not good enough"

This mean future project will be dockerized... except databases like mariadb, postgres and mongodb that will keep living in a VM (At the moment everything is a VM managed but puppet in our infrastructure)

What are your thoughs ? I have some personnal experience with databases in container (I run a postgres DB in a container for a personnal project) but nothing of the scale a company like us would run

https://redd.it/1nutnci
@r_devops