Can anyone with experience chime in and describe for the curious how such a migration would be achieved?
From the department of "yeah, right" comes news that GitLab is shifting its platform from Azure to Google in order to take advantage of the ad giant's Kubernetes technology. It is, of course, absolutely nothing to do with cosying up to developers still anguished following Microsoft's purchase of GitHub. Nope, absolutely not. …
Yes im sure. Roughly twice as many enterprise CIOs are planning to move to Azure as AWS. As per stats quoted on an article here.
You still need to multiply it by the CIO's fatness to have correct dimensionality in the comparions.
How many of those CIOs are from companies already married to Microsoft and too small or weak in IT to implement a "let go" program?
Azure, like anything else from the House Of Microsofts, reeks of overcomplexification, historical baggage and several committees working on it where the members don't talk to each other.
I remember how hard it used to be to even manage a credit card in Azure (or even to log in, you would be siphoned through various servers owned by Microsoft for no good reason). Three years earlier, paying in AWS (not to mention logging in) was a snap.
This post has been deleted by its author
1) git clone firstname.lastname@example.org:capita/anotherproject.git
2) cd anotherproject.git
3) git remote add upstream https://USER@bitbucket.org/USER/PROJECT.git
I mention BB since we are now transitioning everything away from both GitLab and (self hosted) Github. Not at all surprised to hear GitLab was hosted on Azure after the complete fiasco last year.
> 3 steps
Yeah, no. Sure, that can work for a small organization, but you don't want to try that for more than a few hundred repos. The bandwidth costs alone will absolutely kill you.
This is a bulk data move, and the fine folks at Google are super-motivated to make this go down well. In fact, the folks are Azure are also well motivated, because if they get blamed for a mess, then they will be charged with vendor lock-in, not to mention the general concern in the industry involving u$ and quality.
1) Gitlab gets its servers up and running in Google. Checks indicate that they function properly.
2) Google provides Azure with physical media to transfer the data.
3) Azure safety scans the physical media provided by Google, and creates backups.
4) The backup physical media is transfered to the Google datacenters.
5) The Google safety scans the physical media, and plugs it in.
6) If you are quick, Gitlab sets upstream branches on the Google repos to point to Azure, and updates them periodicaly. If you are not quick, it might be cheaper to do a second physical transfer with a delta.
7) MAGIC: Gitlab has its Azure servers redirect to the Google servers as the repos come up to date.
8) Gitlab updates its DNS records to point to the Google servers.
9) Gitlab shuts down the Azure servers.
10) Azure securely overwrites or destroys the SANs with private repos. The public ones might be turned into mirrors, or just overwritten.
At least, that's my first guess. :P
Kubernetes makes migration of the servers very easy, along with allocating IP addresses - all containers are neatly packaged up. Migrating data is another matter, along with switching DNS records.
Remember getting downvoted for explaining the pitfalls of Kubernetes on Azure in the past https://forums.theregister.co.uk/forum/1/2017/07/27/microsoft_previews_azure_container_instances/ would suggest others experience it first hand before assuming Kubernetes on Azure is rosey.
This post has been deleted by its author
@AC "Remember getting downvoted for explaining the pitfalls of Kubernetes on Azure in the past"
ACS and AKS are different services so it's not surprising you'd get downvoted for talking about Kubernetes on a thread about container services. I didn't bother going and looking at your comment as the one I'm replying to suggests you don't put much thought into the content...
"Remember getting downvoted for explaining the pitfalls of Kubernetes on Azure in the past "
Azure is good at a lot of things, but V1 products is often not one of them. I'm sure you have valid points. And if you just need Kubernates then Google is probably a no brainer right now. Especially as they seem to be discounting to insane levels to get business.
Microsoft's greatest successes often seem to be in ripping off the ideas of others and doing it better. They have already gone all in on Docker with Windows Server supporting it natively. So I bet it's not long before Azure's Kubernates products beat Google for usability, integration and functionality. I can see Microsoft integrating it with say Intune to give an alternative to Helm and similar products. OSS products are generally developed from a command line perspective and that's often a higher learning curve barrier to entry than a product that's developed from a GUI. And Microsoft's GUIs generally run on top of Powershell these days so you get the best of both worlds.
"Microsoft's greatest successes often seem to be in ripping off the ideas of others and doing it better."
Ripping off, yes. Doing better, not really. They just tend to wrap them into their existing ecosystem to the point that lazy admins simply deploy over alternative products because of perceived familiarity with the brand and because it's one less vendor to negotiate contracts with.
"And Microsoft's GUIs generally run on top of Powershell these days so you get the best of both worlds."
The performance of a lot of the newer Microsoft admin tools reflects this, unfortunately.
GitLab is not GitHub.
Pro-MS folks are often confused, evidently.
This is a major undertaking not to be done at the drop of a hat. Also, you think MS would move their platform away from their own servers just to win points from anti-MS people? I bet most people never even knew GH was using MS servers (I didn't)"
"Can I put money on, they keep the existing infrastructure, and change the name of it to make it part of the Azure family."
GitHub use a blend of Kubernates and dedicated boxes at Rackspace as I understand it, so I doubt it would stay there long term. I would put money on it moving to a Microsoft facility at some point.