mycentstoo

We should design a specific language to make sure that we can encode the exact requirements that we want. Something that has a limited set of keywords that are explicit. Wait a minute...

I'm genuinely curious what a good survival strategy is for people at different levels within tech - junior, mid-level, senior, staff, etc.

I believe choosing a well known problem space in a well known language certainly influenced a lot of the behavior. AIs usefulness is correlated strongly with its training data and there’s no doubt been a significant amount of data about both the problem space and Python.

I’d love to see how this compares when either the problem space is different or the language/ecosystem is different.

It was a great read regardless!

I am just not having this experience of AI being terribly useful. I don’t program as much in my role but I’ve found it’s a giant time sink. I recognize that many people are finding it incredibly helpful but when I get deeper into a particular issue or topic, it falls very flat.

The market value of software diminishes as it becomes significantly easier to write.

And to add-on, isn’t there some market dynamics we are avoiding here with this example? If I’m an AI company and really produced a principal level engineer, why would I sell it for less than the labor market is willing to bear? Wouldn’t I price it perhaps less than the market but not so dramatically less as to lose money.

I’m genuinely curious on the point about reducing headcount because AI will be more efficient. I’ve seen it articulated here but other places too that a company will be able to have less engineers because each would be more productive. What if companies kept the same number of people engineers but now massively out produce what they used to? And I disagree with the example that this is like typewriters replacing typists. I think typists have a fixed number of things that need to be typed. Software is different - a company that has a better or more feature rich project could gain on their competitors.

Curious if anyone else thinks this. Maybe it’s just optimism but I’ve yet to be convinced that a company would want to maintain its productivity through trading engineers for AI if it had the same opportunity to grow its productivity through AI and maintaining headcount.

Oh I know, I live very close to there. I just wanted to add insight for those that might not be familiar with those being two separate things.

Additional Context: The Getty Villa which is on the border of Malibu and Pacific Palisades was the structure that was threatened by fire directly. This article is about the Getty Center which lies in Brentwood and fires did not reach it.

Center: 1200 Getty Center Drive, Los Angeles, CA 90049

Villa: 17985 Pacific Coast Highway, Pacific Palisades, CA 90272

I don't think I've personally ever been as disillusioned with technology more than with the recent rapid adoption of AI.

I think AI is massively negative on the environment via increased energy consumption to train large LLMs, on creative endeavors via the auto-generated art, etc. on labor via automation of jobs through AI agents, or the degradation of the job market, on public communication via the proliferation of fake videos/news, on personal relationships via AI significant others, on child development through easier cheating, etc, etc.

I get that there's a certain inevitability about technology. I also feel - and this could be a terrible analogy - that might have been what it was like to develop nuclear weapons. Better to develop and harness the technology for yourself if your competition is doing so too. That's the world and the market that we've constructed and it's rational to take advantage where you can.

I certainly don't pretend to stand on any moral high ground about what I would do if given the opportunity to cash out from AI skills if I had them.

But it all makes me very sad. I think I'll go read a book.

EC2s are provisioned with Terraform or if you want to bypass that, click-ops. Nothing custom is needed. You can define a small shell script that is known as userdata that runs when the EC2 boots. That's standard and used everywhere that EC2s are used.

If you want more customization - again not necessary - you can build via Packer. The thing is, you have to do that anyways with Docker or whatever your container runtime happens to be. Docker images need patches as well if you install dependencies like openssl, libpql, etc.

ArgoCD - ArgoCD is great but it's something that has to be separate managed and comes with a database, UI layer, etc. and it's own set of permissions. The whole point of ArgoCD is to have deployments specifically around GitOps for container-based applications. Unnecessary if you don't have K8s.

Load balancers are simpler with ALBs and route directly to the auto-scaling groups. Traeffik is something that you need to manage. Also, K8s typically requires the use of external load balancers to work in the cloud as it is which means there's a layer of complexity that was introduced. Typically, K8s through the External Load Balancer Controller will provision the LB and attach targets. So it adds complexity. Traeffik isn't free, you are paying for the compute in your cluster which has the overhead of the control plane.

Let's Encrypt is another layer of complexity that has to be managed. AWS has ACM which can dynamically create and renew your certifications without you having to do anything.

K8s as a cluster needs to be managed and introduces significant breaking API changes across minor versions (1.23-1.24, etc.). Postgres managed as a stateful application also breaks some of the benefits of K8s in that it needs to be managed as a StatefulSet rather than as a ReplicaSet which means you likely need different deployment mechanisms to avoid destroying it accidentally.

Ironically, this architecture doesn't need any customizations at all. You can provision it with a few modules in Terraform or you can click ops the entire thing. K8s on the other hand, requires pretty constant attention. You've now introduced the management of the cluster, the building of the image, management of ArgoCD, Traeffik as well as external load balancers.

Basically: - Route53 for domain management

- ACM for cert management

- EC2s for LBs

- ASGs to manage EC2s

- Small shell script within userdata to configure the host vm

- RDS if you need a database

Avoiding the operational and actual costs of K8s.

I think that there are compelling reasons to use K8s:

- Lots of smaller services that need to interface with each other

- Product is deployed to multiple clouds or in a hybrid setting

- Infrastructure team has deep expertise in K8s

Oh definitely that happens and from my experience I don’t think there’s a lot that can be done unless there’s strong faith in engineering leadership to push back on the complexity.

As an SRE who’s moved between a few companies recently, I’ve noticed a trend towards simpler infrastructure options rather than k8s. Most places I interviewed at used AWS with just fleets of EC2s managed through ASG and instance refresh.

Deployments are no downtime. It’s pretty nice and if you want to run with docker on the host instances you can but you can also just install the application using systemd.

A few infrastructure things:

- Serve traffic behind a load balancer that has a WAF

- Network segregation for database (separate subnets)

- Make sure you serve https and have a cert that’s valid. Redirect to https if http

- Restrict ports on LB

At some point later:

- Endpoint monitoring and threat detection

- VPC flow logging

- Execute backend as non root

- Dependency / artifact scanning

- Cloud SIEM to monitor common actions taken

- Make sure no hard coded creds. Ie, use role-base auth with cloud providers

- Reproducible infrastructure builds with infra as code

- Email domain protection

- Grab misspellings of domain names to prevent squatting