Posit has solved similar problems with their Package Manager as well, the benefit being that it's hosted on-prem, but the user has to build wheels for their desired architecture (if they're not on pypi).
I don't think the term "Microkernel Architecture" should be used in this context. I think "Modular Architecture," (or Plug-in like is mentioned) gets closer to this extension-based pattern.
The reason being that there's no relevance to the kernel, and modular kernels, also take this approach with replaceable plug-ins or extensions.
There is the "Yank" PEP 592 semantic that can be used to mark vulnerable packages. It's adoption has been a little slow, but I agree, having these packages available and marked accordingly makes it easier for security scanning and future detection research.
I think if revenue or product quality is tied to a VCS, having an active-active or active-passive setup is the way to go.
Fortunately, I'm on an on-prem product so that investment hasn't seemed worth it yet.
This doesn't mean we don't escrow our code, but rather than try to rebuild from source, I just take a short coffee break and wait for the impacted service to come back up :)
I would really like to see a postmortem for the recent outages. While I doubt it's all the same root cause, it would be nice for some messaging around improving resiliency.
I think the outages could be related to:
1. Github mobile just went public so they may of changed the scaling params to keep up with expected increase in traffic
2. The new notification system seems to be a lot heavier, and they could still be catching up to the changes
3. They were somewhat recently acquired by Microsoft so maybe they're migrating to Azure to reduce expenses
Whatever the cause, 11 days with outages out of 90 is pretty rough when you rely on Github for project management, a central hub for viewing CI, and all VC concerns. Feel bad for the smaller companies that wholly adopted GitOps and are blocked deploying hotfixes during these outages.
Sorry but I'd like to get you started on what is happening inside containers ;P
Specifically can you go into more details about what worries you with containers. Is it insecure images with out of date software, or risky applications inside the containers? Something else?
Do the satellites disrupt telescopes world wide? If that's the case it's pretty tough on observatories that were recently built, at (apparently) a tens of millions of dollar price tag, that are now impacted by the decision to launch without proper oversight.
Obviously having more accessible internet for the rest of the world is a positive.
I might be a little slow here, but I don't think I totally understand the use-case.
The parallel docker build / pushing to a registry is definitely cool.
Isn't the parallel Kubernetes deployment the same as `kubectl apply -f .`?
My experience has always been: GitOps w/ version controlled yaml so when a deploy is triggered all the tests run, if that's successful then a sed is performed to replace some placeholder with the new image tags then it's just `kubectl apply -f .`
> please, please slow down on chasing new markets + features and just make the stuff you already have work properly
I really agree with this. I was working at a company where we were exploring switching from Github enterprise to Gitlab for the K8s integrations, the docker registry, and the CI features.
Following the helm chart installation instructions was a nightmare because we were on-prem w/ a custom cluster. There were a lot of assumptions we had to find workarounds for (e.g. we used an f5 integration to manage our ingresses and performed SSL termination elsewhere so the nginx thing was awful).
The other terrifying bit was the number of services / pods that got brought up with the installation. If I have to monitor my team's services, I really don't want to monitor the health of: NGINX, Postgres, Redis, Minio, Registry, GitLab/sidekiq, GitLab/gitlab-shell, GitLab/gitaly, GitLab/unicorn, and GitLab/migrations.
When it comes to on-prem or self-hosted software I actually prefer running a monolithic application that worst-case I can just bounce or reboot the server.
Slow down, simplify things, and improve the user experience. Gitlab already has enough features to be competitive for a while with the Github + marketplace model.
Author seemed to have some valid points - issues that are part of the normal healing process are being diagnosed & treated via antidepressants.
The part I'm not so sure I agree with is the "system is too jammed up so don't come," sentiment.
I think if someone is having a hard time & they want to reach out to a medical professional that's probably for the best.
Unfortunately that does shift the burden onto the system to train professionals to determine the difference between prescribing antidepressants or talk and time therapy. It's a lot easier to write someone that prescription than hear them out.