Enterprise Features, Dgraph Core Values, Open Source, and My Thoughts

My Response to Dgraph Core Values

First, I want to say that I love this document! This is a great thing to see for a project and a community. I see too many projects with great promise that don’t define the vision. This document is the vision of the Dgraph company and the way that you develop software, and all of these concepts will directly affect Dgraph and any other products you deliver. I love the points that you make here.

This is far to often sacrificed for the fact that a tool “technically works”. “Works” is not good enough! If a tool “does the job” but no user can manage to make it do the job then that doesn’t count. User experience is crucial.

Exactly! I have seen a project where new features were what took priority and the issue was that users were constantly running into “this one bug” that rendered all the bells and whistles useless. It is essential for users to actually be able to use your product, and beyond that, enjoy using your product. That attitude will create devoted users out of people that may have otherwise used your project just because they had to or because it “did the job”.

Thank you! I think that, as engineers, we often get lost in the engineering when what really matters is creating solutions to real problems. A simple solution is leaps and bounds better than a complicated solution that solves the same problem. Don’t engineer for the sake of engineering. Keeping things simple will give you more time to actually make a difference, and that is what brings user value.

Yes. Freedom to experiment and try new things helps people be creative and you never know when someone might come up with something great.

This is important. Not being clear about you think or wasting time on unproductive discussion will not be a benefit to anybody. Honesty is important to being able to efficiently collaborate and get stuff done.


Dgraph Enterprise-only Features

You guys are totally saying alot the things that me and my company have been talking about for a while now and it is really cool to see. Now I want to make an appeal to the number 1 point in your core values: Be Open Source.

Before I start I want to say that I completely respect your business model decisions. You have to maintain your business and decide how you want to do that. Still, it appears that this is a place where the community has a voice and so I want to make a case for the Open Sourcing of the current enterprise-only features, knowing that if the Dgraph Core Values are diligently upheld, I will get a fair hearing.

Hindrence to Inclusion in Other Open Source Projects

One thing that prevents me from wanting to use Dgraph is the fact that I want to include it as a part of the stack in other Open Source projects that target enterprises. The particular project in my case is an enterprise orchestration GUI. Having a database, though, that requires a commercial license to access features such as database backups and ACL would really be detrimental to that tool.

Another inhibitor is that the other tools in the ecosystem don’t require commercial licenses to access any features, so adding a new tool to the ecosystem that requires an enterprise license would not fit very well with the rest of the ecosystem which otherwise allowed for any scale deployments without commercial licenses.

Even if I were comfortable with purchasing a commercial Dgraph license for a single use-case in my own company, I would not want to force users of an Open Source application that I develop to purchase licenses, regardless of their scale.

Extra Difficulty When Selling to Legacy Enterprises

I have a colleague with lots of experience working in big, legacy enterprises, and there is a lot of red tape that you have to go through to get anything changed, especially when that change costs money. If I can take an Open Source tool, create a solution with it, and start using it without having to tell the enterprise that I need money to do it, it will be much easier to get the clearance to do so. If I can get that solution stood up and working, the enterprise can then decide that they want to pay for support for the tool because they have it deployed and running at large scale and they want to make sure it keeps working.

This is a bigger deal the more components that make up the application stack. Modern applications can require many different components and if every component needed an enterprise license that would add up drastically. Can big businesses afford it? Maybe. But it is barrier to adoption when a cost is required just to use the tool. If the business can adopt it without cost and they love it, then I believe that most will come back for support once they are using it.

Poisoning Future Development At the User’s Expense

A very relevant quote from the CockroachDB License Change Announcement:

Another option we considered was adopting a three-tier model: open source core, enterprise components, and a middle ground of features that are not open source but available at no cost. This is a popular model, and more or less the model we have had up until today.

However, this creates bad incentives for our company. It creates pressure to avoid creating new features in the core and do as much work as possible in the non-open-source components. Basically, we would be tempted to sell our core users short by permanently putting our most exciting features behind an enterprise license. If you squint towards the horizon, this model does not bode well for the open source ecosystem.

This is what I’m afraid of for Dgraph. For instance, database backups seem like a pretty core feature to me. Yes maybe the Export feature is a fine enough stand-in, but it still feels wrong to me. This is just my impression and you do not have an invalid business strategy in any respect, but I think that it has a negative impact on users.

CockroachDB went with a license that permitted full use of the database for anything except hosting the database commercially as a service. I think this is a great model. It allows you to build your business by offering your product as a service and you can still offer professional support for enterprises. Everyone has access to use and improve all of the features, but large and small businesses can get support and/or hosting to make the Dgraph business sustainable.

My Background

I am the Chief Technology Lead at Katharos Technology and at KatharosTech we build pretty much our entire company’s technology on Open Source software. We don’t have support for any of it because we are starting out and we know how to manage our software ourselves. We want to be able to use tools and deploy them highly available if necessary without having to get licenses for all of the software we use.

Even if we don’t want to pay for support now, to keep costs down in an environment where we can manage things ourselves, that doesn’t mean that we won’t one day scale to a point where having support would be worth the cost. And if we implement a tool for one of our Digital Transformation consulting clients it would be easier to tell them that they can do anything with the tool without paying for it, but that they can get enterprise support if they want to pay for it.

Closing Thoughts

If you got this far, thanks for reading! Regardless of what you guys decide on, I respect your decision. I’m extremely interested in Dgraph after looking into it just for one day, but at this point I don’t know that I would deploy it for the Open Source projects I’m working because of the license. I hope that this feedback is useful even if you guys don’t change anything. Keep up the good work! I think you’re doing an amazing job. :smiley: :tada:

4 Likes

@zicklag Thank you for verbalizing these points. And to the Dgraph team, keep up the good work whatever the decision is. You have created a good product based upon a good set of core values.

2 Likes

@dereksfoster99 might be able to answer re: Enterprise Features.

CockroachDB’s enterprise features will continue to use the Cockroach Community License (CCL). Use of enterprise features will always require a license agreement with Cockroach Labs; this license does not convert to open source after three years.

Oh, well that’s confusing, especially after their post saying what it did about not doing the “Tiered Model”. :slight_smile:

After talking to my partner about it, while I still think that it would be better to not have special enterprise features if possible, the only thing that is a hard blocker for us implementing Dgraph in our Open Source projects is ACL support.

We don’t need advanced user and access management features, but we need a way to put a password on the database access, even if there could only be one root user that had full access. As it stands, without an enterprise license, all that you need to do to get 100% control over database is to get network access to the machine and port. That is a really scary thought from a security perspective, no matter how small your deployment is.

Obviously you would want to restrict network access to the database to anything that doesn’t need it, but you don’t design security around “well that should be enough, nobody will get network access”. It is much harder to get network access and crack a database password than it is to just get network access.

Being that you can backup your cluster with the Export feature, and the rest of the features such as encryption at rest and cluster-cluster replication are more useful to massive deployments, the only real problem for us is the fact that we can’t make the database secure even on a small deployment of the database. Otherwise it is pretty reasonable.

You can combine this with TLS Client authentication. e.g using REQUIREANDVERIFY.

Network isolation, firewall, plus TLS. It should be fine.

Thinking a little further. If someone is able to overcome these barriers on your server (cloud). So nothing would stop him from accessing it in other ways (like having a password approach, would not stop anyone). Overall, if anyone can get through these barriers, he would theoretically have total control over your server even with password and such. In this case, only encryption would prevent the use of the data.

So, TLS feels like a solution for your case of “login to DB”.

But if your case, it’s not specifically about your server’s security. So you are concerned about the possible abuse of users within the DB. In this case, the recommendation is that you never expose your DB directly to users. Create a mechanism (usually an API) to get between the user and the DB. Thus controlling its use. And also add “Network isolation, firewall, plus TLS”.

If you don’t want to create an API or something similar. You can naturally use Dgraph’s GraphQL. Dgraph’s GraphQL feature has mechanisms that allow Auth and etc. Practically an API ready at the time of Schema modeling. And it’s a free open-source feature.

In the latter case, you isolate any access directly to Dgraph and expose GraphQL only. The auth system built-in does everything else you need.

Cheers.

1 Like

I am following this because it interests me as well. If I go the route of

What is the recommended way to limit access to only the /graphql endpoint and not allow access on the /admin endpoint. If they used separate ports then I could do that with port management and give my ip address access to the admin port and give public access to port 8080 (but this includes the admin endpoint)

1 Like

You can use NGINX or Traefik (reverse proxy). Both have ways to limit access to a single path. For me, Traefik is the best, but it is focused on HTTP, the gRPC and other TCP/UDP won’t work well to balance this type of protocol. For that (gRPC), you can combine Traefik with NGINX.

2 Likes

TLS looks perfect for the database. I was already planning on using GraphQL and @auth so that is looking good to.

Securing the /admin endpoint would be a little annoying because the safest thing would be to put Ningx inside the container to make sure that it is password protected from any other containers that run on the same network, but it would still work.


For instance, I have Traefik running already and routing traffic to many different containers that are all on the same “web” network as Traefik. If I used that Traefik instance to enforce the password on the /admin endpoint, it would still leave the /admin endpoint open to attack from other containers on the “web” network. So if I had a website running and that website got compromised, it will be trivial to now compromise any data in the Dgraph database through the /admin endpoint.

The way around that would be to run Nginx inside the same container as GraphQL so that the /admin endpoint would be protected at the container level and would be safe unless you ran the container in host networking mode. Then you have the same problem in host networking mode where any process on the host can access the /admin endpoint without authentication.

I think the best option would be to allow setting a password on the /admin endpoint of the GraphQL server at the app config level. That way it would be secure no matter what and there are no extra servers to run and make sure that the gaps have been filled with. I’ll open an issue on GitHub for that probably.


Still I think that will work well enough for me to use it for my project. We’ll see how that goes. Thank you everyone. :slight_smile:

2 Likes

There’s a way to secure the /admin endpoint with what we call “Poor Man’s ACL”. For some reason, I can’t seem to find the documentation for it. CC: @dmai @MichelDiz

3 Likes

The docs for securing the /admin endpoint with a token is here: https://dgraph.io/docs/deploy/#securing-alter-operations

We can add “Poor Man’s ACL” to its description in the docs so it’s searchable that way.

2 Likes

Is there something similar for the GraphQL /admin endpoint, or does that apply to the GraphQL /admin endpoint as well?

Edit: Silly me, sorry I missed it. “GraphQL is built in to the Dgraph Alpha nodes”. So that should work for me, that would be great! :tada:

Let’s do it, please. That’s how most of us refer to it.

3 Likes

If I can’t get/afford Slash GraphQL, I will walk the Poor Man’s ACL path. :joy:

2 Likes

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.