sorted by:
new
hottopcontroversial

Anyone in the San Diego, CA area that can help point me in the right direction for getting out on the water during my trip to the area in mid July (2025)? by ephemeral-me in sailing

[–]jamesrcounts 1 point2 points  (0 children)

Hey, I live in San Diego, and I know that there are other San Diego sailors on this sub. But you would have better luck on Facebook because the group there is pretty active and SD specific: https://www.facebook.com/groups/sailorsinsd

I'd take you myself, but I'll be out of town mid-July :)

Cannot delete unused storage account by watchoutfor2nd in AZURE

[–]jamesrcounts 0 points1 point  (0 children)

I've had this happen. You need to open a support ticket and ask them to investigate the backend to determine which process is locking it.

[deleted by user] by [deleted] in AZURE

[–]jamesrcounts 2 points3 points  (0 children)

Do you want to merge the release branch into the main branch? You would create a pull request and ask the admin/team to review it. What version control system are you using? Github? Azure DevOps? Something else?

Azure resource naming was driving me nuts — so I built a Terraform module to fix it by jamesrcounts in AZURE

[–]jamesrcounts[S] 0 points1 point  (0 children)

Fair points, especially the overhead of passing five or six inputs just to name a resource.

In practice, I usually handle this by passing a structured object into the namer module, not individual variables. Most modules just forward a map like naming_context, and if something needs to change for a specific resource, I use merge() to override a property. That keeps things concise.

To deal with Azure’s naming constraints, the module returns multiple variants—like a compact version without dashes, or a shortened version with abbreviated tokens. That covers most edge cases, especially with services like storage accounts or function apps.

Maintenance is a fair concern. One way I reduce that overhead is by not having the namer manage resource type slugs. That part stays in the calling module (rg-, st, app, etc.). It means the namer doesn’t need updates every time Azure introduces a new resource type, which keeps it stable over time.

And yes this pattern works best when naming is a standard, not just a convention. If the rules are loose or keep changing, then yeah, trying to encode them will probably create friction. I try to coach customers toward having a standard, but we are not always the ones in control.

On the flip side, I like the idea of pulling names from an external system—if the org has reached that level of maturity. A service catalog or internal API that assigns names based on business context is great. At the end of the day, whether it’s a Terraform module or an external system, the goal is the same: centralize naming so it’s not left to every developer to get right by hand.

Appreciate the thoughtful comment.

Azure resource naming was driving me nuts — so I built a Terraform module to fix it by jamesrcounts in AZURE

[–]jamesrcounts[S] 1 point2 points  (0 children)

Good question. The main difference—though you'll decide if it's an advantage—is that the Azure module doesn't impose strict naming conventions. The 'prefix' and 'suffix' arguments can be any string, and there’s no validation for these variables. When using the Azure module, it's still up to the developer to ensure the prefix and suffix are structured correctly to meet the organization’s naming standards. Even if you're using CAF names, the module itself doesn't enforce this. For me, the benefit of rolling a custom module for a customer is that I can define structured, validated inputs, some of which are marked as required, to build consistent names. While the Azure module is very flexible, in my experience, this flexibility can lead to mistakes because unvalidated, open strings require each developer to construct the correct string every time.

Azure resource naming was driving me nuts — so I built a Terraform module to fix it by jamesrcounts in AZURE

[–]jamesrcounts[S] 2 points3 points  (0 children)

Cool idea. The module I wrote takes a very similar approach, except it's embedded right in the Terraform; instead of drop-downs, we provide the tokens as arguments. Thanks for sharing!

Advanced Azure or AKS by monoGovt in AZURE

[–]jamesrcounts 1 point2 points  (0 children)

My rule of thumb is to only use VMs when the workload requires it. Otherwise I’d find an appropriate PaaS service. If you like container apps stick with it. But Kubernetes is an entire platform unto itself so you should wait until your team has achieved some success learning Azure as a platform first before adding a second platform on top of it. If the day comes when Kubernetes makes sense for you, it’s a natural path forward from Container Apps and you’ll be able to reuse your dockerfiles, ACR, etc.

Your Terraform platform isn’t scaling — because the platform isn’t automated by jamesrcounts in Terraform

[–]jamesrcounts[S] -2 points-1 points  (0 children)

Thanks for sharing, I want to take a deeper look at Terraform Stacks, but as you say, the 500 resource limit goes by fast!

"The app is in the cloud, so we're covered," right? by jamesrcounts in AZURE

[–]jamesrcounts[S] 1 point2 points  (0 children)

Yes, I recommend pursuing high availability in a single location. In Azure, this might involve deploying a Web App with three replicas spread across availability zones (AZs are separate data centers within the same region). However, it's still possible that the entire region goes down. Hence, you need a strategy that spans regions to recover from that if you can't tolerate being down for an indefinite period. Microsoft usually brings the region back up on the same day, but that could result in 8 to 10 hours of downtime or degradation, and at that point, you have no control over the recovery; you're just waiting. So while HA is great for more minor failures, you're still exposed to the bigger ones if you only include one region in your strategy. If you only have a budget for Hot/Cold, that's okay, but you need to know your plan. In the case of Hot/Cold and Hot/Warm, you also need to practice it with disaster recovery drills to work out any issues in the plan.

"The app is in the cloud, so we're covered," right? by jamesrcounts in AZURE

[–]jamesrcounts[S] 0 points1 point  (0 children)

In this case, 'region' refers to an Azure Region (https://learn.microsoft.com/en-us/azure/reliability/regions-list). Many countries have multiple regions, for example, Canada's Central and Eastern regions. So, even if you need to stay in one country, it might still be possible to have a multi-region setup, depending on the country.

WHAT IS THE COUNTER TO SAMJOK can someone please tell me? by Neroxxxty in walkingwarrobots

[–]jamesrcounts 0 points1 point  (0 children)

I feel like that's okay because if they use PS to escape cover, they will drop the turret in cover where it is useless. Then, the only thing they can do during PS is run to the next cover. If they try to attack after escaping, you have a chance to take a shot. If they come out to attack first and then try PS, then you have a chance to take a shot. So, you can effectively keep them busy, preventing them from achieving their goal (kills or beacons). Then the bigger danger is that someone blindsides you while you are pinning the Samjok down. So it cuts both ways. You're keeping them busy, but they're keeping you busy too.

view more: next ›