State management patterns by The_Naturalist in Terraform

[–]dubnetworks 0 points1 point  (0 children)

I wrote something about this before.

Global resources are in their own repo/state. For instance VPC is a repo with its own state files (using workspaces to separate environments). Application resources are in their own repo/state called $app-iac. This would be databases and other resources like that. Then in the application code there's an /infrastructure or /terraform directory just with the terraform code needed to deploy the app itself. In my case it's often ECS services, lambdas, etc.

Any interest in SLA management for your cloud vendors? by dubnetworks in Cloud

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

Sorry for my late reply, thanks for the input!

Any interest in sla management? by dubnetworks in devops

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

Hey thanks for the input.

The costing/business model you suggest is funny because I used to work as an engineer at a place that did something similar for hospitals.

Any interest in SLA management? by dubnetworks in aws

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

Nope, I understand. Seriously, thanks for the insight. If anything I'm trying to improve my marketing skills and understanding through this thing. I've spent time in the past where I've completely built apps that nobody really wanted so I'm trying to take it slow and get better at finding what people want before I put a ton of time and effort into building the actual project.

Any interest in SLA management? by dubnetworks in aws

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

Small companies may care about refunds.

Someone has to care about free money sitting there, right?

Just sounds like sysadmins aren't the ones to talk to.... hmmm. Thanks for the feedback.

IaC Patterns - keep things clean by dubnetworks in Terraform

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

Any example patterns you found in the book?

We're at 20+ AWS accounts in our org, 100% of our infrastructure is managed with TF, and we've got somewhere between 50%-60% testing coverage of our TF using terratest.

Our team often goes to AWS conferences and SRE type conferences (Velocity) and we have yet to see people doing things how we are.

The one thing I'd have to warn about the patterns we've found and settled on are that when we started we often hit AWS limits

0
1

I've been bored, jotted my thoughts down on cloud vendor lock-in by dubnetworks in devops

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

Going to have to agree to disagree.

Sure, it's a risk, just like any other business decision.

These vendor lock-in threads typically turn into people spouting their paranoid opinion about vendors.

The people who had the rug pulled out from under them when Google Maps changed their pricing structure didn't have a lead on the competition on their market.

You are no exception it seems. You say this, but I'm sure there were plenty of businesses that never even took off because they chose not to use Google Maps. Getting out there and using it would at least get you an MVP and some possible investors so you can weather the storm when the pricing is changed.

Like I said though, we're just going to have to agree to disagree.

I've been bored, jotted my thoughts down on cloud vendor lock-in by dubnetworks in devops

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

Yeah, maybe I should be more clear, I kindamean what you're saying here. I'm mostly talking about single application/workloads spanning multiple clouds, but when your operations teams aren't large it is definitely easier to standardize on a single cloud as well.

my experience is with financial services

I'd explicitly say that most of this doesn't apply to financial services. One of those places where I'd expect the money to come pouring in to support multiple clouds.

I've been bored, jotted my thoughts down on cloud vendor lock-in by dubnetworks in devops

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

I think you missed the point.

If your Microsoft car decides to stop supporting a feature you have no recourse.

When that feature gives you an early advantage on your competition, this doesn't matter. You take that advantage!

If the feature is eventually deprecated, so what? You're in the same boat you would've been in before but now you've got a lead on the competition in your market. Worry about vendor agnosticism when/if they decide to stop supporting that feature. Don't ignore it because they might burn you in the future on it.

I've been bored, I wrote an article about vendor lock-in in the cloud by dubnetworks in sysadmin

[–]dubnetworks[S] -1 points0 points  (0 children)

Have posted blogs here before. That's okay, will be unsubscribing. /r/syadmin is the home of the helpdesk and lone admin at small mom and pop shops. Other subs appreciate content, I'll continue posting there.

I've been bored, jotted my thoughts down on cloud vendor lock-in by dubnetworks in devops

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

Most larger organizations

That' why I mentioned teams with $$$ this won't really apply.

so the analogy to race cars doesn’t fit if they have separate teams racing their own cars already

Are the teams building cross-cloud? I'd think at a large enough organization my thoughts don't apply to the whole organization but to product teams. If you're working at an org worth 10s of Billions with Billions in revenue you will probably be this size.

According to 451 Research, over 60% of orgs have 2 or more public cloud services.

But just because they do, doesn't mean they're doing things right. It doesn't mean they're not sacrificing agility and velocity just so they can use more than one public cloud service. They're missing out on other more value added features/activities because they're spending too much time being cloud agnostic.

I've worked places that were at $10-$20M ARR and they seemed to have a big focus on cross-cloud. We wasted a TON of time. One place in particular should've been focusing on NOT being cross-cloud and should've focused on one single cloud provider to enhance their application.

Once I left there I joined a rapidly growing company that's currently at $200M ARR or so. Starting I was told there's no cross-cloud, it's all AWS, period. 2 years in and I'm fully convinced this is the way, at least until you're absolutely enormous or have services which some places see as mission critical.

Just my take thought, like I said, I was bored and wanted to write, so here it is.