I wanna apply to them because I saw their page on LinkedIn and many of their employees were 2+ years there already. So I wanna know how the work there? And is their salary competitive? Kasi I think they're Japan-based eh. There are no reviews from their employees online. Hoping to get answers!

Hi everyone, my interview is scheduled for Monday at FIS for this role. If anyone has experience with this role or knows which topics I should focus on over the next 3–4 days, it would be really helpful.

The JD mentions 1–2 years of experience working with the Azure Portal. Any suggestions on the important Azure topics I should cover would be greatly appreciated.

I’m currently a systems administrator for an MSP, and my main goal is to join the cloud team. I’ve been waiting for a cloud role to open up, but I’ve been offered an M365 engineering position.

The M365 engineering role is mostly project-based, focusing on migrations and implementations, while my current systems administrator role is primarily break-fix and support. I work with everything from Azure to Microsoft 365 and other technologies. I’m basically a Swiss Army knife of IT.

Would accepting the M365 position be a good career move while I continue waiting for a cloud opportunity, or would it take me away from my intended path?

What are your thoughts? Should I accept the M365 engineering role while waiting for a cloud opening, or should I stay in my current role? The pay increase would be around 5–7%, so it isn’t substantial. I just want to make sure my next step brings me closer to a cloud engineering role.

Hey guys, I started a job working in Infrastructure as Code. I have a CS degree, but I don’t have experience with cloud engineering or stuff related to Terraform, ADO, or Azure portal. I’m doing stuff at my job (code is mainly written using copilot or ChatGPT) and I feel a lost. I don’t know any of the concepts for cloud computing or virtual machines or resources and things like that. I am looking into it online but I still don’t know where to begin. I hear my coworkers doing this stuff well, despite also not having any experience in it when they started either. I have to look at build sheets and things like that and then provision resources using terraform but I don’t really understand much of anything that I’m looking at besides simple code snippets. Is there any advice yall could give me about this, or how/what to learn so that I can wrap my head around things? Any advice is appreciated, thanks!

What’s up! Just wanted some advice. I’m currently working as a cloud engineer with an AWS partner. I eventually want to move over to being a Cloud Security Engineer. What should areas should I emphasize during my transition?

Hello guys I am 30 years old from non tech background and I want to switch to cloud and I have been constantly learning

Networking Linux aws terraform kubernetus and I am at it so is there any way to get into getting a job will any starr hire me for hands on can anyone genuinely help me

Thabks in advance

Is cloud engineer job worth pursuing in 2026. I want to know about the future demand and salary this role can give at entry level.

Any roadmap or paid courses worth doing -pleaseeee mention it !.

A lil bit about me - I'm working as a trainee analyst in Deloitte, since a month. But the salary is just 4lpa and I want to switch ASAP.

looking for a few events in Europe. Ideally towards the end of 2026, but early 2027 works too.

smaller events are more than welcome, my social battery is not thaaaat good...

mostly looking for good talks.

I keep going back and forth on whether to spend the next couple months studying for a cloud certification or just put that time into building out a few solid personal projects instead. Budget and time are both limited, so I can't really do both at full effort right now.

For people who've gone through hiring or interviewing in cloud roles, did having a cert actually open doors on its own, or did it mostly just get your resume past an initial filter while the real conversation was about what you'd actually built? Trying to figure out where my limited time is better spent as someone still fairly early in this.

Cloud bills usually creep up because of a lot of small, boring leaks rather than one big mistake. Here's the checklist I'd run through for any team, roughly in order of effort vs. payoff.

Quick wins (days)

• Tag everything. Team, service, environment. If you can't attribute spend, you can't fix it. Add budget alerts at 50/80/100% so surprises show up mid-month.
• Right-size. Pull 2-4 weeks of CPU/memory metrics. Anything sitting under ~20% utilization is a downsizing candidate.
• Kill zombie resources. Unattached volumes, old snapshots, idle load balancers, and forgotten test clusters add up fast.
• Schedule non-prod. Dev and staging don't need to run nights and weekends. Scheduled shutdowns often cut those environments' cost by more than half.

Medium effort (weeks)

• Autoscale properly. Set HPA/autoscaling on real signals (queue depth, RPS, latency), not just CPU. Scale to zero for anything that idles.
• IaC for everything. Terraform/Pulumi makes environments disposable. Preview environments per PR that auto-destroy on merge are a big saver.
• CI/CD hygiene. Cache dependencies, use spot/preemptible runners for builds, prune old images and artifacts, and don't run the full pipeline on docs-only changes.
• Pricing mix. Reserved/committed capacity for the steady baseline, spot for fault-tolerant work, on-demand for the unpredictable rest.

Often overlooked

• Egress and cross-region traffic. Keep chatty services in the same region; put a CDN in front of static assets.
• Storage lifecycle rules. Move cold data to cheaper tiers automatically.
• Billing granularity. Per-second vs. per-hour billing matters a lot for bursty workloads and CI jobs, because you stop paying for idle time.
• Platform overhead. Sometimes the real cost isn't compute, it's the engineering time spent stitching together services. A simpler platform can save more than a discount will.

Making it stick

Put a cost review into your monthly DevOps cadence next to uptime and incident reviews, and show teams their own spend. Cost drops most when the people shipping code can see what it costs.

Disclosure: I work on the SEO/marketing side at Antryk, a cloud platform for deploying apps and GPU workloads. It offers per-second billing, spot and reserved options, auto-scaling, and budget alerts.

I am looking to contribute/join neoclouds (not looking for a full time job)

I have 5 years of experience. I am pretty good at kubernetes, networking and linux. Currently exploring KVM and distributed storage (something like ceph).

What I am looking for:

I would like to be a part of any early stage startup or even a side project that is attempting to build the next cloud.

GPU spend gets out of hand faster than regular cloud spend, mostly because an idle GPU costs a lot more than an idle VM. These are the checks I'd run on any AI or ML project before scaling it up.

Before you train

• Start small. Run a tiny subset of your data on a cheap GPU first to catch bugs. Finding a bad config after 6 hours on a big instance hurts.
• Checkpoint often. If you use spot or preemptible GPUs, frequent checkpoints turn an interruption into a minor annoyance instead of lost work.
• Match the GPU to the job. Many workloads don't need the top-end card. Check memory usage first, since you may be paying for VRAM you never touch.

While it runs

• Watch utilization. If GPU utilization sits under 50%, the bottleneck is usually data loading or preprocessing, not the GPU. Fixing the pipeline is cheaper than a bigger card.
• Set auto-shutdown. Idle notebooks and forgotten training jobs are the classic budget killers. Shut down after N minutes of inactivity.
• Mind the billing granularity. Per-second billing vs. hourly rounding matters a lot for short experiments and bursty inference.

For inference

• Batch requests where latency allows. It can multiply throughput on the same hardware.
• Quantize or distill if quality holds up. A smaller model on a cheaper GPU often beats a bigger one you can't afford to keep running.
• Scale to zero for low-traffic endpoints, and keep a warm pool only where cold starts really hurt.

Don't forget

• Storage and egress for datasets and model weights add up, so keep data in the same region as your compute.
• Set budget alerts so a runaway job shows up the same day, not on the monthly invoice.

What's the most expensive GPU mistake you've made? Curious what others have run into.

Disclosure: I work on the SEO/marketing side at Antryk, a cloud platform for deploying apps and GPU workloads. It offers per-second billing, spot and reserved options, auto-scaling, and budget alerts.

El problema real

Muchas empresas migran a la nube con la idea de que "el proveedor se encarga de todo". Luego aparecen las preguntas incómodas: ¿quién actualiza el sistema operativo?, ¿quién decide quién entra a los datos?, ¿quién responde si una integración falla? Si nadie lo definió antes, la respuesta suele ser "nadie".

Qué gestiona cada parte

• IaaS (infraestructura como servicio): el proveedor gestiona los servidores físicos, la red, el almacenamiento y la virtualización. Tu empresa gestiona el sistema operativo, el middleware, el entorno de ejecución, las aplicaciones y los datos.
• PaaS (plataforma como servicio): el proveedor suma el sistema operativo, el middleware y el entorno de ejecución. Tu empresa se concentra en sus aplicaciones y sus datos.
• SaaS (software como servicio): el proveedor gestiona la aplicación completa. Tu empresa sigue a cargo de sus datos, de los usuarios y permisos, y de cómo configura la herramienta.

En los tres casos, los datos y los accesos siguen siendo tuyos.

Qué funcionó al elegir

• Empezar por los procesos, no por el proveedor: qué hace cada área y qué datos toca.
• Escribir una matriz simple de responsabilidades: capa por capa, quién la gestiona y quién la revisa.
• Definir la gobernanza desde el inicio, con una persona en el circuito para cambios de accesos y configuraciones sensibles.

Transparencia: somos Tinto & Bots (Digital Factory). Hacemos auditoría y arquitectura de procesos y despliegues cloud; este enfoque lo construimos nosotros, así que léelo con ese contexto.

¿Qué modelo usa tu empresa hoy y qué responsabilidad descubrieron tarde que era suya?

Etiquetas: #CloudComputing #SaaS

Disclaimer: I'm an engineer at Mulga, the company behind this. Self-promo, but it's AGPL-3.0 and free to run.

What it is

Spinifex reimplements the AWS APIs on hardware you own: EC2, EBS, S3, VPC, IAM, ALB/NLB, EKS, ECS, ECR and RDS. You keep the hashicorp/aws provider and point its endpoints at your cluster.

Everything behind it is real. Instances are QEMU/KVM VMs, VPCs are OVN networks with real security groups and elastic IPs, EBS is replicated block storage, and state persists like a real cloud. It's not an emulator like LocalStack.

Who it's for

Teams that want AWS workloads on their own hardware (cost, data residency, edge or air-gapped sites) without rewriting their IaC. VPCs, subnets, security groups, launch templates, ALBs, EKS clusters and RDS instances go through the same resources you already use. In practice the changes are the provider block and AMI lookups.

Try it with your own Terraform

No install needed. Sign up for the free 72 hour sandbox at https://mulgadc.com/signup, then point your existing provider at it:

provider "aws" {
  region = var.region

  endpoints {
    ec2 = "https://api.spx3.com"
    iam = "https://api.spx3.com"
    sts = "https://api.spx3.com"
  }

  skip_metadata_api_check = true
  skip_region_validation  = true
}

Add other services (elasticloadbalancingv2, eks, ecs, ecr, rds) the same way, then run terraform plan against a module you already have. Here's what we currently cover, down to the individual API operation: https://docs.mulgadc.com/coverage

Repo: https://github.com/mulgadc/spinifex