Post

I worked closely with Knative for awhile in the early days. I realized this was true way back then. We’re revisiting this with WebAssembly. But honestly, it’s hard to beat what Cloudflare is doing with Workers. That’s such a scalable model.

Browser-grade sandboxing is what’s needed to run untrusted code. We run untrusted code all the time in our browser. That’s why WebAssembly is appealing. I know from experience, though, that working in standards is a difficult game when you want to move fast and be innovative. The long-game can win.

That's a good distinction in the nuances because no one has infinite time and ability and not everything needs to be specially made Working on my cars often requires special tools. It'd be nice to have them but I only need them once a year and I can get by with vice grips

Adam Bernot@bernot.dev

Building is *always* better than adapting? Nah. It's theoretically better if you are not constrained by expertise, time or resources. It makes sense to build the things that drive your business.

So, one thing I'm not hearing people talking about when pulling things back down into data centers is the cost of offloading your compliance to SaaS and PaaS vendors. When selling the cloud, we used this as a big talking point. We have all the compliance letters you need: SOC/FedRamp/ISO*.

It's a big selling point that a minority of people actually need It also turns out to be mostly a US problem. Plenty of other countries have similar requirements and held on to the control of their data

Is this to be discounted as more and more compliance frameworks are necessary for enterprise sales deals? Like ... I think it is hard to sell enterprise software products today without being PCI/SOC 2 compliant at a bare minimum.

Many SaaS/PaaS providers matured a lot. When we were evaluating a service/platform, we could just go pull this list of compliance certs, which basically shifted a good bit of the liability onto the provider.

I was more thinking up the stack. I remember looking at the cloud portions of Merki right around the time of the GDRP scramble and having to think about data custody differently. Merki technically wasn't compliant with how they were storing data.

I'm less talking about ISO2701 or SSAE18 ... blah blah blah on (The physical layer stuff ... because I agree any DC worth paying this should be table stakes)

Building is *always* better than adapting? Nah. It's theoretically better if you are not constrained by expertise, time or resources. It makes sense to build the things that drive your business.

OMG! That was a bad choice to begin with and the reason is stated in the very first lines of the article, dev environments are stateful, Kubernetes is mostly designed for stateless workloads, remember 6 years ago, people would not start a MySQL on Kubernetes. I can't believe they spent 6 years on it

It's gotten better in recent years. StatefulSets, and CSI make it easier to pin resources. We used K8s to build test / validation HDFS clusters years ago.

Well their competitor coder realized that several years ago and came up with a very similar architecture, but I think gitpods problem is they jammed things into the app hosting portion of k8s instead of using the core api/controllers/operators instead.

That is kind of what I'm doing right now. We needed a way of remotely deploying and managing containerized applications on our edge devices but Kubernetes is just "too much" for that use case. Tried it as a POC at a previous company though so that is why I know it is "too much" now 😂

Yes, I had a similar experience in my previous org. Enterprises are pushing K8s everwhere but edge require specialized solutions tailored to its unique limitations and usecases.