We have been using Azure Cloud Services (Web Roles) since 2013. We use it, because In-Role cache was the only available cache at that time in order for Web Farm to work in Azure.
As of today, App Service (formerly Web App/Web Sites) and Redis Cache are available, and App Service can do pretty much what Cloud Services offers.
According to this comparison, we only see 4 minor areas (IMHO) that App Service can't do –
Remote desktop access to servers
Install any custom MSI
Ability to define/execute start-up tasks
Can listen to ETW events
Question
Does it worth converting existing Cloud Service to App Service while updating In-Role cache to Redis Cache anyway?
In other words, should we even consider hosting in Azure Cloud Service (instead host in App Service)?
I think you may get opinions on this question more than facts, so here is my opinion.
I've been using Azure since the early days when it was just Cloud Services and have done my fair share of edge case implementation with them.
Today (say the past 1-2 years), I've take the approach that I start off with Web Apps and WebJobs until I find a reason not too. For the majority of my clients App Services works fine, though there are some projects that still need Cloud Services.
I find easy deployment and management of WebApps and WebJobs the huge win for me - not having to create that monster package file and redeploy the whole thing just for small changes adds up over time.
I also find WebJobs (using the SDK) are faster to be productive with than with WebRoles - though I sometimes find I need a WebApp with no UI to host the webjobs if they are processor and memory hogs. The fact that you can have your code watch a queue using the QueueTrigger just by adding a single attribute is huge time saver and cuts out all that boilerplate code.
I've used Redis on projects too (though none at the moment) and it was easy to work with - once you work out a few kinks and get used to it.
Related
There are too many options to chose from in Microsoft Azure when planning application design. Azure itself not stands still, looks like many options added recently. I'm a pretty nooby solo developer so I need some entry points to choose architecture.
The application consists of next parts:
1. Database
Classic SQL database is already implemented with Azure SQL database.
2. Server-side application. (architecture refactor needed)
For now application is a .NET C#/WPF desktop application hosted on classic Azure Virtual Machine with Windows Server onboard.
This is an always-running scheduler that performs kind of tasks one by one.
Tasks are mainly long-running works getting some data from Web, CPU-bound proccessing with recieved data, working with the DB.
It feels like its kind of ancient and wrong design (having in mind amount of azure features):
a) The application really don't need a GUI, just ability to control scheduler's status required.
b) Logically some kind of tasks can be performed simultaneously, and some of them must wait others to finish before start. Now all of tasks performed one by one, that caused by virtual machine performance limit. I think there must be a way to achieve parallel working and control results on higher level of abstaction than inside desktop app. I wanna somehow move scheduling logic to level up. (Maybe IaaS->Paas goes here?)
3. Client applications.
Client applications. Registered users work with the DB.
Here questions:
Which server-side application design should be chosen in this case, what Azure features required?
Is there an Azure built-it abilities to manage registered users accounts, or only way is to implement it as a part of application?
Did you explore other storage options or SQL database is what you need?
lets start from scratch:
STORAGE:you can choose from
1. Storage - Blob, Table, Queue, and File storage and disks for VM
2. SQL database - relational database service in the cloud based on the market leading Microsoft SQL Server engine, with mission-critical capabilities
3. Document DB - schema-free NoSQL document database service designed for modern mobile and web applications
4. StorSimple- integrated storage solution that manages storage tasks between on-premises devices and Microsoft Azure cloud storage
5. SQL data Warehouse- enterprise-class distributed database capable of processing petabyte volumes of relational and non-relational data
6. Redis Cache- High throughput, consistent low-latency data access to build fast, scalable applications
7. Azure Search- Search-as-a-service for web and mobile app development
SCHEDULAR: You can pick from
1. Virtual Machine
2. Cloud Service (worker role): you have more control over the VMs. You can install your own software on Cloud Service VMs and you can remote into them.
3. Batch: Cloud-scale job scheduling and compute management
4. Service Fabric: distributed systems platform used to build scalable, reliable, and easily-managed applications for the cloud
5. App Service: Scalable Web Apps, Mobile Apps, API Apps, and Logic Apps for any device
CLIENT: you can try out
1. Web Apps
2. Cloud Service (web role)
Use this link as one stop shop for all Azure services beautifully categorized based on functionality. From here you can pick and choose various services and amp it to your app's requirement.
MASTER LIST: http://azure.microsoft.com/en-in/documentation/
Currently working on a .NET solution for an application server. I'm using .NET 4.0 running on Windows Server 2008 R2 with IIS 7.5.
My requirements are:
The application server can run multiple Console applications at once on a schedule - Quartz.net looks like a really good solution to this problem - and is working well for me so far
The application server will also host a web application that will report on jobs (what time they ran, what they did, how long they took etc)
I would like to be able to restart the "service" that is running my jobs and trigger ad hoc jobs from the web interface.
The Service that is running my jobs needs to run all the time
Once this is live I will not have direct access to the machine to restart a Windows Service, but i could potentially setup IIS to be able to do this for me.
WCF Services looks quite promising to me - but I'm not sure where to host it. My current project uses a WCF Service to run console applications using the Quartz.net plugin. Configuration for what to run and when to run it is stored in an oracle database and my WCF service connets directly to the database to retrieve this information (not sure if that is the intended use of WCF).
If I host the WCF Service in IIS / WAS then running the console applications might be a security concern from what I've read. I can keep the WCF service running all the time using appFabric at least. Alternatively I could host it in a Windows Service and allow my web app to consume the WCF service to report on the jobs. I'm concerned about using a Windows Service though as I wont have direct maintenance access to this machine and if it breaks I'm in trouble. I would really like to be able to do the maintenance from a web application. A windows service also feel a little unnecessary given it can be hosted from IIS.
So my question is - is a WCF Service the right approach to this problem or can anyone think of a better approach?
If a WCF service is a good approach - where should I host it so that I can perform maintenance via a web interface given I will not have direct access to the machine itself?
Should the WCF service be the one to start and schedule the jobs?
I think you're overengineering it, possibly.
The Problem: You have a web site which needs to start up jobs on an ad-hoc basis. Other jobs will be run to a fixed schedule. The web site will report on all/any of these jobs.
For running the scheduled jobs, a Windows Service using Quartz is indeed an ideal solution for the fixed schedule part. However, to report on those jobs the data must be collected by the Service and made available. A service can be set up to restart on fail, so you can guarantee that it will always be running (barring a minute or two when it's restarting if it fails - and why should it?. However, any history will be lost unless the Service stores it somewhere it can be retrieve it after a restart.
The simpler solution to the web site getting the history is for the Service to write its data to a database. Then it doesn't worry about a restart: all the history has already been saved, and the data can be read by the web site at any time.
Similarly, if the web site talks directly to the Service (as a WCF Service or otherwise) then what happens if the service is not currently running? The request gets fails until the restart is completed. Frustrating for the user. Alternatively, the web site puts the request into the database. The service monitors the database for requests, and starts jobs appropriately when it sees a new request. If a request is written while the service is not running, when it restarts it will see the request(s) in the DB and execute them.
So I think using a WCF service is overkill, and actually introduces some problems: persistence of history, and what to do about requests made while the service is down. These problems don't arise if you go the way I've described.
Cheers -
In advance, sorry for stupid question, but all search results in google are off-topic for me.
I want to create a C# application, that will run continuously on an Azure VM. It should NOT be event driven, as it will use different factors (db monitoring, time schedule, overall usage) to decide its activity.
Now, should I just create a console app in VS Express 2013 for Desktop and run it using RDP on VM? Or is there some azure-specific project that I can use (maybe for better integration with management portal)? All I can see and find is web-related (a website, a webjob, a background worker, a webapi), and mine app will not in any way be accessed remotely (it will periodically check db shared with a ASP.NET website)
It is possible. You should create the equivalent of a Windows Service, but then for Azure.
There is a useful question for that already on SO: Windows Service to Azure?
It has a reference to a full walk though: Migrating a Windows service to Windows Azure.
The corresponding azure type is "Cloud Services / Worker role". They work just as windows services.
So you can basically take all classes from your windows service (except Service1.cs) and put them in the new azure project.
The copy all start/stop code from your Service1.cs to the corresponding class in your new Cloud service project.
http://www.windowsazure.com/en-us/documentation/articles/cloud-services-dotnet-multi-tier-app-storage-4-worker-role-a/
I am planning to move a game server of mine to Amazon EC2. Right now the actual server runs on .Net Framework 3.5 on a windows dedicated server. Since it is a personal side-project, it's quite expensive to have a fully dedicated server to that, therefore I would like to move it to the cloud (Amazon EC2 or maybe Windows Azure).
Have someone accomplished such thing? Is it possible to do so? If yes, could you provide me with some documentaiton on the subject since I was only been able to find doc for setting up web servers over http.
The server binds and listens to 2 TCP sockets (nodelay option) on 2 different ports.
Thanks a lot!
Kel
With EC2 you own full control of the server. That means you'll be able to deploy your app without much modification and have full control to tune the system to your needs. I'm not familiar with game servers, but if you need to tune your environment (ports, accounts, services etc.) then EC2 is probably the platform for you.
If your application is very light then you may be able to get away with using the 'Mini' EC2 instances, which only cost about 3-5 cents/hr. Cost comparisons between EC2 and Azure are a bit challenging, but my understanding is that Azure can get expensive due to their billing methodology. I've written a small cloud comparison article recently that gives an overview of the main players: http://blog.labslice.com/2010/10/choosing-your-cloud.html.
There's not much more to say. The cloud solutions can be quite confusing. Each tend to come with unique terminologies, a vast amount of services and certain peculiarities. In short, you're best off to just test both EC2 and Azure simply to get the ball rolling. Costs are pretty low and there's no lock-in for testing.
Simon # http://LabSlice.com
You should be able to do this on Azure using custom AppFabric ServiceBus binding, with TcpRelayConnectionMode = Hybrid.
There's some background on how this works here.
I know you already accepted an answer but if you are running your server 24-7 it may just be cheaper to get dedicated hosting. Doing the math it would cost 86.40 to run a small instance (I did small instead of micro because you also have to calculate in EBS pricing for the data, the micro instance has no local storage). Doing a Google search for "Cheep dedicated hosting" gave me this provider for 66.95/mo. ($37.95 for the server + $29 for using windows instead of Linux)
If you are doing testing I would recommend using EC2 to get things working smoothly but when you are ready to deploy and want the game running all the time you can save a lot of money by going with a traditional hosting provider instead of doing cloud computing.
What are the challenges in porting your existing applications to Azure?
Here are few points I'm already aware about.
1) No Support for Session Affinity (Azure is Stateless) - I'm aware that Azure load balancing doesn't support Session Affinity - hence if the existing web application should be changed if it has session affinity.
2) Interfacing with COM - Presently I think there is no support for deploying COM components to the cloud to interface with them - if my current applications need to access some legacy components.
3) Interfacing with other systems from the cloud using non-http protocols
Other than the above mentioned points, what are other significant limitations/considerations that you are aware off?
Also, how these pain points are addressed in the latest release?
our biggest challenge is the stateless nature of the cloud. though we've tried really really hard, some bits of state have crept through to the core and this is what is being addressed.
the next challenge is the support of stale data and caching as data can be offline for weeks at a time. this is hard regardless.
Be prepared for a lengthy deployment process. At this time (pre-PDC 2009), uploading a deployment package and spinning up host services sometimes has taken me more than 30 minutes (depends on time of day, size of package, # of roles, etc).
One side effect of this is that making configuration changes in web.config files is expensive because it requires the entire app package to be re-packaged and re-deployed. Utilize the Azure configuration files instead for config settings - as they do not require a host suspend/restart.
My biggest problem with Azure today is operability with other OS’es. Here I am comparing Azure to EC2/Rackspace instances (Even though Azure as PAAS offers a lot more than them e.g. load balancing, storage replication, geographical deployment etc in a single cheap package).
Even if you consider me as a BizSpark startup guy, I am not inclined to run my database on SqlAzure (Sql2005 equivalent) since I can’t accept their pricing policy, which I’ll have to bear three years after of the BizSpark program. Now they don’t have an option for MySql or any other database. This to me is ridiculous for an SME. With EC2 I can run my MySql instance on another Linux VM (obviously in the same network. Azure gives you the capability to connect to network outside theirs, but that is not really an option)
2nd. This is again is related to using *nix machines. I want all my caching to be maintained by Memcached. With asp.net 4 they have even given us out of the box memcached support through extensible output caching. The reason why I am adamant about memcached is the eco system it provides. E.g.: Today I can get memcached with persistent caching as an add-on. This will even give me the opportunity to store session data with memcached. Additionally I can run map reduce jobs on the IIS logs. This is done using cloudera images on EC2. I don’t see how I can do these with Azure.
You see, in the case of Amazon/Rackspace I can run my asp.net web app on a single instance of Windows Server 2008 and the rest on *nix machines.
I am contemplating running my non hierarchical data (web app menu items) on CouchDb. With Azure I get the Azure table. But I am not very comfortable with that ATM. With EC2 I can run it on the same MySql box(don't catch me on this one :-)).
If you are ready to forget these problems, Azure gives you an environment with a lot of grunt work abstracted. And that’s a nice thing. Scaling, loading balancing, a lot of very cheap storage, CDN, storage replication, out of the box monitoring for services through Fabric Controller etc among these. With EC2/Rackspace you’ll have to hire a sysadmin shelling $150k PA to do these things (AFAIK Amazon provides some of these feature at additional cost).
My comparisons are between azure and Amazon/Rackspace instances (and not cloud). For some this might seem like apples and orange. But azure does not provide you with instances. Just the cloud with their customized offerings…
My biggest problem is/was just signing up and creating a project. And that's how far it got over the last month.
Either I am doing something very wrong, or that site is broken most of the time.
One important challenge is the learning curve, lack of experienced developers, the time it takes to become productive .
This happens with all technologies, but with the cloud there is a fundamental change in how somethings are done.
If your application needs a database, I'm not sure that Windows Azure has a relational database (right now)
Also, there are other cloud computing providers that can offer you more options in configuring your virtual machine for example, it really depends on what you actually need and want.