The future of SaaS hosted Git repository pricing

Good timing. This is what good marketing and agility looks like.

I've been impressed by GitLab. They moved very fast and made good progress recently. It is great to see competition, to what many (at least in start up land) considered a done deal in terms of a winner as far as hosted code is concerned. Remember someone was telling me "if your code is not on GitHub, it doesn't exist".

But then remember getting a sticker shock when we got a quote for GitHub Enterprise a few years back. Ended up picking Atlassian instead, besides the price it was the better ticket workflow, or maybe it was the wiki, I forgot. Anyway, I would have liked to have more choices at that point to look at. Now GitLab is a choice as well.

I really have to tip my hat to GitLab marketing the past few months as they've done a phenomenal job. I do wonder what will happen to their pricing once they raise additional rounds of financing? What happens to their pricing once their investors want to see a return on investment? I like the carpe diem business strategy, and of course I like free, but I'm a bit skeptical at the long term viability of a business and market that seems to be racing to the bottom.

>With such tangible business benefits, it is no wonder why Google, Amazon, and Facebook have been using microservice development practices for over a decade.

At one point Google and FB were trunk based monolithic repositories, and I haven't heard that has changed. If it has not, this might not be the best example for micro services leading to many repos.

I see this as an upcoming trend in all SaaS. Across the industry, the cost of resources is headed towards zero.

Blame it on Amazon and Google who are making online compute, memory and storage ridiculously inexpensive if you know how to use it right.

So SaaS companies should and will have to price on a different dimension.

I think:

Charge to cover the resource prices. But if your resources are small amounts of storage for code, round down to zero.

Charge per user. It's simple and predictable and a good proxy for budget.

Tier around features.

Sell a totally private on-prem version. Companies will pay big bucks if they need your product features and compliance.

So yeah, basically exactly what GitLab is doing. They really are doing a great job at trying to build an open source business.

>> The rise of microservices, an approach to development in which you structure your software into smaller individual service-oriented units. Each microservice then runs its own process and they communicate with each other through APIs. This software development approach is known to have four primary benefits: agility, efficiency, resiliency, and revenue

Off-topic, but what?! I understand there is a lot of hype about "microservices" right now but I don't think the upsides of the propagated approach are as clear-cut or uncontroversial as the post makes them out to be.

The article defines "microservices" as the act of splitting up an application into many small, individual programms that talk to each other via RPCs.

How does structuring my code into lots of small programs improve revenue of all things? Or are you talking about the revenue of code repository hosting providers and "microservices" consultants?

Also, this approach surely does not improve resiliency and efficiency per se. It actually does the opposite in my opinion. All the additional RPCs are only adding _more_ points of failure (unreliable IPC) and overhead as compared to straight in-process method calls.

And who's saying that "a microservices architecture" improves a dev teams "agility"? How does one even measure agility? The article is stating this like it's an established fact. In my [anecdotal] experience, spreading an application out over lots of individual repositories and binaries makes it harder to work with, not easier.

>> With such tangible business benefits, it is no wonder why Google, Amazon, and Facebook have been using microservice development practices for over a decade.

The fact is that these are a massive software companies with thousands of engineers. Naturally they run an incredible amount of internal software and services. I think this is often conflated with the idea that splitting up a given application into smaller and smaller parts to produce more individual "services" automatically makes it better somehow.

Don't get me wrong. I'm all for having a clear seperation of concerns and well defined interfaces between individual modules. Doing that has been best practice since I started to code. But the latest "let's split our codebase up into 20 different binaries and repos, because microservices" fad is just bonkers.

I'd like to see a migration guide for bringing a small organization (company) from GitHub to GitLab. Not the Git part, but rather how to map organizations and organize repositories.

GitHub's new pricing seems incompatible with smaller studios and agencies who encourage collaboration from non-developers or which frequently hire outside contractors. Make it easier to understand how those migrations might work.

A small factual error - the article states N/A for unlimited users at bitbucket but according to their pricing page[1] unlimited users is $200/user/month.

[1] https://bitbucket.org/product/pricing.

> That is why it is not surprising that GitHub has announced free private repositories

I think this might be an error.

> Due to the rapid growth, GitLab.com's performance slowed down.

Not sure why Gitlab is still not able to scale the platform.

I run Gitlab on a 2 CPU 4GB RAM VM and it performs very well(even with fairly large repos). There is also the known issue with Gitlab CE itself being resource intensive, but in the case of the version hosted on Gitlab it seems to be a scaling issue.