Let me guess, Big-4? boutiques in the UK don't usually charge that kind of day-rate and the big banks all use their purchasing power to get day rates down.
£800/day is low, but not unheard of especially if you use freelancers/small boutiques, but £2k/days is more than I've seen for most things in the UK.
Very interesting article, if a bit worrying for the UK's economy in the short/medium term.
I think it could well be right that they're hoping for the (likely impossible) blink from the EU, but between that, the heavy political toll a US trade deal would require (it would have a big impact on the UK farming community+possibly other areas) and the expanding spat with China, it's really not shaping up to be a good period, economically speaking.
Indeed they are not. What I find a bit puzzling is that the UK Gov. absolutely had an easy escape hatch from the cliff edge of end of 2020, by saying "we've got to delay due to the pandemic" I don't think many people would have complained if they had.
Instead they explicitly rejected that opportunity and carried onwards...
I'd imagine it depends on how much attention the operators in this marketplace have been paying.
If they've believed UK Government rhetoric about how Brexit will be a smooth process that will enhance the UK's trading opportunities, this may come as a surprise.
There are (IMO) a reasonable number of UK citizens and businesses who haven't grasped the likely consequences of what's happening on 1/1/21
kube-ps1, kubectx and kubens can help quite a bit here. kube-ps1 to give you a visual indication of current context and the others to make switching easier.
You can also explicitly add namespaces to manifests, which help avoid applying to the wrong namespace.
Interesting looking project, although at the moment it's only useful for a small range of issues.
One of the harder parts of vulnerability scanning is building and maintaining the plugin database. Nessus, which is one of the older and better known VA tools has 10's of thousands of plugins...
There are other, open source, vulnerability scanning tools available as well like OpenVAS https://www.openvas.org/
The people who "win" at Pyramid schemes aren't (IMO OFC) winning through luck, they're winning by being the people that set them up.
And in the US and many other countries gambling is regulated, so that the games have certain parameters and the risks are known, can't see that being applied to pyramid schemes.
Ultimately the end of any pyramid scheme is a large number of people losing money , often money they can't afford to lose.
It doesn't seem likely to be in the interests of most governments to actively encourage straight Ponzi schemes as when the people at the bottom of the pyramid lose their money, they may end up requiring state assistance, transferring the risk to taxpayers.
I'd agree that k8s has a lot of functionality built-in, another important thing to realise is what k8s doesn't do.
In addition to the well-known integration points (Container Runtime/Network/Storage Interfaces), there's things like the lack of a good built-in user authentication mechanism with Kubernetes, which means you pretty much always need some external authentication service for your clusters.
That's not too bad if your on one of the big managed providers (GKE/AKS/EKS) but can get complex for people who want to deploy on-prem.
The problem with Uber et al, is not that they cannot become profitable, but that they cannot become sufficiently profitable to justify their valuations.
Uber has burned through many billions of investor cash. To show a reasonable return on that cash it would need to generate not just profit, but a lot of it.
Whether it can do that in markets like taxi's and food delivery is a quite debatable point as competitors will continue to spring up quickly especially when Uber tries to put the prices up enough to generate the kind of profts needed at their scale.
That theory implies a significant barrier to entry for new competitors.
In some markets that is justified. Those where significant infrastructure is needed to compete. For example Amazon's network of warehouses and datacentres would be hard for a competitor to replicate at scale.
For other markets, that's not justified. For example Uber, a small scale competitor can operate with some taxi's and an app. They won't have all of Uber's capabilities for sure, but they can compete in a locality.
Within the same pod sure, they share the same netns. I was talking about individual container comms.
With rootless podman they use slirp4netns and all get the same IP, with rootful podman or Docker a bridge network is established so that containers that aren't in the same pod can communicate with each other.
LXC takes quite a different approach to containerization compared to Docker (e.g. running full systems in containers by default, instead of a single application process)
What is it about their approach that you feel is superior?
Podman when not run as root has some significant drawbacks (e.g. containers can't communicate with each other). That's not specific to podman it's just hard to do without root.
Podman has long running processes as well, there's a podman process that'll run once you've launched at least one containner, and a conmon for each container (equivalent to containerd-shim)
Packaged directly... it is by RH and SUSE, don't think by debian/ubuntu. At least for ubuntu, 20.04 packages Docker 19.03 just fine.
complexity and overhead. Maintaining Kubernetes is non-trivial (IMO ofc). It has a 9 month support lifecycle, so you need to redeploy everything regularly. There are also API deprecations to deal with periodically, which if you're not keeping up with k8s developments, could be disruptive.
From a complexity perspective, you're adding more places for things to break. Instead of (say) running your apps in containers with Docker, you add pods, services and ingress as layers, which is more places for things to go wrong.
I think what type of k8s environment you use very much depends on what you're looking to get out of it.
If it's experience deploying applications into containerized environments, then micro-k8s and k3s seem like reasonable choices, you don't really care about the setup of the underlying components, just that they present the k8s API.
If you're looking for experience of managing k8s clusters, then either the distribution you're looking to run in prod. or something like kubeadm are perhaps a better option. kubeadm is very "vanilla" in terms of how it's deployed so it's quite representative of production (on-prem) deployments, perhaps unlike k3s which makes changes to how k8s works.
If you're looking to quickly test things in k8s, I'd recommend kind as the easiest way to stand up and remove clusters quickly.
And if you're looking for something to run your home services long term, I would recommend not using Kubernetes :) (unless you have a really complex home network which might justify adding k8s to the mix)
except of course where the system is ossified and you can no longer make changes for fear of affecting that lack of downtime.
In the organizations I've seen with mainframes, what happened was a panoply of supporting systems sprung up where new requirements existed as everyone was afraid of making significant changes to the mainframe environment.
In many cases (e.g. banks) these systems have been running for decades, they're often badly documented and have had a lot of fixes applied for issues that arise.
Re-writing that, is going to be a nightmare, as you've got no spec. to work from and mistakes may not show up immediately (think monthly or annual payment processes)
It's a very high risk endevour with little immediate reward for the team doing it. If it goes perfectly, no-one notices, if it goes badly it could seriously impact your whole company.
I was at a talk about mainframe security recently where the state of play with one company was, there were three users in their admins group for the mainframe, two had retired, and the third was past retirement age...
When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...
£800/day is low, but not unheard of especially if you use freelancers/small boutiques, but £2k/days is more than I've seen for most things in the UK.