Earlier quoted context omitted.
I thought you meant API and parameters. Blaming them for product names is weird to me.
aws api and param names are stupidly long CamelCased and not even consistent half the time like a leaky abstraction over their underlying implementation
Almost every infrastructure decision I endorse or regret
531–540 of 644 posts
Re: Almost every infrastructure decision I endorse or regret
#532Earlier quoted context omitted.
I am confused. Doesn't Modal Labs solve this?
Definitely. But the sad reality is that in some corporate environments (incumbent finance, government) if it's not a button click in portal.azure.com away, you can spend 6-12 months in meetings with low energy gloomboys to get your access approved.
Re: Almost every infrastructure decision I endorse or regret
#533So by and large I agree with the things in this article. It's interesting that the points I disagree with the author on are all SaaS products: > Moving off JIRA onto linear I don't get the hype. Linear is fine and all but I constantly find things I either can't or don't know how to do. How do I make different ticket types with different sets of fields? No clue. > Not using Terraform Cloud No Regrets I generally recom…
You're staying within an ecosystem you know and it seems to offer almost all of the necessary functionality
Re: Almost every infrastructure decision I endorse or regret
#534Re: Almost every infrastructure decision I endorse or regret
#535I feel like this is overkill for a startup. Why not dump your application server and dependencies into rented data center (or EC2 if you must) and setup a coarse DR? Maybe start with a monolith in PHP or Rails. None of that word salad sounds like startup to me, but then again everyone loves to refer to themselves as a startup (must be a recruiting tool?), so perhaps muh dude is spot on.
I don't want to be negative, but this post reads like a list of things that I want to avoid in my career. I did a brief stint in cloud stuff at a FAANG and I don't care to go back to it. Right now I'm engineer No. 1 at a current startup just doing DDD with a Django monolith. I'm still pretty Jr. and I'm wondering if there's a way to scale without needing to get into all of the things the author of this article mentio…
One thing though, I'd start with go. It's no more complex than python, more efficient, and most importantly IMO since it compiles down to binary it's easier to build, deploy, share, etc. And there's less divergence in the ecosystem; generally one simple way to do things like building and packaging, etc. I've not had to deal with versions or tooling or environmental stuff nearly as much since switching.
Re: Almost every infrastructure decision I endorse or regret
#536Earlier quoted context omitted.
> K8S is a disastrous complexity bomb. You need millions upon millions of lines of code just to build a usable platform. I don't know what you have been doing with Kubernetes, but I run a few web apps out of my own Kubernetes cluster and the full extent of my lines of code are the two dozen or so LoC kustomize scripts I use to run each app.
If you're using a K8S cluster just to deploy a few web apps then it's not really a platform that you could provide to an engineering team within a medium-large company. You could probably run your stuff on ECS.
Re: Almost every infrastructure decision I endorse or regret
#537Earlier quoted context omitted.
Perfect list, also: Google Cloud Run - Lambda Sure I get the reference to the underlying algebraic representation of coding but come on, Lambda tells us nothing of what it does. Products (not brands, products) should be named in a way that means something to the customer afaic.
Have you named any successful product?
Re: Almost every infrastructure decision I endorse or regret
#538Earlier quoted context omitted.
Perfect list, also: Google Cloud Run - Lambda Sure I get the reference to the underlying algebraic representation of coding but come on, Lambda tells us nothing of what it does. Products (not brands, products) should be named in a way that means something to the customer afaic.
> Perfect list, also: > Google Cloud Run - Lambda ECS is the AWS equivalent of Cloud Run. GCP Cloud Functions are the equivalent of AWS Lambda. ECS / Cloud Run = managed container service that autoscales Lambda / Cloud Functions = serverless functions as a service
Re: Almost every infrastructure decision I endorse or regret
#539Earlier quoted context omitted.
I'm currently early in my career and "the software guy" in a non-software team and role, but I'm looking to move into a more engineering direction. You've pretty much got my dream next job at the moment — if you don't mind me asking, how did you manage to find your role, especially being "still pretty Jr."?
What a coincidence! I've got my dream job too! The things I did to get here are honestly kind of stupid. I started out at a defense contractor after graduating and left in the first six months because all the software devs were jumping ship. Went to a small business defense contractor (yep that's a thing) and learned to build web apps with React and Django. Then the pace of business slowed so after about 18 months I…
In my case it took a good five years and a couple job hops to rebalance. But eventually you get back to a reasonable tech leadership role and back to making some of the bigger decisions to help make the junior devs' lives less miserable.
No regrets, but the five years it takes to rebalance can be pretty hard.
Re: Almost every infrastructure decision I endorse or regret
#540Earlier quoted context omitted.
Oh I disagree - we migrated from azure to AWS, and running a container on Fargate is significantly more work than Azure Container Apps [0]. Container Apps was basically "here's a container, now go". [0] https://azure.microsoft.com/en-gb/products/container-apps
Heh, your comment almost echos the positive thing I was going to say, as well as highlighting half of why I loathe Azure with every fiber of my being https://learn.microsoft.com/en-us/azure/container-instances/... is the one I was going to plug, because coming from a kubernetes background it seems to damn near be the PodSpec and thus both expresses a lot of my needs and also is very familiar https://learn.microsoft.c…