monus

Crossplane https://crossplane.io might be what you’re looking for with its bunch of controllers and a nice composition API.

One of the best features is that you can bundle a CR to request a MySQL database and it will be satisfied with whatever config is in your cluster so that app only declares the need but not care how it’s done.

Disclaimer: I’m one of the maintainers of Crossplane.

I’m not associated with Countly ( https://count.ly/ ), but I heard good things from my friends using it. It’s open source and makes money with enterprise edition.

One of the maintainers of Crossplane here.

New feature of Crossplane allows you to write your own cloud resource abstraction and let the developers use it as one Custom Resource in a Kubernetes cluster and mount the credentials of that cloud resources to your pods.

CS:GO, Dota 2, TF 2 and others...

Missed the edit window.

Disclaimer: I am actively contributing to Crossplane.

Missed the edit window.

Disclaimer: I am actively contributing to Crossplane.

I think Crossplane[1] could be a candidate here. It allows cloud services to be provisioned via native CRs in your Kubernetes cluster and mount their credentials to workloads that can be scheduled to any kubernetes cluster, either provisioned through Crossplane or imported via Kubeconfig.

[1]: https://crossplane.io/

I'm wondering how native Anthos integrate with other clouds. They are standardizing on Kubernetes level, i.e. you can schedule pods from on-prem GKE to AWS cluster. But are you able to use RDS similar to how k8s config connector makes CloudSQL available via CRs? Crossplane has the advantage of being equally integrated to all clouds.

Also, if the point of multi-cloud was vendor lock-in, aren't you now GCP locked-in when you use Anthos? It's not open source and may die any time like other Google projects.

I like that it treats the infrastructure the way Kubernetes treats volumes. Claim/Class/Resource model works well for infrastructure self-service and allows fine-grained RBAC for infra resources.

However, except database resources, most of the CRDs seem to be in v1alpha stage. I'd play with it and see how it unfolds but probably not depend on v1alpha resources in production.

I have recently started https://muvaf.com to write about software culture as well as deep dives.

Right now, there are two articles. One is about exploring what keeps us, developers, excited and what kills it. The other one looks into how bugs should be handled and its relation to company culture.

The next one is about how to be nice but also apply candor during code reviews so that everyone wins. It’s on its way!

I really wanted to use kind but the fact that it loses all the data after restart/sleep of computer keeps me from using it.

I’m developing Kubernetes controllers and the Custom Resources represent the bits of cloud infrastructure ( https://crossplane.io ). So when I lose the kind cluster, I have to go and delete each and every resource in AWS :( I am unhappily forced to use minikube until support comes to kind.

I think that'll be pretty useful for a lot of companies but I'm not sure whether going with container count as limit will work.

Staging is where the software is tested as a whole before the production and in many cases it's more than a few containers. I'd not pay $500 for "Up to 5 containers/env" to set up a staging environment for my app that consists of many microservices deployed on Kubernetes. My two cents; change the pricing model. It's not only expensive but also container count is not that helpful. Number of environments is a good proxy for the value I get but I don't want to be punished just because of my number of containers; cpu + memory could be more acceptable.

I think concrete things you listed like the case for pointers is not much different than Java. While why you use a pointer changes, it's simply pointer in the end, just like Java.

I'd say Go is able to put so much meaning to those fundamentals because 1. they have to, there isn't many other mechanisms 2. they can because it's still early in the evolution of the language. After some adoption and wildly different use-cases that users wants to be addressed, those patterns start to disappear and people end up with lowest common denominators, pointers being just pointers in this case.

Usually, being easy is confused with being simple. Easy to use systems usually tend to be very complex but they'd only hide it from the average user. Once you go one step ahead, do something outside of quick start, you find yourself helpless. In that sense, the article is on point. Not only the management of the ship is simple, machinery behind the scenes is simple as well.

This applies to programming languages, too. Python is easy but when you do advanced stuff, often without realizing, you start to grok many complex details to make it work or make it work in a performant way. On the other hand, Go (and Rust supposedly, but I don't have experience) is simple. It doesn't let you do many things and that results in fewer ways of doing a specific task but when you do it, you feel safer because in the end, it does look and feel simple although you spent 1+ hour than you'd normally spend compared to coding in Python (this assumes you're doing some advanced stuff, not quick start).

OP here. I wrote about how genuine curiosity about your work helps your happiness. I think this is especially true for us software engineers where so many people got into the field by being curious. Happy to discuss.

What is the point of think tanks then? Just get paid by companies and do their propaganda but expect people to believe your thoughts are free because it's a "non-profit"?