This message was deleted.

Nice read on comparing the two tools. As an infra engineer tho

Qovery

makes my think cool another tool a random dev is going to deploy and then leave me to fix cause they dont understand whats happening goin on underneath. Crossplane is interesting but prefer more control. I have seen countless times where someone pushes terraform and they dont read the plan and delete things they arent supposed to. Neither of these products seem to stop that and could leave the developer in a worse position.

Hi @Andrew Warren - I get your point but Qovery is usually deployed by Platform Engineers - and they can manage permissions for their developers. What’s your fear exactly?

Requirements change for applications and generally are adding more services and moving things around. The problem I have with

Qovery

is if you are chasing down something where is it? (from the article) It says its agent running on k8s that then goes to its own control plane which then handles everything. Honestly it sounded to me like it was more of a product that deployed your service onto k8s than managing infrastructure using k8s. IE i want this thing go set up everything for me and it would do the needful.

Qovery is indeed built upon Kubernetes, leveraging it as a powerful orchestrator to streamline the deployment process for developers. However, our goal with Qovery is not to supplant the robust control and management capabilities that Kubernetes offers. Instead, Qovery aims to augment Kubernetes by providing an Internal Developer Platform (IDP) that simplifies complex DevOps workflows into developer-friendly operations. To be clear, the article was not intended to position Qovery as superior to Crossplane or any other tool, but to emphasize how both Qovery and Crossplane appreciate Kubernetes for its orchestration capabilities, albeit in different ways. Crossplane extends Kubernetes to manage cloud infrastructure in a declarative way, while Qovery focuses on enhancing the developer experience by automating and abstracting some of the complexities involved in deploying applications. Qovery offers the following to developers and platform engineers: 1. Streamlined Deployment: Developers can deploy applications quickly with automated CI/CD pipelines that integrate seamlessly into their existing workflows. 2. Environment Management: Qovery handles the creation, isolation, and removal of ephemeral environments efficiently, simplifying the review and testing process for new features. 3. Security and Permissions: Platform engineers can define and manage permissions for developers, ensuring they have the access they need without compromising infrastructure integrity. 4. Database Management: With open-source tools like Replibyte (also developed by Qovery), managing database seeding becomes more reliable and simpler, enhancing testing and staging processes. The concerns you’ve raised about control and accidental changes are valid. Qovery is designed to provide guardrails and visibility to minimize such risks, enabling developers to work autonomously while platform engineers retain oversight and control over the infrastructure. I believe that empowering developers to perform certain DevOps tasks themselves does not mean relinquishing control but rather optimizing collaboration between developers and platform engineers. Our aim is to strike a balance where developers can be more productive without overstepping their bounds, and infrastructure remains secure and well-managed. I hope it makes sense and clarifies the intent of the article.

management capabilities that Kubernetes offers

I would really like to talk about the merits of this.

We have the concept of lifecycle jobs (take a look of this guide or doc here) that brings the ability to manage external resources.

I get that but how does utilizing the k8s api accomplish that?

Both Qovery and Crossplane recognize Kubernetes as a powerful platform for managing diverse workloads. This shared perspective underlines a broader trend in the cloud-native ecosystem: the extension of Kubernetes beyond its original scope to encompass a wide range of infrastructure management tasks.

how is this utilizing k8s as an orchestration vs other deployment tools such as helm and argo? That is the part that I am confused on by the article. If you arent using any custom crds and actually making objects in k8s then you are simply just hosting a service perhaps on k8s.

@Andrew Warren what’s your take on netflix’s http://managed.delivery philosophy

To clear some air here my viewpoint was looking at the article and seeing how it leveraged k8s. If we are talking about keeping that same lens then I would say this would be more along with what I would expect. Users are declaring what the state should be in the system, it modifies the objects on k8s and then that information gets pushed to the operator to make it happen. From there one could simply query the k8s api to get the status of the object which should represent the status of the deployment. As to my personal opinion of the tooling I think its very interesting. It still has my gripe of the abstraction. Things like let someone else tell me what my compute resources should be, and what nodes I should run I become hesitant on. I guess this also depends on if you are running a shared environment or if each team would get their own environment. At my last employer we tried implementing resource automation via VPA and limiting it to just k8s request. This led to many complaints from our developers as they were unfamiliar with how request vs limits and would state that the VPA was causing them to run on too few of resources. We would have to explain that they have the same resources available because that has to deal with limits once they are on the box. Ultimately a majority of the teams ended up opting out of it as they preferred something static.

do you believe there is a problem to solve / what part of the problem if there is one is most critical to solve

Might be best to move to a DM or another thread as not to clutter this one but also I am not sure what you are asking. Do I see a problem with the Modern Deploy or do I see a problem with having all these layers of abstraction? Or am I just completely off target 😅 As to the Modern Deploy without actually using the tool I don't think my opinions would be valid. I have not researched it other than reading the article you posted and a youtube video on it. As an infrastructure engineer I believe I would need to learn the CRD/Operator in order to be effective. Basically ok you have this yaml that should be the overall goal but if something messes up in between I would need to be able to look at that yaml and correlate that to the actual resources and from there troubleshoot why that happened or didn't. Think like what happens if dev requested to much and the cloud provider doesn't have the resources. Does sound fun but I have learned over the years not to chase the shiny unless there is a reason to and I just haven't had that come up yet.

You should keep this on an open channel @Andrew Warren! Super interesting discussion.

Agree

(sorry @Andrew Warren - back to back meetings all day long - I’ll take the time to respond to your points probably this weekend)