I was looking at Azure documentation but I couldn't find what type of operating system does Azure for MySQL and Azure Redis Cache use. I assume that for redis it should be a must to use Ubuntu but can't find any details about underlying infrastructure. I may have missed it so if you can please refer me to it.
I want to know what are the difference between my current environment and Azure managed DBs and also what control I would lose if moving to managed instances as opposed to the many benefits that I would gain before going that way.
Related
We have been developing a RESTful web api using node and MongoDB. For hosting options, we decided to use Azure through BizSpark. We used DocumentDB with protocol support for MongoDB.
The problem now is DocumentDB is consuming all the credit causing a downtime and we haven't started making money yet. We are now considering switching from DocumentDB to MongoDB. The question now becomes, what is the cheapest way to host MongoDB on Azure?
So far on our research, we have found two options:
Using a VM (Linux or Windows)
Using a worker role
Please advice if there are other options, and how easy can it be to switch between these options at a later stage.
You can use the Azure calculator to get estimates between DocumentDB and a VM with the settings your company needs to see which one is cheaper.
If you are using Bizspark, remember that you have 5 accounts in which you can distribute all your costs to optimize in a better way.
Personal recommendations(subjective view):
Remember that if you are using the PAAS solution(DocumentDB) you
get full functionality out of the box, you don't have to set it up
and you can escale it very easily and plug in to very powerful tools
like PowerBi out of the box.
In the case of IAAS solution(vms) you have to install, mantain and
create all the connection settings for this to work. If you want to
scale you have to me more dedicated, since you have to scale it
through the use of more vms, traffic managers and more robust
architecture. If this is the path you are taking I would recommend
using containers like Docker inside the VM and their power to
manage this.
I have REST Service hosted as AzureWeb App & Another Cloud-Service WorkerRole, both need to share few common info like DB Connection string / Storage Connection string Etc.,
What is the right way to do this?
Since your question is rather broad I will try to answer in a similar way - A good practice in distributed application and micro service architectures is to have services query a single store for their configuration by so allowing your configuration to be consistent and easily changed.
In these cases you would probably want to set up some kind of database known to all services as they initialize. Depending on how complex your config data is, you can decide between several options on Azure:
Easy, quick store for simple key value pairs such as strings: consider Azure Table Storage
For more complex document like configurations (e.g. JSON): consider DocumentDB
In some rare cases where latency and throughput is a concern and you might even want to consider an in-memory store such as Azure Redis cache, though mostly for configuration data this is an overkill.
Note that all of the suggested services above are Azure managed services meaning you get availability, redundancy and robustness out of the box. This is important since the configuration store you use can be a single point of failure in your system.
We plan to migrate the existing website to Windows azure, and i have been told that we need to store files to blob storage.
My questions is:
If we want to use blob storage, that means i need to re-write the file storage function(we use file system for now), call blob service api to store files, that's very strange for me just because we want to use windows azure, how about in the future we want to use Amazon EC2 or other cloud platform, they might have there own way to store file, then may be i need to re-write the file storage function again, in my opinion , the implementation of a project should not depends on the cloud platform(or cloud server)! Can any body correct me, thanks!
I won't address the commentary about whether an app should have a dependency on a particular cloud environment (or specific ways to deal with that particular issue), as that's subjective and it's a nice debate to have somewhere else. What I will address is the actual storage in Azure, as your info is a bit out-of-date.
One reason to use blob storage directly (and possibly the reason you were told to use blob storage) is that it provides access from multiple instances of your app. Also, blob storage provides 500TB of storage per storage account, and it's triple-replicated within the deployed region (and optionally geo-replicated). With attached storage (either with local disk or blob-backed Azure Disk), the access is specific to a particular instance of your app. Shifting from file system access to blob storage access does require app modification.
If you choose not to modify your app's file I/O operations, then you can also consider the new Azure File Service, which provides SMB access to storage (backed by blob storage). Using File Service, your app would (hopefully) not need to be modified, although you might need to change your root path.
More information on Azure File Service may be found here.
Why does it seem strange? You need to store your files somewhere and the cloud is a good a place as any IF it suits your needs. The obvious advantages are redundancy and geo replication, sharing files across multiple projects and servers, The list goes on. It's difficult to advise on whether it would be a good idea or not without hearing some specifics.
You could use windows azure storage with amazon in the future if you wanted to (you'd just need to set up the access for it), obviously with slighter longer delay. Then again that slight performance drop may be significant and you may end up re-writing it.
Most importantly, swapping over from one cloud provider to another is not trivial depending on just how much you use it or how much data you've got in it, so I would strongly suggest looking at the advantages / disadvantages of each platform closely before putting your lot in with either one and then fully learn that platform.
Personally, I went for Azure cloud services + storage etc even though it was slightly more expensive at the time, because i'm a Microsoft Person (not that I didn't do my research). It was annoying in the early days when key features were missing, but it's really matured now and I like the pace that it's improving.
It's cheap to test, why not try both and see which one suits you? A small price to pay when you have big decisions to make.
Disclaimer: I don't know the current state of Amazon web services.
Nice question. We are in the middle of a migration of an old PHP/MySQL/LocalShare to WebRole/SQLAzure/AzureStorage ERP application. We faced the same problem and decision. Let me write some thoughts about the issue :
It is a good option to just be able to switch the storage provider but is it reasonable? You can always build the abstraction but do you plan how to do the actual change of storage provider - migration/sync while in production? What kind of argument will exactly drive the transition to another storage provider? How much users and data do you have? Do you plan to shard-rebalance the storage in the future? How reliable must be this system during this storage provider switch? Do you want to totally move the data when you want to switch or you just want to shard it so that you start using this different provider? Does the cost development of these (reliable) storage layers and the cost of development of reliable transitions (or bi-directional syncs) outweighs the money difference between any two storage providers?
Just switching storage mechanism from Azure Blob to Amazon will incur heavy latency penalty if your other services are on Azure - When you create Storage and Services on Azure you set affinity groups by region so that you minimize the network latency.
These are only a few of the questions to answer before doing all the weightlifting. We have abstracted the file repository (blob) because we planned to move from local NFS to Blob transparently and gradually and it answers our needs.
We have got an application running fine on On premises and plan to move it to IaaS on Ms Azure, do we need to make any changes to it or will it work as is?
I agree with the above post. You have not detailed if you are using Virtual Machines (Sql server or going to use Azure SQL). You will have to make choices about fail-over and geo redundancy, cloud services, etc. There are IP restrictions that may affect you (I don't know since I am not sure what you are moving). More than anything, I always warn people about the cost, it is difficult to understand. Here is an article series I wrote on Azure & SharePoint, you can skip the SharePoint stuff but the cost/limitation/VMs and such would still apply.
http://www.matthewjbailey.com/sharepoint-azure-guide/
We've managed a lift-and-shift of an on-premise Windows app into Azure, but I wouldn't say it's been without its pain. The above comments definitely ring true; you need to provide a bit more of an overview of what the current application does so that people can help answer your question.
In my experience, the only stumbling blocks to moving on-premise into Azure are:
Hardware requirements; i.e. if your application requires some specific hardware
Cost: It's not always cheaper to move large systems into Azure
Licensing: Make sure that your existing licensing is compatible with a cloud system which you don't control
What is established best practice in porting a Windows Service to Azure? Should it be changed into a Worker Role or moved into a VM Role? Are there other options? Assume that my services write to external persistence sources (MSMQ, databases, WCF) rather than to the file system directly.
You are far better off converting your Windows Services to Worker-Roles than VM roles. VM roles are meant to house applications that require complex un-automatable installation procedures. They are also a bigger pain to manage and you want to stay away from VM roles as much as possible. If you can find a way to automate deployment of your existing Windows Services via Worker-Roles, it is definitely the way to go.
You can also looking into HPC roles and depending on the on-prem/off-prem and load/compute requirements, adding Azure machines to your HPC cluster maybe of benefit.
All types of Roles (Web/Worker/VM/HPC) are stateless and require to be able to spin-up or tear-down from scratch on demand. All types of Roles are meant to run more than one VM instance at a time.
HTH
I wrote a blog post about this a while back. It is here:
http://blogs.msdn.com/b/golive/archive/2011/02/11/installing-a-windows-service-in-a-worker-role.aspx
Note that a Windows Service won't communicate directly with the fabric controller, so you need to ping it periodically to check health, then take remediative actions as needed.
Putting a Windows Service into a worker or web role is accepted practice. The main reason to go with VM Role is if there is significant (>10 minutes) setup required. My blog post details how to install your service.
Of course, if you want to move the code into a worker role, that's also fine. In this case you don't need any special steps to ensure the fabric controller is aware of its health.
If cost is an issue, combining functions into web/worker is also accepted practice. And you can save by not working over your code to get it into a web/worker.
Azure has a special type of Web Role called "WCF Service Web Role" which corresponds to a Windows WCF Service. This is a good point for migrating existing services.
Ideally the migration should be followed by taking advantage of Azure specific features, for instance using queues and work roles to maximise perfromance and scalability.