Gitlab's Journey from Azure to GCP
about.gitlab.com
about.gitlab.com
> GCP offered the performance and consistency we needed. A second reason is that we believe Kubernetes is the future
Azure does a lot of cool stuff as well, not really a valid reason why you would move (other than you got a better deal).
Maybe GitLab should focus more on their product instead of growth hacking.
Their product is pretty damn good as well, IMO.
To me gitlab already provides the absolute best CICD service. It's like they need work to provide a better service than any of their direct competitors.
I've heard great things about GitLab CI, but we aren't looking to move our version control and there doesn't seem to be a way to have hosted CI from GitLab without it.
Can I ask where you're hosting your code today? We offer first-class support for external repositories stored on GitHub with GitLab CI/CD for GitHub [1]. In addition, you can do similar CI/CD integration with any git repository by URL as well [2]. We see both of these as "minimal" integrations and we're hoping to add more first-class support for external repositories this yeah - but would love to know what you'd focus on first if you were Product Manager for a day :smile:
[1] https://about.gitlab.com/solutions/github/
[2] https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/githu...
I also agree that they should share some cost analysis results.
They show that their latency has gone down, but that is not always the reason just because it correlates.
I would expect that most companies that both a) are big enough for the cloud providers to bother talking to and b) have proven they have the ability to run their workloads on multiple clouds are getting discounts from whatever cloud provider they end up using. One condition of these discounts might be that they can't publish exactly the prices they are getting, or any information that would let you infer the price.
Strange you work at Google and not know about him.
My previous manager was a Principle Engineer (Level 8). I am pretty sure no one here ever heard her name.
If that was remotely true then what product/service does Microsoft offer that is remotely comparable with Docker/Kubernetes and is neither Docker or Kubernetes?
Because you lead nothing if all you do is reuse the tools developed by the actual leaders. That's what followers do, not leaders.
Now, I happen to think Kubernetes is better, but you asked. Service Fabric was available to the public in 2016 but has been used internally since 2011.
I don't necessarily think you're wrong; I just think your argument, as stated, is weak.
I don't even do development in containers, but run services I'm not actively working on in them locally... this lets me have them nearly always on in the background and work on the piece I need to work on in the foreground. It's simply a matter of automation with a fast reset to zero.
The code that gets exercised the most is the code you can trust the most... by automating it once, you can repeat it. By automating with a container, you can isolate it. You can ensure the boundaries are proper, well defined and enough detail/documentation to repeat again and again. I do containerize the DB locally as well. I can reset and spin up the application stack I'm working on in under a minute total. Generally only resetting the db (around 18 seconds) or api (around 5) when those parts of the application are changed. I can work on the front end locally and just have the background in the background. I can tweak the background without touching shared environments. I can tear it all down and work on a different project without borking my host/local environment.
Yeah, orchestration setup and config in a cluster for hosting can be hard to learn (still learning current kubernetes myself) ... that doesn't mean that containers themselves are overkill.
It doesn't look like a good service to me at all.
When that GCLB outage happened, GKE would still be able to get traffic if you used ngnix ingress and/or regional load balancers.
If there's something we can do to help, please let me know!
Disclosure: I work at Azure on Machine Learning (but not AKS)
"This Pingdom graph shows the number of errors we saw per day, first in Azure and then in GCP. The average for the pre-migration period was 8.2 errors per day, while post-migration it’s down to just one error a day."
This was measured independently by pingdom, not by gitlab.
Hello azure?
As a result it's often really hard to tell if all the differences are down to differences in quality between the two providers vs. things done as part of the migration.
But of course this also does not mean the providers aren't different in terms of quality, just that it takes more than a graph like that to tell.
Perhaps they haven't been doing enough chaosmonkey testing?
> Putting aside valid thing that article was written by person with role at gitlab 'Content Marketer'
A lot of us in marketing have technical backgrounds and are GitLab code contributors, that's what made us competitive for the positions we were hired for. We just write a lot of the blog posts so the product teams can focus on their own work. They're also usually very collaborative.
Sorry if you meant no offense, it's just a bit of a button-press issue for me!
What I wrote (and what I stand for) is that it is good to know that this article was written by 'content marketer' - meaning person with a SPECIFIC agenda for writing that article (by definition of 'content marketing' itself).
Thats always good to know. If anybody praises something I always prefer to know if there is something (e.g. salary?) which may created/influenced/PAID such opinion. We (hackernews) derided it on many ocassions. To give different example: I personally ask all bankers if they have commission on me (for specific recommended product), or not. And I consider it healthy to know and ask.
To make it clear, I think that there is a good content marketing, and that there is a a bad content marketing. The bad for example can be seen easily with searching google for "blog 10 best sleeeping bags" and similar.
While I don't take offense to your comment, I think you made it for a reason. It's an ad hominem fallacy. These are our staff engineer's words almost to the letter, if I had posted it in his name would you have taken it at face value? I think it's important for us to ask these questions of ourselves and analyze why we form certain opinions.
That said, I do appreciate the feedback, and thank you for your comments. I'll try to keep your opinions in mind with future posts as I certainly never want to come off as having an "agenda." We're not running some BuzzGitFeedLab mill here :) .
I thought Andrew gave a wonderful presentation, and yes, we do use Pingdom as a tool to measure these things.
I would expect all that to happen typically within 1 millisecond, and perhaps up to 100 milliseconds at the 99th percentile latency when the VM machine is overloaded/overheating/otherwise unhealthy.
So what design did Microsofts engineers pick that can ever take 10 minutes to do anything?
Because overall this reads more like a sponsored post. Google probably offered a lot of money (good deal) to encourage them to move also.
The arguments for cloud look different: services offered by the cloud providers, higher flexibility, no capex (though at small scale you can rent and at Netflix scale capex is presumably not an issue) or better scaling in highly variable loads.
Netflix encoding servers probably have very variable load since releases vary depending on season (like the flood of films for Christmas).
At one point it's quite possible that a combination of the two is the cheaper option.
And yes, you're completely right, load variability plays a huge role in all this.
- maintain the physical machines
- build or rent data centers
- have people to operate, maintain, upgrade the machines
- set up, build, maintain, update, upgrade infrastructure for your projects to work on your machines
All these costs are not insignificant when you need more and more machines. And as it was mentioned above, they don't do well when demand is variable: when you no longer need as many machines, you can't just decommission them. When demand spikes, you can't install new servers instantly.
IME cloud _can_ easily be more expensive and more work than bare metal, in house or colocated. If course it depends upon the workload and the tools/resources available to manage it. Even with clouds there is still server management to do.
More work - definitely not. No matter how hard managing your AWS workflows is, bare metal will always be all that same work plus everything else related to hardware, cooling, power management, ISP and more.
Sure you have "hardware, cooling, power management, ISP and more", but that's all easy, especially compared to managing AWS workflows.
Note I'm not including their networking costs to get to the last mile, where they place a lot of their own boxes in ISP facilities pretty close to users, that would be about the same however they were doing core IT.
I've personally discounts ranging upwards of 90% for certain services and cloud vendors.
They might have a dedicated fleet for some capacity. They might also have a less predictable encoding load (e.g. not be sure how much content they will acquire), or able to make trade-offs (encoding is expensive today? let's do a fast encode and wait until spot instances are cheap with the better one).
They might also be buying for different prices/conditions than what you and I see on the web site.
On the contrary, there's probably decent product alignment with Gsuite (proven by Microsoft's acquisition of Github) & opportunity for Gitlab potentially getting acquired by Google.
GKE gives a sweet deal to encourage it because they see the long tail revenues.
It's a pretty easy decision for anyone based on k8s. I see this more a sponsored ad for kubernetes than I do for Google.
Do you have some sort of citations to back this up? Out of the 20-ish or so fortune 500s I work with directly and indirectly, not a single one has a gcp presence and every one of them uses kube somewhere in the business.
I worked at MS for a few years and during that time everything looked like Enterprise to me, which is the opposite effect :)
In another, folks were pining for the days they could migrate off of AWS for GCP and the better managed k8s clusters it would give them.
Gitlab is big enough that should they ever be killed by a Google acquisition (I don't think that's likely), a strong enough community would sprout and keep maintaining it.
I'm not challenging necessarily, I legitimately am interested in examples.
OpenSolaris -> Illumos
Hudson -> Jenkins
OpenOffice -> LibreOffice
MySQL -> MariaDB (not killed, but forked out of fear it would be)
And a non-Oracle example:
Node.js -> IO.js (arguable - forked because Node dev was stagnant, eventually merged)
I admit it's difficult to come up with examples, though I don't know of any failures either. RethinkDB has been sort of a failure, but it was never very popular to begin with.
If you told me 10 years ago I’d be way more interested in working with Microsoft than Google I wouldn’t have believed you.
Just look at Google+: it still lives on for G-Suite customers while the public version has been shut down.
I don't expect GitLab to be of much interest to Google though: A lot of their stuff competes with services Google has on GCP, Ruby/Rails doesn't fit that well into their Python/Golang/Java stack and a remote-only company wouldn't fit into their office-bound culture.
Gitlab's Series D was $100 million dollars for a valuation of $1 billion; settled several months (Sept '18 [0]) after Microsoft announced their plan to purchase Github (June '18 [1]) and in the month before the Microsoft-Github transaction was settled (Oct '18 [2]).
If the pitch deck to investors didn't mention Microsoft buying Github, I would be surprised.
Of interest, looking at their pricing page[3], Gitlab lists CI minutes as the top differentiating item for each level. I wonder if that's a signal of how the market has responded to segmentation ... or if it's as simple as "it looks better".
Disclosure: I work for Pivotal. We compete at the fringes and I expect there will be more as Gitlab expands its product boundaries.
[0] https://about.gitlab.com/2018/09/19/announcing-100m-series-d...
[1] https://www.theverge.com/2018/6/4/17422788/microsoft-github-...
[2] https://www.theverge.com/2018/10/26/17954714/microsoft-githu...
Seems like it would fit better with IBM's (now) RedHat portfolio, than it would fit with Google.
Maybe I'm just being hopeful...
On the other hand Google is in a struggle to catch up with even Azure, so Gitlab looks attractive as a foil against Github.
Another possibility would be Broadcom, as CA has a number of adjacent products for the software development lifecycle.
Though nobody's plans survive contact with money and I would still bet on such a slide having been displayed.
Let’s make a prediction: Gitlab will be bought by Google within a year.
[1] https://www.bloomberg.com/news/articles/2018-09-19/alphabet-...
Can someone please link some articles that underline why this is the case? Thanks
Here's hoping they get off Google before its meltdown.
But Google probably won't melt down. It will just very, very gradually go all to hell, like everything else.