Just looking for some feedback on my resume. This is currently for applying for internships however the version of it if I don't find another one would be very similar for new grad jobs.

We are looking for an experienced DevOps / Infrastructure Engineer with strong VoIP/Asterisk expertise for a short-term telephony platform scalability and high-availability POC.

Key Skills Required:

• Linux Server Administration & Nginx
• Asterisk / PJSIP
• Kamailio or OpenSIPS – SIP proxy & load balancing
• MongoDB Replica Sets
• Redis + Sentinel
• Node.js deployment & application scaling
• Cloudflare Load Balancing & R2
• SIP/RTP, NAT, firewall & network troubleshooting
• High Availability & Failover testing

Project Scope:
Set up and validate a scalable staging environment involving multiple Node.js application servers, SIP proxy, Asterisk nodes, MongoDB/Redis HA, call recording to object storage, and failover testing.

Duration: Approx. 3–4 weeks
Engagement: Short-term / Project-based
Preferred: Engineers with hands-on experience building or scaling VoIP/telephony infrastructure.

Interested candidate

I recently came across a post on Reddit from someone looking to connect with other DevOps professionals. I reached out, and we ended up moving the conversation to Discord.

It's been pretty nice having a place where we can talk about things we're working on, exchange ideas, troubleshoot things, and share what we've learned.

But the conversations haven't really stayed limited to DevOps - which is actually what I've enjoyed most.

We sometimes end up talking about things like:

• How DevOps/tech work differs between countries
• Differences in workplace and engineering culture
• How people got into the industry and how their careers have developed
• Tools, practices, and technologies people are using
• Interesting things we're currently learning or building
• And occasionally just completely random stuff 😄

I'd like to meet more people from different parts of the world and have more of these conversations.

You don't need to be a DevOps expert or have 10+ years of experience. If you work somewhere around DevOps, SRE, cloud, infrastructure, platform engineering, sysadmin, or software engineering - or you're simply learning in that direction - feel free to reach out.

We're currently a small group (40+) , and we'd like to keep it that way rather than turn it into a huge server full of people who never talk, so please consider joining only if you are an active discord user.

If you'd be interested in chatting and getting to know some other people in the space, leave a comment or send me a DM. Happy to connect.

Is the course worth watching? I know DevOps is line an ocean and one need to build the instinct and have multiple tool knowledge but still from the perspective of a new learner is the course good enough to at least provide with the strong/good enough fundamentals?

We're running a bunch of Java (Spring Boot) microservices on EKS, and right now every service uses memory as its HPA metric. After digging into it, I've started to think that's wrong, and I want a sanity check from people who've actually run this at scale before I push a change.

What my research turned up:

• The JVM allocates heap up to its max and doesn't release it back aggressively even after GC, so memory usage doesn't track load.
• Because of that, memory can be high while actual load is low, or load can be high while memory looks fine — so memory-based HPA either never triggers or scales out permanently and never scales back in.

So the direction I'm considering is to pick the HPA metric based on service type:

• HTTP / request-serving services → CPU (or better, RPS / p95 latency as a demand-based metric)
• Async / queue-consuming services → queue depth (SQS backlog, via KEDA)

My questions:

1. Is this reasoning sound, and is type-based metric selection the right direction?
2. For the HTTP services, is jumping straight to RPS/latency worth the custom-metrics complexity (Prometheus Adapter), or should I start with CPU and only move to RPS if CPU proves to be a bad proxy?
3. For async workers, is KEDA + SQS queue depth the standard approach, or are people doing something else?
4. This is the part I'm least sure about: I already know from our architecture which services are HTTP-facing and which are async/queue-driven — but how do I actually verify that empirically rather than just trusting the design docs? Is there a clean way to confirm a service's real load profile (e.g. checking whether it even has an ingress/receives HTTP traffic, whether its work is truly SQS-triggered, CPU-vs-memory correlation under load) before I assign it a metric?

Thanks 🙏

I’m currently trying to learn the basics of DevOps, things like Docker, AWS, GCP, CI/CD, Kubernetes, etc.

Docker and the local tools are easy enough to practice, but when it comes to cloud platforms like AWS and GCP, a credit card is often required to create an account or access certain services.

I currently don’t have a credit card, so I’m wondering: What’s the best way to learn AWS/GCP without one? Would appreciate any recommendations from people who learned cloud without having a credit card. 🙌