Gitlab Dedicated – our new single-tenant SaaS offering

https://about.gitlab.com/blog/2022/11/30/introducing-gitlab-dedicated/

by mikece • 4 years ago

222 106 4 years ago

about.gitlab.com

nimbius• 4 years ago

so no pricing and its offered by inquiry only which i can only assume means we have serious reservations regarding the salability of this 'new' product versus, say, a $24 a month vultr instance or something...

if you had 60 devs using the service thats 14k a year. you could have one of them thats on payroll maintain the gitlab container along with the rest of the CI/CD and im not sure it would really matter. Is there something im missing?

chrisseaton2• 4 years ago

offered by inquiry only which i can only assume means we have serious reservations regarding the salability of this 'new' product

Much B2B is done on price by inquiry. The three columns and 'best value!' is a very modern thing. Even in those cases you'll usually see the enterprise option is 'call us'. I wouldn't make extreme assumptions based on the pricing model.

mschuster912• 4 years ago

Much B2B is done on price by inquiry. The three columns and 'best value!' is a very modern thing.

Yeah. That is the biggest cultural difference between "suit tech" and "t-shirt tech" - the old boomer-generation suits love personal connections and dealings of any kind, while the modern generation prefers efficiency and getting their work done without pseudo-social bullshit.

pelagicAustral2• 4 years ago

Yeah, that's actually how much I pay for my instance on Vultr. Granted it's only a few users... It is a bit tricky at times to keep things up to date and secure enough, it would've been great to see a price tag for small teams or something.

I mean, I do get that at that point (<= 5 devs) these guys (nor any other company of that size) actually cares about that particular case study since one could just stick to their free tier on the main site.

lbotos4• 4 years ago

If you have any insights as to what makes it tricky to keep up to date I'm all ears. Would love to know:

Single node? Omnibus or docker based?

Making upgrades easier for all users is a core part of my plan for the next year

(I work at GL)

nixgeek• 4 years ago

Exact pricing is not listed, however if you dig around on GitLab’s site [1] it says Dedicated is for purchasers of >= 2000 seats of Ultimate, plus a management fee to cover defraying the infrastructure cost, and the time to look after it for you.

From this even with generous discounting on those seats, I’d infer this is for customers willing to spend >$50k/mo or >$500k/yr.

[1] https://about.gitlab.com/direction/saas-platforms/dedicated/...

Thaxll• 4 years ago

Comparing a SaaS solution to a cheap vps like vultr is completely missing the point.

senko• 4 years ago

Is there something im missing?

Yes. This is for big corporations who absolutely must not use shared/co-hosted/non-dedicated hardware, but don't want to maintain the thing themselves.

We had several such customers at my previous startup; one of them was a bank, another was a popular household name, neither of which so much as blinked when we quoted a price much higher than what they could get otherwise if they only shopped for the cheapest option.

toomuchtodo• 4 years ago

Cheaper than blame when there is a vendor snafu, compliance/regulatory risk and all that. It’s mostly a risk insurance premium.

tallship• 4 years ago

neither of which so much as blinked when we quoted a price much higher than what they could get otherwise

And therein lies the business model of throwing good money after bad, and that's not even taking into consideration the enormous cost benefits of self-hosting with one's own physically colocated hardware infra and a meager full time staff.

Not batting an eye, or rather, "...so much as blinked", as you said, are bourne of business models with factored in wreckless budget kruft that may at first be acceptable until one merely scratches the surface of cost savings.

Even with a full time staff, and carrier hotel fees, the reliability and overall cost savings of self-hosting would likely not even exceed 15% of what the fully managed SaaS hosting package would cost - and two more points as well...

* Response time of support staff would be under 5 minutes.

* Dedicated support staff would actually need to "dedicate" very little actual man-hours to support functions, freeing them up to have their budgeted labor resources allocated elsewhere in the company most of the time.

This is a wonderfully stark and typical example of how to sell vendor lock-in for a FOSS solution... brilliant!

bmitc2• 4 years ago

I have never understood why companies don't just publish pricing. It too often means pricing is just a game they want to play, for both personal and enterprise use, and it's a game I all too often don't want to play. If pricing is not available, I almost universally move on.

a_c3• 4 years ago

Enterprise software is more willing to milk money from corporate than to leave money on the table. The amount of money a company is will to pay can be order of magnitudes higher than an enterprise software imagined. Hence SaaS company hire bunch of sales people/sales engineer to "understand your need", which is an euphemistic way of asking how deep your pocket is. And when everyone is doing this, you can't simply move on, there are only so much options.

Of course, you could see it completely differently, private pricing means longer sales process, higher labour cost and fewer customer. Having tiered offering is common. This is actually what gitlab did, free plan, individual plans, business plan[1]. If you don't need worrying about data residency, you don't need contacting their sales at all.

[1] https://about.gitlab.com/pricing/

cbzoiav• 4 years ago

Because when you are dealing with corporates the amount of time needed can vary massively by customer. A bank or healthcare firm will come at you with endless feature requests, support requests etc. over things they claim is a regulatory requirement / they must have ASAP.

You also might offer the first bank a discount because once you have one onboard its much easier to sell your product to others. They know a competitor has already done all the due diligence and decided you're safe, so the risk they spend months evaluating you to not be able to move forward is minimal.

kube-system• 4 years ago

Enterprise pricing san be complicated enough that there may be billions of combinations and it can require an engineer to do scoping to determine which line items should be included.

Source: have been said engineer.

filmgirlcw2• 4 years ago

Because pricing is always negotiable in enterprise settings. Even if it was published, that wouldn’t necessarily be what would be charged.

I agree with you in a personal sense that it’s frustrating, but in enterprise, it often is too variable to list because if you are a big enough client, you’re going to get discounts and deals that regular folks just won’t. It’s no different than volume pricing in any other industry.

bityard• 4 years ago

I assume you don't work in the Enterprise IT space, this is absolutely 100% the norm. There is no such thing as up-front pricing, they always want you to talk to a salescritter. In some ways, this is good as the salesperson (usually) has the same level of knowledge of a system architect or engineer, or will bring one in, and you can have an open dialogue about how (or even if) their product can solve your problem. It's bad when you know exactly what you want and the salesperson's job is merely to gauge how much they think you're willing to pay and quote accordingly.

And many companies will not even talk to you except through a reseller.

water-your-self2• 4 years ago

maintain the gitlab container along with the rest of the CI/CD

Errr.. I would hope you have at least 1, preferably more, replications outside of your own stack.

hardwaresofton• 4 years ago

Well this is fascinating. There are other Gitlab hosting companies out there like GitlabHost[0] but interesting how the market will shift with Gitlab itself entering.

[0] https://gitlabhost.com

zeeZ2• 4 years ago

With the way things have been going and them showing decreasing amount of care for smaller orgs and more push towards enterprise, I'm gonna say we'll see the discontinuation of at least some of the various official self-hosted packages for nonsense marketing keyword reasons.

jnsaff2• 4 years ago

Is this going to be more performant and less flaky/down? Can money be thrown at the one dedicated tenant being more performant?

These were the big issues with at my previous client. The isolation/compliance/etc stuff had already been solved.

a_c3• 4 years ago

I can see gitlab's appeal. I wonder if there is opensource connector that let SaaS company host their application on customer's choice of cloud? Or is there similar project?

water-your-self2• 4 years ago

We heard you didnt like having all your source code scraped for our ML model so what if we silo you? Would that make you content when we eventually do our scraping again?

roblabla• 4 years ago

This is gitlab, not github. I'm not aware of gitlab doing any code scraping for ML models. Did I miss some news?

sco1• 4 years ago

I guess this is why they couldn't call it GitLab Enterprise :)

daxelrod3• 4 years ago

If I remember correctly, GitLab used to offer the same kind of service, but discontinued it because managing it was not a core competency that they wanted to focus on. I'm curious what's different now.

daxelrod3• 4 years ago

Ah yes, it was called GitHost. Here's the previous page for it https://web.archive.org/web/20190528091645/https://about.git... .

Note that the domain it used to be hosted at (GitHost dot Indian Ocean) is now a possibly-nsfw casino.

lbotos4• 4 years ago

Scale.

When I joined 6 years ago, there were 3 products with a team of about 120 people total.

A tough decision was made to focus on 2 products to increase velocity.

Probably about 2 years ago there were some asks if we offered "single-tenant cloud solutions".

At around that time, we had really rock solid reference architectures that were well tested and confirmed to be scalable.

We are now 2130 team members. There is demand, there is capacity, and there is clarity of how to run it. (6 Years ago "how big should the instance be for x users" was a question that was not answered yet.)

Feel free to ask other questions, If I can answer them I will :)

daxelrod3• 4 years ago

Thank you for that answer! Wow, I can't believe how small the team was 6 years ago. Is that 120 engineers or 120 employees total?

Looking forward to seeing GitLab doing this well. It hits a sweet spot for a lot of organizations.

sschueller2• 4 years ago

Please don't let this be the kickoff to gitlab starting to remove the self-hosted option like Atlassian/Jira decided to do. I know it's open source and a fork would happen but I would prefer not going through this crap again like I am currently having to deal with Atlassian. What happens to all the premium features we pay for right now? They aren't open source.

ccday• 4 years ago

I don’t think GitLab will do this as they would lose many government customers that self-host on private networks.

sdmike1• 4 years ago

They would lose us, that's for sure

sschueller2• 4 years ago

This sure looks like an attempt to move those into this solution.

sytse2• 4 years ago

This is not intended as a replacement for self-hosting. We plan to continue offering that.

thepill• 4 years ago

Thank god...

godman_8• 4 years ago

I don't see this as an attempt to kill off their self-hosted offering. They charge the same as their SaaS version with some slight differences in features/limits (limits being removed as they're offloaded to your infrastructure.) The self-hosted version should in theory have a better profit margin than their SaaS version. Seems like the Gitlab Dedicated offering is probably just their self-hosted version automated and hosted on Gitlab infrastructure. Appears the demand was there and it probably wasn't much extra work to make it happen so why not.

brightball• 4 years ago

Gitlab has invested pretty heavily into being able to self host virtually anywhere.

If they aren't committed to it they are certainly investing a lot of time into doing it well.

brazzledazzle2• 4 years ago

To be fair so was Atlassian. It just takes the CEO seeing the amount of money they'll make and save from pushing their customers to SaaS to change the direction for the company.

jdoss3• 4 years ago

A couple jobs ago we had to take our entire SaaS offering (security product) and reproduce it in the EU for GDPR. This exercise evolved into my Systems team being asked to create private deployments for a handful of Fortune 500 / Fortune 10 sales opportunities. The private deployment enabled Sales to land these Enterprise deals that were very risk adverse to having their data in a multi-tenant SaaS product. We ended up with around 10 of these private deployments and some very large big name customers.

We did it entirely with Ansible on AWS or GCP on accounts owned by us. This was before Terraform was 1.0 and Ansible enabled us to quickly reproduce our deployments. It wasn't sexy or pretty. It worked well enough to get the job done. The best aspect of using this model is it gives your engineering team total control over the private SaaS deployment and unlimited access. Where as On-Prem or Customer Cloud deployments are an entire other bag of cats. It is great middle ground for Enterprise customers that won't do multi-tenant SaaS.

I am only sharing this anecdote because I have seen this single-tenant SaaS model work in the past and I think more engineering teams should strive be able to reproduce their whole environments for private deployments.

wara23arish• 4 years ago

if you were to do this again today do you think terraform would be a better fit or maybe even something like pulumni?

jdoss3• 4 years ago

I would use Pulumi if I had to do it over again. I use the Pulumi Python SDK for some internal things at my work currently and it's so much better of a DX than fighting HCL all day.

We actually tried to adopt Terraform early in 2015 but we hit some of the nasty state bugs back in version .05 or .06 IIRC and we hosed one of our deployments and couldn't recover. That burned the Terraform bridge for us and we just used Ansible to automate everything.

croes• 4 years ago

Wouldn't it nowadays be a violation of the GDPR?

I mean AWS and GCP still are affected by the CloudAct, and if your company is US based they are too.

I guess your anecdote happened during Safe Harbor or Privacy Shield.

jdoss3• 4 years ago

Good question. Our EU deployment was on AWS in eu-central-1. TBH I don't know. I was told it was for GDPR and other compliance reasons and as long as it was being hosted in the EU it checked the boxes for our EU customers.

jcims• 4 years ago

What part says violation to you? Just the fact that re-homing was the only thing mentioned?

nijave• 4 years ago

I worked at a company that did this with Python and Terraform. Another great benefit is being able to rollout product changes based on customers risk tolerance. Some customers will be more interested in new features while others will prefer stability. On the engineering side, you can do canary-style rollouts to each isolated environment

Some enterprise customers will want special features or configurations that might not make sense for everyone else this setup also makes a lot easier (special network connectivity like IP allowlisting, network peering, VPN tunnels, cipher selection)

gjvc• 4 years ago

https://code.onedev.io/ is a good backup plan for when gitlab goes rogue.

dustedcodes• 4 years ago

This blog post as well as the GitLab blog doesn't load for me at the moment and times out.

I know the "HN hug of death" can happen to anyone, but with GitLab's history I can't help myself and be very judgmental now.

sytse2• 4 years ago

I checked a few minutes after your comment and right now and it loads fine for me. Maybe our DDoS protection routing people different?

sqs3• 4 years ago

Everyone assumes cloud == multi-tenant, but single-tenant cloud has a lot of benefits and is becoming more common: GitLab Dedicated is single-tenant, GitHub is prioritizing and rebuilding "GitHub AE" (their single-tenant cloud offering), and Sourcegraph (of which I am a cofounder) Cloud is single-tenant[1].

For self-hosted products, offering a single-tenant cloud product is much easier than multi-tenant because single-tenant cloud "just" requires automating and managing infrastructure, not completely changing the core application to support multi-tenancy. This also means nobody should be worried about self-hosted being deprecated in favor of a single-tenant cloud product; companies generally find it easy to keep both.

Single-tenant cloud is also a lot more appealing to large customers because the security is (arguably) fundamentally better and scalability is easier to prove (you can just point to scalability on a self-hosted instance, which has the same scaling characteristics).

Expect to see more single-tenant cloud offerings come out for dev tools, especially those that have a big self-hosted offering (like GitLab, GitHub, and Sourcegraph).

[1] https://about.sourcegraph.com/blog/enterprise-cloud

mooreds2• 4 years ago

I agree. At FusionAuth (my employer) we have a single tenant SaaS solution . I think this has legs and serves a real need.

Interesting to note that you mentioning mostly devtime solutions (version control, source navigation).

I think the proposition is even more compelling for components of your application that are used at runtime (like auth servers, databases or message queues).

Wins for the company offering the self-hosted solution:

* Easier to build the SaaS offering as you mention.

* Can leverage same code for SaaS and self-hosted versions.

* Unique value proposition: "run it yourself or let us run it, or migrate between these as needed" has been a compelling message for some of our clients

Wins from the developer perspective:

* Easier to version the tool like a library. No more surprise upgrades. Especially when you using a component that other pieces of code depend on, devs want control over the upgrade process.

* No noisy neighbor problem (at least, no more than you'd have using a VM in a public cloud).

* Still a SaaS, so you get ease of delivery/usage/maintenance.

The major cons:

* it costs more.

* deployment time can take longer (you're not just adding a row in a database and configuring a hostname).

* making sure folks know when/how to upgrade (it's still a learning experience for many devs to have a single tenant SaaS solution).

I had an interesting discussion with the Cloudility folks about the three models for multi-tenancy:

* logical (in a db)

* with k8s namespaces

* with VMs

That's here: https://cloudify.co/blog/podcast-episode-twenty-five-the-end...

bryanray• 4 years ago

Honestly, curious ... if I understand this correctly, you are deploying multiple versions of your application? So if you have 100 clients, you have 100 deployed versions of your application?

Do you have infrastructure in place to deploy all at once? All I can think about is a time back in the dark ages where I had 50 different instances of an application deployed and some clients didn't want to upgrade. Some didn't care. And some did. It was an absolute nightmare trying to keep all of the individual systems in sync?

I get the feeling that's not what you're describing here though? It sounds like a really convenient setup you guys have, but I just can't envision it very clearly.

Anyhow, thank you for sharing a bit of your infrastructure.

bberenberg• 4 years ago

I would love to hear about the tooling you're using to deploy the tenants as part of the signup flow etc.

compiskey5• 4 years ago

So a code monolith I can just dump on a Linux box is in again?

Our figurative ideas, ephemera, seem to be in a loop of taking a simple mental model, branching it into a mess, feeling over extended, circling back to a simpler mental model, branching it into an over extended mess.

Monotheism versus polytheism, and dozens of flavors of a religion rooted in a central umbrella idea.

Nation states allow creating over leveraged branches of economic Ponzi schemes.

And we’re all certain this is net new and never before seen of humans because the labels are all different!

groestl• 4 years ago

Just nitpicking, but code monolith does say nothing about the way it's deployed. Could be a massively distributed system, fwiw (we did that and were quite happy with it).

cheriot4• 4 years ago

So a code monolith I can just dump on a Linux box is in again?

Single tenant != Monolith. These things are orthogonal.

chasd00• 4 years ago

Our figurative ideas, ephemera, seem to be in a loop of taking a simple mental model, branching it into a mess, feeling over extended, circling back to a simpler mental model, branching it into an over extended mess.

It's pretty standard, the pendulum swings to one side and then eventually swings back to the other. If you stay flexible you can just ride it back and forth throughout your career.

here's an old Dilbert that shows the same

https://www.sambridger.com/wp-content/uploads/2012/01/dilber...

nzoschke• 4 years ago

Yes! We're doing this at my job for our single tenant cloud offering for a data processing and analytics product.

Monorepo, single Go binary, dump on an instance via cloud init, run it as auto scaling group with count of 1. Only dependency is S3 and database service like RDS.

Super simple for us to build, maintain and operate. Still get a reasonable economy of scale in right sizing the instance / db for the customer workload.

Easy to have a customer set the same thing up themselves for self-managed / any IaaS or on prem version.

More portable than any pre-containerized contraption, because all our enterprise clients all know how to manage instances, and only a few have container expertise, and its trivial to wrap it your container of choosing anyway.

zitterbewegung• 4 years ago

You can still put it on a Linux box this is more like you enter in a support contract with GitLab and they setup the SaaS for you and the cloud infrastructure instead of being intermingled with their other multi tenant systems.

What this is trying to solve for is companies that can’t buy their other offerings which they said are enterprise companies and or heavily regulated .

DeepYogurt• 4 years ago

So a code monolith I can just dump on a Linux box is in again?

Always has been

simplotek• 4 years ago

So a code monolith I can just dump on a Linux box is in again?

Aren't you grossly extrapolating a tad? Nothing suggests there's a "code monolith" involved in the story. Just because the topic is single-tenant instances. Also, single-box deployments are completely orthogonal to "code monolith". Finally, just because a company offers a product that does not mean there's a major architectural shift in the industry.

claytonjy• 4 years ago

How does one handle cross-customer data work in a single-tenant SaaS arch? Do you pipe a lot of "exhaust" data from those envs into a shared env for analysis, ML model development, etc.?

sqs3• 4 years ago

For products like GitLab and Sourcegraph that started self-hosted, there is not really any cross-customer data or cross-customer functionality. This is what customers expect. They want their data to be isolated and not shared.

For other products needing cross-customer features, I think you'd need to define clear APIs and pipelines for exporting some form of the data that the customer can inspect to be certain it is not violating their security/privacy expectations. I'd love to hear from people who have built such a system!

SergeAx• 4 years ago

Single tenant app is also better from data security point of view: there's no way to make a mistake that allows to access someone else's data, if it resides in a different database/object storage. On the other hand, single tenant app is more expensive to scale: memory footprint and caching layer are not shared between clients.

count• 4 years ago

Not to be terribly pedantic, but multi-tenant is literally part of the NIST definition of cloud:

"Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model..."

sqs3• 4 years ago

It’s still an accurate term under that definition. Single-tenant cloud is technically multi-tenant with respect to the underlying cloud provider (AWS/GCP/etc.), but not with respect to the software service provider (GitLab in this case).

But I believe language and communication are emergent, decentralized phenomena. Single-tenant cloud is a good and useful term.

ryanbrunner• 4 years ago

Pretty much everything on the cloud is inherently multi-tenant at some layer of abstraction, but because the underlying infrastructure is multi-tenant doesn't mean the application layer needs to be (or that the fact that it's hosted on multi-tenanted infrastructure needs to be relevant at all to it).

grepfru_it• 4 years ago

GitHub has deprioritized AE due to azure capacity and data consistency issues. Maybe AE lives on in some different format, but the Azure-based platform has taken a backseat to other enterprise features for GitHub

I wouldn’t be surprised if they pivoted back, but they lost a lot of talent on that team

mardifoufs• 4 years ago

What type of data consistency issues?

maartendraijer• 4 years ago

It's an interesting move from GitLab. About 5 years ago they offered single-tenant hosting as well, but they shut down this service. Back then we had just started single-tenant GitLab hosting (focusing on the European market) and were a good alternative, so GitLab referred their single-tenant customers to us.

Fast forward a couple of years and now they are back again. :) In the meantime we also started offering HA GitLab hosting (on AWS, GCP and Azure), so if you're interested but don't want to wait or don't have > 2000 seats, feel free to reach out: support <at> gitlabhost <dot> com or check out our website[0].

[0] https://gitlabhost.com/services/dedicated-high-availability-...

paxys2• 4 years ago

What does single-tenant SaaS even mean? All of your company's data will be in a separate AWS account? Isolated Kuberentes cluster? Individual RDS instance? And how are you ensuring that the cloud provider you rely on is also single tenant? It is a meaningless term unless the service describes exactly how they are isolating customers (And it doesn't seem like they are in this post). In my experience the term is just used by salespeople to assure paranoid CIOs and nothing else.

sa46• 4 years ago

What does single-tenant SaaS even mean?

I'll attempt to explain to clarify my own understanding.

SaaS is a delivery mechanism. Tenancy is an isolation model. To your broader point, the isolation model is implementation specific.

Multi-tenant SaaS means a single deployment for all tenants, and the data is delivered over the internet.

Single-tenant SaaS means a separate deployment for each tenant. I think common usage means a separate database per tenant. Single-tenant can also include entirely new infra for each tenant with private networking which is what Gitlab describes.

HN thread on single-tenant DB experiences with lots of useful tidbits: https://news.ycombinator.com/item?id=23305111

cheriot4• 4 years ago

The press release says customers can pick the cloud and region they want to use so I suspect the answer will be 'yes' for those questions.

A ~1000 person company I'm familiar with moved from GitHub to a self hosted GitHub because it was too easy for engineers to hit a button and accidentally publish a repository/gist to the public. That shouldn't matter, but sometimes it does. I'm not sure if that's the same on GitLab.

paxys2• 4 years ago

Sure but you can offer that with multi-tenant deployments in different regions.

sugaroverflow• 4 years ago

Hi, GitLab team member here :)

GitLab has some project visibility settings that you can utilize to control visibility and prevent users from publishing repos to the public: https://docs.gitlab.com/ee/user/public_access.html#restrict-...

Alternatively, private groups can only have private projects: https://docs.gitlab.com/ee/user/public_access.html#private-p...

Gigachad2• 4 years ago

Usually means each customer gets their own DB and instance of the app. This is a pretty good protection against a software bug from reading another customers data.

cultureulterior• 4 years ago

They already had this once before, then shut it down. Not sure why this time should be different?

JoshTriplett• 4 years ago

This looks great. I'd love to use something like this.

The biggest thing I've been hoping for for years is a federated mechanism for handling clones and pull requests. Click "fork" on a repo on gitlab.com and get a fork on your single-tenant instance. Push changes to your fork, and open a federated pull request that ends up back on the original repo.

arsome• 4 years ago

How is this single tenant? Is it running on dedicated physical hardware or just difference instances on the same cloud provider?

Gitlab Dedicated – our new single-tenant SaaS offering

Related Stories