Is there a tool which can transfer an Application/Code base from the Google Cloud to Azure Cloud?
Or is there a tool which can help with the process?
I tried Google but could not find anything.
I am afraid that you will not be able to find any tool helping out with code migration from Google Cloud over to Azure Cloud (or vice versa).
Google App Engine as well as Windows Azure are Platform as a Service (PaaS). Windows Azure also provides Infrastructure as a service (IaaS). Both platforms supports many different programming languages e.g. Java, PHP, Python etc. In many cases you can even use the same libraries (performing specific tasks) in both platforms. But that is pretty much is as far as similarities are concerned.
Each platform uses different architecture and different services; you need to use different SDKs. Also having in mind the fact that both platforms are dynamically evolving, it is practically not possible to a tool which allows you to transfer code base from one platform to another.
Related
How are the different FaaS or Serverless Architecture offerings of the major cloud providers effectively implemented in terms of backend and infrastructure?
AWS Lambda: Java, Node.js, C#, Python, binaries
Azure Functions: JavaScript, C#, Python, PHP, Bash, Batch, PowerShell
Google Cloud Functions: JavaScript
Google Cloud Functions seems to be based on a managed Node.js environment according to here: https://cloud.google.com/functions/docs/concepts/overview which seems to be different and a limiting factor.
AWS and Azure support a multitude of different runtimes which may look like an ideal docker use case? At least the underlying logical core concept is very close to process isolation/containerization respectively scaling of these which would lead us to Kubernetes/Mesos? It wouldn't be very efficient to invent custom solutions nowadays, wouldn't it?
Does anyone know what is at work behind the scenes?
I had a discussion with an AWS Engineer a while back and he confirmed my suspicion that AWS Lambda is run's on top of docker. Can't comment on azure or google's infrastructure though...
I've looked extensively at the Azure documentation regarding saving VM images. I understand there are two types available, Generalized and Specialized. I've read explanations of what the differences are. However, these appear to be written mostly for those very familiar with Azure concepts or IT in general. I'm more on the development side.
To my problem... I have an azure hosted image, which i've used as a build agent for teamcity. Our application isn't vanilla in that we can just install Visual Studio and be done. (i wish). We have about 20 or so third party dependent applications to install to the main OS disk, with lots of configuration required (System variables, etc.) to get it all to work.
So finally to my question - Which is the right version to use? Specialized or Generalized? I want to spawn 4 copies of this server in the same cloud service.
Any advice is greatly appreciated.
Generalized since you want them to be in the same cloud service. Generalized images start up differently as they configure themselves to take on new identities during their first start up.
What middleware (preferably non-commercial) offers the a migration path between AWS/Azure/Openstack and On-premises deployments of large applications - thus increasing agility? It is a difficult problem, but am looking for any new developments in this area. Seems like it should be an active niche given all the new cloud possibilities.
Rightscale seems to be the market leader in this. Their pricing certainly emphasizes "enterprise" and "lucrative".
In the DIY world, many libraries try to make a common layer between these. boto, for instance, can store data on S3, Google Cloud Storage, and OpenStack's Swift. Many other services are designed to be API-compatible, such as Heat (cloudformation) and Nova (EC2).
I've been bitten by the test-driven infrastructure bug. My current project is using Azure, including SQL Azure, Azure tables, cloud services, and mobile services. Configuring an entire environment is somewhat complex. Now I'm looking for a testing framework that I can use to verify that the environment is configured correctly. Something like "Confirm that there's a mobile service endpoint named foo, that is has APNS and GCM endpoints, and that there is a Google API key and Apple push certificate associated." There is more, but that is complex enough that existing tools don't seem to cover it but simple enough to describe in a single sentence.
Because of the number of products, I have to use both the PowerShell module and the cross-platform CLI to script the setup. The cross-platform CLI looks like the easiest way to get data out (it uses Node and can easily dump JSON data), but I'm at a loss as to how to even start with testing JSON dumps from a Node module that was never really intended to be used as a module.
The PowerShell module is buggy and doesn't have any ability to read mobile services information.
There is a ruby gem for managing Azure, but it's very limited. So my hope of being able to work all in Ruby was dashed. There too, I'm not sure how one would use ServerSpec to test a remote node without actually running anything on the remote node.
I'd like to stay within the realm of something that would be understandable by another Azure developer (e.g. JavaScript, PowerShell, and potentially Ruby) and not have to start from scratch with something like Erlang or Brainf**k.
Corey - big area of ongoing build out on Azure right now which is why you are finding limited support. Resource Manager is aimed at driving programmable infrastructure (http://azure.microsoft.com/en-us/documentation/articles/xplat-cli-azure-resource-manager/) but doesn't yet encapsulate all Azure service offerings.
There is also the Management Libraries (for .Net) - http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries or at the most basic of levels there is the pure REST API that you can code directly against if there are bits missing from the above (which is likely) - http://msdn.microsoft.com/en-us/library/azure/ee460799.aspx
I've been reading about azures storage system, and worker roles and web roles.
Do you HAVE to develop an application specifically for azure with this? It looks like you can remote desktop into azure and setup an application in IIS like you normally can on a windows server, right? I'm a little confused because they read like you need to develop an azure specific application.
Looking to move to the cloud, but I don't want to have to rework my application for it.
Thanks for any clarification.
Changes to the ASP.NET application are minimal (for the most part the web application will just work in Azure)
But you don't remote connect to deploy. You actually build a package (zip) with a manifest (xml) which has information about how to deploy your app, and you give it to Azure. In turn, Azure will take care of allocating servers and deploying your app.
There are several elements to think about here -
Code wise - to a large degree this is 'just' .net running on IIS and Windows, so everything is very familiar and all the past learnings, best-practices, etc. apply.
On top of that you may want to leverage some Azure specific capabilities - for example table storage, or queues, or interacting with your deployment - for which you might need to learn a few more APIs, but these aren't big, and are well thought of and kept quite simple, so there's not a bit learning curve. good architecture, of course, would look to abstract these away to prevent/reduce lock-in, but that's a design choice.
Outside the code, however, there's a bit more to think about -
You'd like to think about your deployment - because RDP-ing into a machine and making changes that way takes away many of the benefits of PaaS - namely the ability of the platform to 'self-heal' by automatically re-deploying your application should a server fail.
You would also like to think about monitoring - which would need to be done slightly differently.
Last - cloud enables different scenarios, and provides a scale-out model rather than a scale-up model, which you might want to take advantage of, but it might require doing things a little bit.
So - bottom line - yes - you could probably get an application in Azure very quickly, without really having learning much or anything, but to do things properly, and to really gain from the platform, you'd like to learn a bit more about it. good thing is - it's not much, and it all feels very familiar, just another 'framework' for .net (and Java, amongst others....)
You can just build a pretty vanilla web application with a SQL backend and get it to work on Azure with minimal Azure dependencies. This application will then be pretty portable to another server or cloud platform.
But like you have seen, there are a number of Azure specific features. But these are generally optional and you can do without them, although in building highly scalable sites they are useful.
Azure is a platform, so under normal circumstances you should not need to remote desktop in fiddle with stuff. RDP is really just for use in desperate debugging situations.