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 have mixed feelings. Gitlab always reacts to Github stuff. It's a bit "too much" for my taste actually.
The Gitlab team seems awesome but these posts always read a bit forced-friendly. Yay we are all friends in this space and we see this and that trend and here are some benefits of gitlab over the competition in a thinly vailed "switch already" piece. I wish they'd just write "these price changes could suck for you, it's a good time to switch to us now".
I got a similar vibe from the posts in reaction to the "this is wrong with github" posts.
Well they have to be agressive but can't be inconsiderate. As a smaller company, can't wait around to see what happens, they have to move fast.
Responding to their biggest competetor is very smart. I like that they included prices and a comparison table. As opposed to say something too general like "here are our features", they know everyone will compare them GitHub, so they talk about it and compare directly.
I don't think their approach is veiled at all. It seems pretty obviousy. Saying "things like GitHub pricess suck" would be childish and irresponsible though.
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.
> Today, Twitter is excited to announce participation in the first major release of the Pants open source project: 1.0.0, an open source build tool for monorepo-style source repositories.
They (for the most part) had two repos as of 11/2014. They certainly were moving towards one. Here's a public thread mentioning the two repos: science (mostly jobs, shared code) and birdcage (mostly services). https://groups.google.com/forum/#!topic/pants-devel/60Vzkole...
Netflix is heavily based on microservices. TalkPython had a good episode with one of the higher ups at Netflix about their infrastructure if anyone is interested.
>> 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.
It's just a popular reason you might need a lot more repos than you once did. Insert your own reason, be it organizing docs, static sites, more skunk works, etc. I doubt the point of the post was to advocate microservices, so making the discussion here about it is distracting.
What's interesting is that FB and Google both use a single large repository. Not sure about Amazon. In fact, I don't know that I've ever read a detailed article about how Amazon handles things like source control internally.
They weren't really making a claim about programming practices, more trying to pump up the idea that you need a lot of repos.
I don't agree with their stance on microservices, but do find that I need a lot of private repos. In my case I just like to create a bunch of hobby projects.
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.
> 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.
Which is akward to install for the average user.
If you have an Ops team that is fine, but I doubt even at gitlab.com they don't have too many folks that automate that stuff, so either they spend time developing or they spent time automating / splitting.
Actually the biggest problem is actually RoR which Gitlab is based on, it offers a very limited performance compared against others. Even if you split, you still need more servers on ruby than you would've needed for C#, Java, C++ or whatever is closer to the metal.
Where did I mention that Gitlab should allocate a 2 CPU 4gb RAM server for every user?
The point of the comment was to show that Gitlab performs well when there are appropriate server resources, hence the reason for Gitlab.com not performing well is because it has not been scaled up/out or both.
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.