rorychatt

Why is significant economic value the metric for success?

Skoda publishes the research and design openly (no patent, no product for sale), to solve a real problem (increase in bike-related accidents from noise cancelling headphones), to ensure that the safety outcome can be spread as quickly and easily as possible.

We should be celebrating companies that open source material findings related to safety, not lambasting them for not exploiting it for maximum value.

it feels disingenuous to lump this in with most of the other items you listed.

ha. Cloud Native ≠ Native Cloud Services.

I always found it odd that the marketing successfully pivoted the term Cloud Native from meaning 'managed services consumed as APIs over the internet' to a generic umbrella for self-hosted versions of the cloud control planes and container management tooling.

That isn't a dig at the particular tools themselves - they just aren't... you know... cloud.

The bet is that compute gets cheap enough before the crunch that it won't matter. You should model it at 10x - but you also need to factor in NPV and opportunity cost. Even if pricing spikes later, the value extracted at today's rates might still put you ahead overall.

The relevant comparison for most enterprise isn't whether $15/PR is subsidised - it's whether it beats the alternative. For most shops that's cheap offshore labour plus the principal engineer time spent reviewing it, managing it, and fixing what got merged anyway. Most enterprise code is trivial CRUD - if the LLM generates it and reviews it to an equivalent standard, you're already ahead.

Yes

Very strange, this has always worked for me with Zed - both with local and remote ssh sessions.

I use `"autosave": "on_focus_change"` which may be keeping my buffer in sync with the file contents as I switch between terminal and zed.

I had this today when I cancelled a Microsoft Subscription, where it asked me for feedback on why I left.

One of the options they gave was because "My company needs an AI solution".

None of the options had anything to do with why I was unsubscribing.

Building out test infrastructure for correctness to support the project sounds like a fantastic idea.

That said, while it's compatible with Linux via fuse, unless you're helping to build RedoxOS, I don't think there's any real expectation that you would try it.

I found things got a lot better when the proper apis and terraform zpa/zia coverage happened

Still many foot guns, but I’ve much the same feelings for most of the tooling in the proxy/vpn space.

why that's a bad idea

Given that traffic inspection for user and service proxies rely on MITM traffic inspection for many forms of IPS/IDS beyond basic SNI signature detection - I'd love to hear more!

I'm not necessarily suggesting it should be mandatory - I remember the pain of introducing Zscaler about a decade ago and the sheer number of windows apps that simply broke, leaving a trail of complex PAC files - but not enough to warrant off the solution.

I would assume the half way house would be to leave Name Constraints off your offline CA, maintain (at least) one intermediary with constraints turned on for regular certificate lifecycle management for internal certs, and a dedicated intermediary that is only used to generate the MITM certs?

staging->prod is a merge

I might be misunderstanding what you mean by staging in this case. If so, my bad!

I don't think staging ever actually gets merged into prod via git history, but is rather maintained as separate commit trees.

The way that I visualised the steps in this flow was something like:

  - Developer Commits code to feature branch
  - Developer Opens PR to Main from feature branch: Ephemeral tests, linting, validation etc occurs
  - Dev Merges PR
  - CI checks out main, finds the helm charts that have changed, and runs the equivelant of `helm template mychart`, and caches the results
  - CI then checks out staging (which is an entirely different HEAD, and structure), finds the relevant folder where that chart will sit, wipes the contents, and checks in the new chart contents.
  - Argo watches branch, applies changes as they appear
  - CI waits for validation test process to occur
  - CI then checks out prod, and carries out the same process (i.e. no merge step from staging to production).

The way you then deal with a delta (like ver 1.0.1 in your earlier example) is to create a PR directly against the Prod branch, and then next time you do a full release, it just carries out the usual process, 'ignoring' what was there previously.

It's basically re-invented the terraform delta flow, but instead of the changes being shown via Terraform by comparing state and template, it's comparing template and template in git.

ultimately couldn’t get the tooling and workflow to fit together when I last tried this

I genuinely feel like this is the bane of most tooling in this space. Getting stuff from 'I can run this job execution on my desktop', to 'this process can scale across multiple teams, integrated across many toolchains and deployment environments, with sane default' still feels like a mess today.

edit: HN Formatting

I believe the idea is that it makes it very explicit to track provenance of code between environments, eg merge staging->master is a branch merge operation.=

That isn't quite my understanding - but I am happy to be corrected.

There wouldn't be be a staging->main flow. Rather CI would be pushing main->dev|staging|prod, as disconnected branches.

My understanding of the problem being solved, is how to see what is actually changing when moving between module versions by explicitly outputting the dynamic manifest results. I.e. instead of the commmit diff showing 4.3 -> 5.0, it shows the actual Ingress / Service / etc being updated.

With directories you need to resort to diffing to spot any changes between files in folders.

Couldn't you just review the Commit that instigated that change to that file? If the CI is authoring the change, the commit would still be atomic and contain all the other changes.

but if you have a workflow where hot-fixes can get promoted from older versions

Yeah 100%.

In either case, I'm not saying it's wrong by any stretch.

It just feels 'weird' to use branches to represent codebases which will never interact or be merged into each other.

While I agree generally with the pattern (dynamically generating manifests, and using pipelines to co-ordinate pattern change), I could never quite figure out the value of using Branches instead of Folders (with CODEOWNER restrictions) or repositories (to enforce other types of rules if needed).

I can't quite put my finger on it, but having multiple, orphaned commit histories inside a single repository sounds off, even if technically feasible.

More generally, do you have to legally agree to Terms and Conditions to communicate with service provider's servers over HTTPS? Do you legally agree to them after you communicate one packet in such a way?

Browsewrap agreements (agreeing by using the site) are pretty much unenforceable to your point. I'm not sure this is the same thing however.

Youtube don't offer a customer facing consumable service for offering an ad free experience outside of Premium or their Developer API. The app is deliberately bypassing the provided services. Bypassing those published mechanisms is hacking, and depending on where you are, may not be legal. I suspect for most consumers of HN, this would be the case.

Browser crawlers fall under fair use. I'm not sure this does.

I get it. I don't like ads either.

I'm not sure.

IANAL, but reading the developer policy, reference is made to include the Youtube Developer Site & Services, but is not exclusive of other Youtube API Services.

Whether Invidious uses a Public Developer API, a Broker offering their own API, or a workaround with an internal API seems inconsequential.

https://developers.google.com/youtube/terms/developer-polici...

    #  Client: `"API Client" means a website or software application (including a mobile application) developed by you that accesses or uses the YouTube API Services.`

    #  Service: "YouTube API Services" means (i) the YouTube API services (e.g., YouTube Data API service and YouTube Reporting API service) made available by YouTube including those YouTube API services made available on the YouTube Developer Site (as defined below), (ii) documentation, information, materials, sample code and software (including any human-readable programming instructions) relating to YouTube API services that are made available on https://developers.google.com/youtube or by YouTube, (iii) data, content (including audiovisual content) and information provided to API Clients (as defined above) through the YouTube API services (the "API Data"), and (iv) the credentials assigned to you and your API Client(s) by YouTube or Google."

Is this legal?

In Google's Terms and Conditions, it's says that bypassing ads violates Youtube's terms and conditions. https://support.google.com/youtube/answer/14129599?hl=en#:~:....

I get what the author is saying, but I feel like many of the examples provided have more to do with poor culture and chronic mismanagement rather than issues with “agile” itself.

However, I don't believe Agile is the root cause of tech laziness. No framework encourages underestimating capacity or wasting time on distractions like “TikTok smoothies”. This issue stems from people and performance problems, which would likely exist regardless of the planning framework.

Before adopting Agile, I experienced the need to justify financial spending on Waterfall plans for non-existent hires/teams, two years in advance. With quarterly agile planning cycles and static teams, we spent significantly less time worrying about whether we’d get people at all, and more time looking at the teams' overall velocity and outcomes.

I wouldn’t have been able to do any of that without the estimations and structure that the author despises.

The reality is, in larger companies, teams don’t exist in a bubble. They need to justify their outcomes, plans, and velocities, or they get laughed out of the room by finance and budgets slashed. Frameworks around agile (SAFe/etc) give tools that help management to forecast and finance investments into their teams. If I didn’t have estimations and velocity, and a way to break down and visualise work,

I don’t get what the author suggests the alternative is. I’m sure some teams have full autonomy and trust to do whatever they want without oversight by finance and PMO, but my experience is that is few and far between (or small enough where the team and upper management are one and the same).

While I've encountered my fair share of subpar Agile implementations, it doesn't mean we should abandon the concept altogether. The widespread adoption of Agile suggests a genuine need for improved working methodologies.

Instead of advocating for Agile's downfall, let's acknowledge the necessity of tools for sharing roadmaps, streamlining transitions between teams, and assisting management in making data-driven investment decisions. By doing so, we can collaboratively refine and adapt Agile methodologies to better meet the evolving needs of contemporary organisations.

We use Terraform extensively at our organisation. Some examples come to mind that make this impractical: - For services that do support tags, we are already reaching limits on the number of tags that can be associated with a single resource. For example, in Azure, some resources still only support 10 unique key/values - Drift detection against write, but no read secrets mean that you cannot do drift detection over certificates, and secrets. Depending on your organisation and how they manage things like PKI, this may be impractical to track validity of the endpoint. - Many services we manage don't have tags. For example, we use Terraform to manage Github Repositories, Actions, AzDo Pipelines, and Permissions - Some object types simply don't have primary keys that are easily searchable by the provider, and requires some sort of composite key to be compiled and tracked.

State gives us a common schema and playing field to significantly simply the generation of dependency graphs and show drift. I imagine that even without a 'statefile', you would end up having to generate a similar graph in memory anyway.

In the organisations I have worked, we have normally done something like this:

- <environment>-<component>-<application>.<application-portfolio/team>-<tenancy>.<hosting-environment>.<business_name>.com

This allowed us to delegate hosted zones to the application teams to self-manage their dns.

Example, the hosted zone:

- marketing-nonprod.aws.example.com

Would appear as a hosted zone in the Marketing, Non-Production aws account. Note that we track the "Tenancy Environment", i.e. whether it's a prod/non-prod/labs. This will map to multiple application environments, e.g. UAT/INT/etc will be under non-prod.

Then an application like:

- prod-web-app.marketing-prod.aws.example.com

could have a cname to:

- app.example.com

Which we would handle as a one-off service request to the central DNS management team (often dealing with things like Akemai at that stage).

If the application stack required multi-regionality, we could added a regional identifier into the application name.

My approach is overkill in many orgs. Many of these issues are made simpler through mechanisms like service discovery.

An argument can be made that this is what Test Driven Development is here to solve. State intent in the test, not the comment.

That said, I agree it can be a helpful contextual clue.

It's a shame, BDNA's Technopedia used to have an excellent, free online search engine that could be leveraged to search EOL information.

For context, Technopedia is a library that, for a yearly subscription, could supplement detailed supplier End of Life/Support/Extended details onto your CMDB/Asset Management System. It was a godsend when dealing with large software audits.

Flexera have since acquired BDNA, and from the looks of things, the public access to the system has been locked out: https://portal.technopedia.com/landing

Might be worth checking out for those who are in large orgs and have to deal with this problem en mass.

Can you talk to the problem Docker-Run is trying to solve? It's already relatively easy to deploy docker containers today (AWS/Azure/GCP/DigitalOcean/etc) and even have them pipe to the browser like this.

Without an ecosystem of services to integrate (Identity/Storage/DB/Queue/DNS/LB/Network/etc), containers aren't awfully useful.

What is the differentiator?

EDIT: grammar

I'm all for the separation of concerns for managing underlying services! I just suspect most organisations have the scale to warrant running it themselves.

Lets say it takes 5 engineers at 100k each to maintain the K8s and FaaS service internally. Are we getting 500k+ _more_ benefit from that internally managed platform than offloading it to a third party? What is the cost of exit from one platform to another if we just used the native services?

As long as the service management of FaaS continues to sit with your organisation, it feels disingenuous to call it Serverless. We lose out on the per invocation opex costing model, the benefit of scaling offloaded to a third party and the well integrated ecosystem of services which Serverless developer paradigms really shine.

B) Full disclosure, I work for a software consulting company. We are partners with AWS, Google and Azure. I'm relatively agnostic, although my preferences would be somewhere along AWS > GCP > Azure.

"I would always go for Openshift (not working for Red Hat) since they are much better at getting on-prem to work than k8s, and you have the almost same setup and interaction experience throughout all your clouds."

That true if we plan to run _everything inside the OpenShift cluster_; our own database, analytics, logging, iam, secrets managers, etc.

As soon as we get other cloud hosted services involved, the integration becomes really clunky and our teams end up split braining between two orchestration layers which aren't well integrated. An example of this would be Networking and Databases in AWS - You simply can't do microsegmentation inside and outside of the Openshift and cloud networks. Assuming you wanted to offload databases to RDS (and you should), all your security groups are going to have open traffic flow from every node in your Openshift Cluster, whether those nodes are tied to the Databases App partner or not. Welcome back perimeter based traffic rules!

And since the networking and database part of the deployment scripts are tied to a specific cloud, I need to re-write them to move workloads around anyway... So why not just re-write the whole deployment job to use a native service?

Why not start with Fargate/App Engine, or skipping containers all together and going straight to FaaS on your cloud of choice?

Small companies seem like the primary choice to skip container orchestration layers completely.

Pivotal haven't launched a serverless framework, they've launched a FaaS(ish) framework.

Serverless implies that the management of the underlying infrastructure is owned wholy by a third party, and the only exposure to you is the higher order abstractions, leaving you to only worry about the business logic.

This is not that.

You still need to water and feed a Pivotal/K8s platform, and those things are awful to run.

"What’s interesting about Pivotal’s flavor of serverless, besides the fact that it’s based on open source, is that it has been designed to work both on-prem and in the cloud in a cloud native fashion, hence the Kubernetes-based aspect of it. This is unusual to say the least."

This isn't unusual. Every software house seems to be building a dream of hybrid cloud on-top of Kubernetes. Rightscale, Openwhisk, Cisco Cloud Centre, IBM Cloud Private, ServiceNow and others build their sales strategy across cloud mobility.

This dream of cross cloud portability needs to die. You either end up:

Option A

- Leveraging the cloud native logging, storage, networking, database and analytics services, leaving behind only the container layer which is portable. By this stage, you end up having to re-write those parts of the json/yaml/terraform to handle deployments into other clouds ANYWAY. So what's the benefit again?

It also encourages you to do stupid things like single account deployments in AWS since federation for these abstraction layers are still very much a pipe dream, significantly increasing the blast radius concern.

Option B

- You run your own logging, storage, networking, database and analytics services inside the K8s which defeats the entire point of being in the cloud in the first place.

Being cloud agnostic is a great pipe dream, but the economics of running an abstraction layer (Pivotal / Openshift / Mesos) vs cost of exit just doesn't add up for 99% of companies. Just use the native FaaS/Data/Analytics.