jrudolph

To be fair, GitHub has several magnitudes higher of revenue to support that. Including from companies like mine who are paying them good money and get absolutely sub-par service and reliability from them. I'd be happy for Codeberg to take my money for a better service on the core feature set (git hosting, PRs, issues). I can take my CI/CD elsewhere, we self-host runners anyway.

I wouldn’t be surprised if Google aims to replace Google Deployment Manager with this, which never really got any traction. Azure has ARM, AWA has Cloudformation. Google betting big on terraform will be interesting considering the recent change to BSL.

If Google decides to back OpenTF that would be a huge deal.

Getting a lot of docker hub vibes from this one. HashiCorp is course within their rights. Can't be cheap to run the registry given the obscene size of some terraform providers.

$ ls -lah terraform/providers/registry.terraform.io/hashicorp/aws/5.14.0/darwin_amd64/ total 368M

Anyone have an idea of the reasons terraform needs a 370 MiB binary just to call REST APIs?

I’m pretty confident of all the players in that market AWS is the least likely to pull that move.

On netlify iirc pricing was for every git committer that was allowed to trigger a deploy.

Render.com was more lenient in a model like you describe but still we have different people manage different apps and it adds up.

The appeal of a no-ops workflow for basic frontend apps is there. We’ve got a bunch of static docs sites built with vuepress and docusaurus that are a great fit for this. Not that we can’t whip up a CDN with terraform and a CI/CD pipeline with preview environments, but my team would rather spend its energy on our core product.

However we’ve been badly burned by vercel, netlify and render.com switching their pricing models to user based instead of infrastructure based pricing. We’re migrating to AWS amplify right now, which also happens to be wonderfully integrated into our wider IT landscape with an AWS landing zone, automated internal chargeback etc. It’s 90% the same for our use case and charges only for infra at standard AWS rates.

At this point I’m starting to wonder why it isn’t more popular.

also on the same blog -> https://tracy.posthaven.com/part-i-founder-led-enterprise-sa...

> German CVs basically require photos and other information

I‘not sure where you got that from, but that’s just false. Most employers I know actively ask candidates to not submit irrelevant info like photos, gender, religion etc. in their applications as any info is a liability for an employer.

Look up AGG law and how all too easy it is to get a massive slap on the wrist for even the slightest hint of discrimination. Add PII issues on top.

Other commenters have covered the workload lock-in angle pretty well. Using Kubernetes as a target platform for your application already gives you a decent shot a workload portability. Keep in mind though that some K8s APIs are leaky abstractions. You pay with lock in into K8s of course. At the end of the day, lock-in is a matter of tradeoffs.

An often overlooked angle is the "organizational lock-in" to the cloud. Adopting the cloud in any serious capacity with more than a handful of teams/applications means that you will eventually have to build up some basic organizational capabilities like setting up resource hierarchy (e.g. an AWS Organization with multiple accounts), an account provisioning process, federated authentication, chargeback... See https://cloudfoundation.org/maturity-model/ for an overview of these topics.

To be honest I have seen quite a few enterprise organizations that went through so much organizational pain integrating their first cloud provider that implementing a second provider is not really that exciting anymore. Now of course, if you plan on eventually leveraging multi-cloud anyway you can save yourself a lot of pain by setting things up with multi-cloud in mind from day one.

A good read on the topic is "Cloud Strategy" from Gregor Hohpe https://architectelevator.com/book/cloudstrategy/

notion.so, also has integrated support for mermaid diagrams, decent syntax highlighting etc.

Learn from my mistakes picking up terraform as a software engineer thinking "it's just a better YAML"

It's so saddening to see how the Kubernetes hype-cycle follows OpenStack and all the fundamental problems still seem unsolved. I sometimes feel like its just the same story playing out 5 years later, one layer up to the stack (IaaS -> CaaS) and with other fools to fall for it (with OpenStack it was sysadmins trying to run a control plane, with Kubernetes its devs trying to run infrastructure).

The abstractions we have available to build and run distributed systems may have improved, but they still suck in the grand scheme of things. My personal nightmare is that nothing better comes along soon.

> - Is it the networking model that is simple from the consumption standpoint but has too many moving parts for it to be implemented?

Many poor sysadmins before us have tried to implement Neutron (OpenStack Networking Service) with OvS or a bunch of half-assed vendor SDNs. Or LBaaS with HAProxy.

> - Is it the storage model, CSI and friends?

I mean, the most popular CSI for running on-premise is rook.io, which is just wrapping Ceph. Ceph is just as hard to run as ever, and a lot of that is justified by the inherent complexity of providing high performance multi-tenant storage.

> - Is it the bunch of controller loops doing their own things with nothing that gives a "wholesome" picture to identify the root cause?

Partially. One advantage the approach has is that it's conceptually simple, consistent and feels easy to compose complex behavior. The problem is that Kubernetes enforces very little structure, even basics like object ownership. The result is unbounded complexity. A lack of tooling (e.g. time travel debugging for control loops) makes debugging complex interactions next to impossible. This is also not surprising, control loops are a very hard problem and even simple systems can spiral (or oscillate) out of control very quickly. Control theory is hard. David Anderson has a pretty good treatise of the matter https://blog.dave.tf/post/new-kubernetes/

Compared to OpenStack, Kubernetes uses a conceptually much simpler model (control loops + CRDs) and does a much better job at enforcing API consistency. Kubernetes is locally simple and consistent, but globally brittle.

The downside is that it needs much more composition of control loops to do meaningful work, and that leads to exploding complexity because you have a bunch of uncoordinated actors (control loops) each acting on partial state (a subset of CRDs).

The implementation model of an OpenStack service otoh is much simpler because they use straight forward "workflows", working on a much bigger picture of global state, e.g. neutron owning the entire network layer. This makes composition less of a source for brittleness, not that OpenStack still has its fair share of that as well. Workflows are however much more brittle locally, because they cannot reconcile themselves in case things go wrong.

This. To be fair that info is very hard to discover on the website (I looked it up in the docs code that generates the website because I found that easier to parse like a database of all models).

I own an L10 and am very happily running valetudo on it. Someone should make a business out of selling them pre-flashed with valetudo for a less technical audience…

Was it so bad? My experience with it was resoundingly positive, and saw lots of productivity gains with a great developer experience for teams that could build apps with strong guard rails in place.

Now everyone and the kitchen sink „needs“ their own kubernetes cluster and operations teams struggle to build complex landing zones for the underlying cloud infrastructure so teams don’t shoot their own foot off all too easily…

Sorry, I accidentally posted the wrong URL, duh!

https://www.meshcloud.io/2022/04/14/degrees-of-correctness-w... is the deep link to the article.

> The research, which was funded in part by the National Wildlife Federation and U.S. Department of Energy

meshcloud GmbH | Various Engineering Positions | Frankfurt, Germany | Remote work within Germany, after the Onboarding World Office | Fulltime and Permanent

Our cloud foundation platform provides control and visibility that empowers an efficient and secure multi-cloud adoption for our customers such as Volkswagen or Commerzbank. To get a tiny insight about our work: We recently launched an open-source CLI tool that provides an easy overview of multi-cloud landscapes https://github.com/meshcloud/collie-cli

We are looking for: - Fullstack Engineer (Kotlin, Spring Boot, MariaDB, RavenDB) - Cloud Engineer (Kubernetes, Terraform, Dhall, Ansible) - Frontend Engineer (Angular, TypeScript, Bootstrap) - Cloud Solution Engineer (AWS, Azure, GCP)

Feel free to take a look at our website to learn more about our benefits: https://jobs.meshcloud.io Among other things, we offer World Office (mobile working all over the world), but most importantly a working atmosphere that allows you to do your job with passion.

If you are interested in hearing more please choose a free slot in the calendar of our HR-Manager Joanna https://app.harmonizely.com/jbauer our reach out via mail to [email protected]

Is this a US specific problem? In Germany companies need to maintain cap tables in a mandatory public registry (Handelsregister). You can request any company’s records against a small fee (which in fairness I consider very backwards, could be more open). There are some third party providers like NorthData making this data available publicly as well.

Trying to get one right now...

Just a shoutout that vuepress 2 (or is it called vuepress-next?) can also bundle via vite. I haven't compared it to vitepress, but its reloads from markdown are also really snappy.

> Espresso machines, then and now, are gigantic, expensive, difficult to use, and incredibly inefficient from an energy perspective.

Interestingly that's not my experience with Moka Coffe Pots. The 2-pot Bialetti I have takes a long while to heat and is almost always too small for the heat source I have available. Electric stove fields are too wide, and camping gas heaters seem to wrap the flames more around the pot than boiling it properly. After the water is steaming, you also need to sustain the heat for a bit to let the steam travel through. In total, it feels like a lot of wasted heat energy for a little bit of coffee.

I have a Flare Espresso machine (piston, manually operated) that just requires boiling water that I can get from a more efficient source like a pot matching the stove, a water boiler or even a good thermos (!) when travelling ;-) And the result I get out of that is a "proper" espresso because you can easily hit 10 bars of pressure, by applying gentle pressure on the lever.

TL;DR: Favorite stack is Notion -> notion-markdown-cms -> VuePress -> netlify

So I've gone through a bit of journey doing docs for a product company. I feel that for a product company it's really important to own your documentation and the publishing workflow as it's a key part of your product.

GitBooks was my first stab. I liked git and markdown, however I disliked all the places where "proprietary" formatting/features crept in and once it got more closed/commercial wrt. publishing/theming pipeline we went out.

We then adopted docusaurus v1 for our product documentation. It's a great tool, but never really built custom components for it because we're not a react shop. We did integrate some nice tools to work with our markdown tool (e.g. markdown-lint, custom code snippet injectors etc). One downside of docusaurus is how much friction there is to create a new page. You have to create a markdown file, insert frontmatter, add it to sidebars.json, reload the dev server, then insert your content.

When docusaurus announced v2, we considered adopting it. Instead, we started looking into VuePress vNext. What I love about it is that its configuration is TypeScript (vs. JSON). This allows us to generate things like navbars, sidebars from code instead of manually wrangling JSON. It uses Vite for bundling and the local editing experience is therefore much faster.

As you write more and more docs, markdown editing experience becomes important. VSCode + the right plugins can get you far, but we found they all did not feel "fluent" to the point where our team _loves_ writing documentation. People often complained that our company wiki (Notion) feels much nicer, so we built a tool that allows us to use Notion as a "CMS" for our documentation: https://github.com/meshcloud/notion-markdown-cms It's really handy because that way we get perks like organizing content with databases, link pages using @mention syntax, drag & drop for screenshots etc. Publishing on netlify rounds it off.

There are quite a few options for markdown + git knowledge bases, eg. Obsidian. You can easily find more alternatives discussed here on HN by starting a search on Obsidian.

If you’re looking for more of a CMS there’s quite a few options out there, most notably static site generators like docusaurus or vuepress. Plug: I’ve built a small tool to generate the markdown from notion, which allows me to use notion as my CMS editor while keeping the generated site fully under my control. https://github.com/meshcloud/notion-markdown-cms

Awesome research. I have similar quibbles about photo finish cameras in sports and written about them [0].

There are usually tons of rules in sport about the equipment, the Race course etc . but how exactly the finish needs to be set up is often vague. In this case it was an alignment issue at fault. But the next problem is the arbitrary resolution finish cameras work at. How wide is the pixel slot? This can be the difference between calling a tie or a small margin.

[0] https://www.rowinginmotion.com/thoughts-fairness-rowing/

AWS root user accounts are kind of an achillis heel in every enterprise setup using AWS. What you typically do is MFA (bare minimum) + sharded secrets. This means you need multiple people to use the root user account. You can also hook in additional audit controls eg by automating cloud watch and sending notifications about any root user login. Alternative is that you throw away the password and vow to never use it, or set up an account recovery process (all of this may not be a great idea as it can fail when you need it most).

The situation is somewhat more relaxed with GCP Billing Accounts and Azure EA Accounts, though they have better separation of concerns than AWS (billing vs. workload access). Nonetheless, never give these passwords to finance department lest they store it in an excel sheet on a SharePoint. Access to these credentials allows anyone to suspend billing for an entire enterprise... not sure what controls the providers have in place to verify any of this before initiating automated shutdown of all workloads.

I run a Ubiquiti UDM Pro as the router for my home network and slapping a few additional containers (it uses podman) on top like pi hole is doable e.g. using https://github.com/boostchicken/udm-utilities

I use it for pi hole and rclone backups.

It’s not exactly great as a home server if you want total freedom/control but it has a decent ARM SoC, a swappable 3.5“ drive bay and even though it’s got a fan I can’t hear it .

I only use it because it’s obviously running anyway and that was the least expensive way to add some things I wanted to my local network.