#About Dagger Cloud
scarlet lion
Thanks for this detailled answer Solomon, that's very nice !
I think that's very smart to acknowledge there will be hacks around the OSS version that will compete at some point to what you will provide with the cloud version.
To give you more insights about what I would like to achieve:
At Cycloid, we work around a concept of stacks. It's kind of a blueprint of a project that contains at least a pipeline (concourse), and often some terraform code + ansible.
The goal is to let devops teams create the stacks and give to their dev teams a way to easily instanciate environments through a form that will automatically pass all the variables to pipeline/IaC
About concourse, we're currently using the vault integration for managing credentials, and we're mostly wrapping all the calls to concourse through our backend.
We are maintaining our own UI of concourse as it's a strong added value of our product: a unified experience that bring the best of all OSS tools for DevOps/DevX.
So my thoughts when I saw Dagger project was to replace at some point our Concourse backend by running Dagger on customer's CI, and do a good UI on top of Dagger to have something well integrated.
The "conflict" I may see is that there may be no interest from our customers to use dagger cloud at some point (depending on the features it will bring). But it may help to increase popularity and ressources around Dagger...
Nothing is done yet, as I said earlier, I'm just trying to figure out the future, but want to do things in a fair way 😉
modest forge
Makes sense to me 🙂
Worst case you’re one more user of engine who doesn’t need Cloud. Still valuable to the ecosystem.
Best case you become a Dagger Cloud customer, Dagger Cloud becomes a source of customers for Cycloid and vice-versa, or both
Either one is fine with us
storm terrace
The question is also whether Dagger Cloud will target small teams or large companies, see this part https://www.youtube.com/watch?v=a-BOSpxYJ9M#t=21m43s
Some regulated industries will have a problem going onto Dagger Cloud, due to existing on on-premise hardware or private cloud, and due to compliance reasons. Also sending any data by dagger is a red flag in the eyes of security compliance teams. Allowing an established (AWS, Azure, Google) Cloud is a long process, time scale of years. Dagger Cloud will need to be ready to provide a history of SOC 2 and other reports, and for some industries there is even no established report type, and Dagger Cloud will be evaluated on a case by case basis. This is a time scale of months if not years from the initial interest in Dagger Cloud expressed by someone in such company, until the contract is signed (if this person does not leave the company, and the process stops or needs to be started over again).
Instead of forcing onto Dagger Cloud, would a legal option be an alternative? Like Docker did with their payment for docker desktop https://www.docker.com/pricing/? In addition to the license requirement some extra cloud plugins not avaiable in the open souce dagger would be available. Maybe with this approach there would be no need for Dagger Cloud?
modest forge
We've done all that at Docker. Time scale of years is not a problem.
And of course the devil is in the details. Not all enterprise customers have the same stance towards third-party cloud services, and not all cloud services are the same in that regard. It depends on what the service actually does, and the risk exposure.
Lastly, yes we may offer on-premise solutions as well. We are not cloud zealots, if the customer experience is actually better with on-prem, we are open to building that as well (probably not right away though)
These days "on prem" often means "on the customer's AWS account" 🙂
@storm terrace are you a potential enterprise customer with some of those concerns? Or just guessing what concerns we might encounter from others?
storm terrace
I know these are real concerns but won't say more. I'm watching developments of Dagger.
My suggestion of the option for replacing Dagger Cloud with a legal license obligation (e.g. you pay $amount for a dagger run if your company is of a certain size) has more elements than just facilitation of procurement of Dagger. It's about your team not needing to build and maintain a cloud. Actually I don't know what is easier: to support a tool on existing clouds for thousands of users, or build a cloud for the tool. Related to this is an element of reliability of Dagger itself: if dagger runs reliably only on Dagger Cloud, the open source users may have non optimal experience of Dagger on their own clouds. There is also an element of psychology: what if Dagger promised all feasible features to be part of the open source version? Would that attract more small scale users and build a community? I'm just re-reading your post higher up and seeing "Dagger is not and will never be a vendor-neutral platform", so maybe my thinking is not relevant. I think however that there will be a need at some point for the discussions about Dagger Cloud to appear in a public forum like github, since discord does not have a large outreach.
modest forge
All good points.
To clarify Dagger Cloud is not meant to be a hosted version of Dagger Engine. So the primary way to run the engine, whether you're an individual, a startup or an enterprise, will always be to run it on your own machines.
Additionally it's important that Dagger Cloud will always be optional. So anyone can install the engine on their machine, never connect it to Dagger Cloud, and have a great experience. Of course they will be missing the features of Dagger Cloud, but they may not need them; they may have in-house or off-the-shelf tooling that makes Dagger Cloud unnecessary; or they may have compliance requirements that Dagger Cloud doesn't (yet) fulfill.
In all those cases, we still want them to have a great experience with Dagger Engine.