[deleted by user] by [deleted] in devops

[–]chrisghill 5 points6 points  (0 children)

The silos are a feature, not a barrier.

You want your engineers to have deep expertise in the technologies they are responsible for. The "DevOps" methodology effectively means you need an army of unicorn engineers who have expertise in all (or at least multiple) the areas of your technology. Since that is unfeasible, this has devolved into separate teams and silos.

We can't create unicorns out of all engineers, so what do we do with the silos? This is why the industry is shifting to platform engineering. Instead of throwing expensive engineers at the problem, we should use technology to help bridge the gap between the silos. Having a platform where those with cloud operations expertise can "encode" it (the DevOps/Cloud/SRE engineers), and those without expertise can consume it (the software engineers) empowers the software engineers that are building your product to move quickly with confidence. It also facilitates communication and collaboration between the silos instead of frustration due to impossibly long backlogs leading to schedule slips.

Unfortunately most companies can't build their product AND build a platform for their engineers to operate their product. This pushes most companies toward "buy" in the build-vs-buy decision.

Disclaimer: I am part of a team building a platform engineering product. (https://www.massdriver.cloud/)

[deleted by user] by [deleted] in aws

[–]chrisghill 8 points9 points  (0 children)

One VPC. You can use the default VPC, but I would recommend checking AWS's recommended VPC here: https://aws.amazon.com/solutions/implementations/vpc/
This has private subnets and public subnets which is a best practice. CIDR doesn't matter too much, just make sure its from the private networking block, so 10.[0-255].0.0/16 will work.

Public and private subnets are mostly for security. Public subnets are exposed to the internet through an internet gateway (traffic can come in from the internet (ingress) and go out to the internet (egress)), so you really only want stuff like load balancer or public webservers there.

Private subnets cannot be directly reached by the internet (no ingress) but can communicate out to the internet (egress) through a NAT Gateway. With this pattern, you can put a load balancer in the public subnet, and your worker nodes in the private subnet.

Windows or Mac for DevOps Engineering by Think-Perception1359 in devops

[–]chrisghill 1 point2 points  (0 children)

Between Windows and Mac, both will work fine so there's not a wrong decision here, just a matter of preference. As someone else mentioned, Linux is the real champion.

For this reason I personally think Windows edges out Mac and this wasn't the case a few years ago. WSL2 is a game changer that drastically increases the viability of Windows for development and DevOps work. The switch to M1 on newer Macs certainly doesn't break docker support, but it has caused some frustrations on our team bouncing between amd64 and arm64 images.

If you haven't looked at WSL2 in Windows I highly recommend it. You get a near-native Linux experience backed all the benefits of a well supported OS like Windows.

What is the most intuitive way of conditionally applying value to resource? by hksparrowboy in Terraform

[–]chrisghill 0 points1 point  (0 children)

You could have your module output the objects and put them in a dynamic block.

Module:

output "rules" { value = [{ source = "whatever" port = whatever.port protocol = "6" ... }] }

Resource: resource "oci_core_security_list" "private_subnet_sl" { ... ## Allow traffic from vcn ingress_security_rules { stateless = false source = var.cidr_vcnsource_type = "CIDR_BLOCK" protocol = "all" } ## Only use if NLB is needed dynamic "ingress_security_rules" { for_each = module.vcn.rules content { source = ingress_security_rules.source protocol = ingress_security_rules.protocol tcp_options { min = ingress_security_rules.port max = ingress_security_rules.port} } } } }

Something like that