Update on Our Planned Move from Azure to Google Cloud Platform
about.gitlab.com
about.gitlab.com
NOTE to users in Crimea, Cuba, Iran, North Korea, Sudan, and Syria
GitLab.com may not be accessible after the migration to Google.
Google has informed us that there are legal restrictions that are
imposed for those countries. See this U.S. Department of the
Treasury link for more details. At this time, we can only
recommend that you download your code or export relevant
projects as a backup.Hypothetically something to bypass censorship might just point you to a README on a repo for installation details.
EDIT: It's one thing to accidentally be violating an embargo, it's another thing entirely to suggest ways to bypass it on your company site.
The law can be stupid, but it's rarely as stupid as the people suggesting simple hacks around it think it is.
> Restricting US companies from doing any business with Russia hurts the US economy too much.
sources:
https://www.census.gov/foreign-trade/balance/c4621.html
https://www.statista.com/statistics/218255/total-value-of-us...
If you only block doing business with Russia, then middlemen in other countries will just have to be go-betweens making a politically inflammatory action (blocking a world power) that wasn't actually effective beyond being offensive.
Blocking Crimea is a symbolic but also mostly ineffective practice done to make a statement. Making that statement about the entire country wouldn't be prudent.
If not, can/should someone post here?
21. Governing law [1]
This Agreement shall be governed by and interpreted in accordance with the laws of the Netherlands.
Is there a code hosting service in Europe or any place of the world that cubans can use?
This causes a lot of annoyances -- lots of features are not available in Chinese "AWS" regions, or they require special treatment. When I've gotten reports about slow, incomplete or stalled downloads from CloudFront it is almost always someone who's inside the Great Firewall.
I guess GCP decided not to bother with that approach for now.
If they were, AWS would not be present in any form.
Use GeoIP to serve your consumers in mainland from HK.
The truth is there could be a lot of reasons.
Another weird example: code.google.com was not available in 5 countries due to US state department controls. Github was.
Github was basically ignoring explicit guidance (this is not a statement of intentionality. I'm pretty sure when they started they didn't know and it became a pain to be compliant).
Google went and tried to get licenses (We eventually succeeded for most of them. At the same time, everyone ganged up together to try to convince state/etc to loosen up)
In the meantime, people complained that github was available but code.google.com was not, when the reason was "one was following the law" :)
https://futurism.com/google-jk-project-maven-work-military-s...
I am really interested in the real reason too.
I hope you're wrong. :|
Weird for me as I love gitlab and azure equally.
I wonder if setting up Gitlab on premises is already a (small) business.
Or, you know, an IPO. Which is precisely the exit they claim to want:
We want to IPO in 2020, specifically on Wednesday November 18.
The key is that each fund has a fixed lifetime, often something like 7-10 years. At the end of the lifetime the final value of the fund is returned to the investors.
It's hard to return cash you don't have -- and worse to return a reduction in value to investors (since you'll find it harder to raise next time). So as a practical necessity, at some point, there needs to be a big liquidity event for one or more investments made out of the fund. That could be an IPO or a purchase by another company.
Because of the highly speculative nature of VC, almost all of the companies supported out of a fund will fail. These will essentially be ignored. Some few of them will be bought at a price that covers their cost. A very few will do well enough that they are genuine prospects for a big liquidity events.
Those companies will be under the most pressure to cash out.
Gitlab has taken several rounds of funding now, some very large. These do not appear to have been made on the basis of current assets or current earnings. It seems reasonable to conclude that VCs predict a large exit and wish to ensure that Gitlab will make it to what is, for them, the finish line.
Disclaimer: I have never worked in finance and my views are cobbled together from books and blogposts.
php was pretty much a dealbreaker for google acquisition years ago. It pretty much means google might be happy to buy shares in the company as an investment, but won't buy the whole company and plan to integrate it into their own offering.
If you design for the strengths of, say, Amazon Lambda, you can't use Google Cloud Functions / Azure Functions directly. Most likely you'll just run it on top of self-managed VMs on the other clouds, making Amazon the "clear" winner. If you design for GKE, you'll find that Amazon and Azure's Kubernetes support isn't as good, but maybe there was a better design for your site that wasn't based around GKE. And so forth.
And if what you actually want is a fixed amount of compute capacity and block storage and you'll just manage OSes yourself (either because that's actually better for your needs, or because you're operating something that predates containers/serverless/object storage/etc. and the development work to get it there is expensive), just get some dedicated servers in colo, it'll be cheaper than any cloud for that model.
The fact that you basically had to provide a ELI5 here on HN for this, shows what a dismal job we, as an industry, have done to educate the larger world as to the best-practice of cloud selection should be.
We, on HN, for the most part, can spout off this tribal-domain knowledge because we live it most days.
But what would be great is to have these types of nuggest of information, empiracally delineated, available without effort to those who would like to know.
Specifically, in a way format/method where you don't need to have the lexicon to be able to formulate the proper question.
Most people, even those IT people who may work for a tiny office who has very little need for anything "at scale" may not be able to ask the questions.
An analogy could be (?): "everyone knows if they need a bike, motorcycle, car, truck or bus - and everyone should be able to assess their basic computing needs as well. It should be fairly clear if you need a single machine in an office, a colo or a cloud - and figuring out a path to doing so and selecting a vendor should be a straightforward task."
If you need apps to be hosted, something like Flynn can host the apps.
If you need Lambda, you can rack your functions natively into OpenFaaS.
The issue is that these systems aren't really 'multi-cloud capable'.
I really tried to put together a 6 node Flynn cluster with 2 in AWS, 2 in GCP and 2 in Azure but the response time in cross-talk was terrible!
The DIY approach is fantastic when you're interested in operating your own cluster on your own hardware, though - if you're mostly in a place where colo / datacenters makes sense to you, and you need a bit of something like Lambda, don't do a cloud migration just to get there.
Kinda like how back in the day you could use Java and AWT just provided either the lowest common denominator widgets, or rendered the widgets itself to be equally unsatisfactory everywhere. Those who forget history...
http://uk.businessinsider.com/gitlab-raises-20-million-from-...
Generally, companies are not bought for culture. Folks say a lot about their most valuable resource being their people, but typically a purchaser wants to buy assets. In software that will be less about cash or inventory or plants and more about customer contracts, partnerships, brands, trademarks, patents, copyrights, existing sales organisations and so on.
> GitLab isn't a major money maker ... If Google wanted them they would have already bought.
They might buy simply to have a hedge against Github. Gitlab comes with a lot of independent brand awareness that Google has not, so far, been able to gain against Github in this area.
The cloud providers are involved in a no-prisoners effort to lock in customers while the market emerges for the first time. This is golden age of rail stuff, there are massive path dependencies that will be very difficult to unwind.
Each will grow aggressively on every edge of their current surfaces, whether by implementation, partnership or purchase. Or all three, in varying orders, as they think works best. They will rapidly copy each other to try and prevent competitors gaining an unassailable lead in some segment.
Disclosure: I work for Pivotal. We have partnerships with Google and Microsoft.
Completely irrelevant; Google does not version-control their projects substantially with Git. They used Perforce for a long time and now I understand they use some internal, proprietary VCS.
My experience with AKS is mostly with the Azure REST API (building security and compliance tools around AKS). Unfortunately AKS isn't within scope of MSFTs BAA yet, so my focus has mostly been on other services like Cosmos and App Service.
As a matter of fact they should in fact avoid any kind of cloud vendor lock-in and spread the deployment across the big 3
So I suppose once those ran out it was a good idea to choose the best provider from first principles, rather than letting the inertia marketing succeed.