I'm currently building a site that will be hosted in Microsoft Azure. The last site I created in this hosting environment used "Windows Azure Shared Caching". Some of you may already be aware that "Windows Azure Shared Caching" service will soon be deprecated over the next year.
I have applied for the preview release of "Windows Azure Cache". However, I'm finding that my request is still "queued".
I wouldn't mind using "Windows Azure Shared Caching" since the site I'm building will only be live for around 10 weeks and the fact it being deprecated next year doesn't worry me. However, I am unable to create a new caching service through the old Azure Management Portal since new caching has to be done using "Windows Azure Cache".
So my question...
Since my application for the new caching platform is still yet to be approved and I am unable to create a new caching service under the old platform, what other options are there? Have I missed something?
Microsoft is surely making things difficult.
The other option you have is using In-Role Cache for Web/Worker roles (Azure Cloud Services). Any role within the same cloud deployment can access the cache. If you have just 1 web role - this acts very similar to ASP.NET State Server which provides an in-memory cache. However, as you add more web roles - you can choose to distribute this in-memory cache across all roles or use a dedicate worker role for managing the cache.
Dedicated In-Role Cache: worker role uses all available memory
Co-Located In-Role Cache: percentage of available memory is used across all roles
See In-Role Cache FAQ on MSDN for more details.
Your request should have been approved (irrespective of whether yours is a paid/trial/free subscription). If it still hasn't, put the query up here. This is the forum for Cache.
This is a proper release of the Cache Service! The core is very mature and Microsoft is giving great support on top of it. Go ahead and use it!
This flavor of Cache is THE right one for Azure Websites.
Leave a post at the forum for any concerns/issues you have. It is being constantly monitored and replied to.
I guess I am the first to suggest Azure Redis Caching?
Related
In the old silverlight portal, azure cache was under the service bus category along with ACS. In the new HTML5 portal, I can't find my cache anywhere. Under ServiceBus, it says I have zero, and only shows a link to create a new service bus namespace. Should I contact support?
You have to use the previous portal for managing the Azure Cache. Since the new portal is still in beta - not all features have been ported yet. MSDN still links to the previous portal for provisioning the Azure Cache.
Update by question asker: As seen in the comments, it looks like my browser may have been hanging onto a DNS redirect from windows.azure.com to manage.windowsazure.com. I was able to successfully get back to the silverlight portal using both the provisioning the Azure Cache link and by using #BrentDaCodeMonkey's suggestion.
I have a project and I'm planning to start the web app as an Azure Web Site and then migrate it to an Azure Cloud Service (also called Hosted Service) if it is needed as a scale strategy.
The decision is because I read that Azure Web Sites are more simple and fast to develop with almost no Azure-specific configurations or code. So starting fast and simple is a good starting point for the project.
But, is that a good starting point for you?
Is migrating an Azure Web Site to an Azure Cloud Service the same as you were migrating a normal ASP.NET Website to an Azure Cloud Service?
Would you start with an Azure Cloud Service right from the beginning? If yes, why?
Thanks for your time.
There are benefits to both deployment models, it will eventually come down to what you are trying to achieve and ultimately the success of your application.
Below I've outlined the Pros and Cons of each of the models to ensure that you're making the right choice for your applications goals.
Windows Azure Web Sites
You have properly identified that Windows Azure Web Sites is a great starting point for an application, however you could also consider that Web Sites does offer enough scalability for many solutions.
Pros
10 Free sites during preview [Free for 12 months]
Easy Deployment (use Git, TFS, Web Deploy or FTP)
Quick Scalability (You can move to your own dedicated cluster [aka reserved standard])
Simple Development (Supports Classic ASP, ASP.NET, Node.js, Python & PHP)
Persistent Environment (most people are used to this)
Cons
No SSL Support on Custom Domains
in Preview (currently no SLA)
Windows Azure Cloud Services
Cloud Services (formerly known as Hosted Services) is definitely the vision for the future of Web Applications. It is built with resiliency in mind to keep the cost of applications affordable by scaling to meet demand, and dial back capacity when your traffic slows.
Pros
Increased control over the cost of your application (if architected correctly)
Flexibility (You have full control over the environment)
SSL Support
Language Agnostic
Web Server Agnostic (although IIS is available by default)
Auto Management of Servers
Cons
Architecture should be carefully considered
Deployment time is slower (Slows development cycle)
Things to consider for Portability
The items above might have given you enough to plan the immediate future of the application and it is very likely that you might want to consider Cloud Services in the future (it fits a number of application scenarios better in the long run).
Here is a list of things to help portability between Web Sites to Cloud Services:
Start thinking Stateless
Windows Azure Web Sites is nice as it is a persistent environment, which means you are able to store things like session state and assets to the disk.
Although this is a good feature, it's best to start planning towards a stateless application, if your end goal is to be in Cloud Services. Here are a few things you can do to start thinking stateless:
Don't rely on Session State
If you need it, come up with a strategy to make it scale (Caching Service, SQL, or Storage)
Use the Storage Service
Assets such as Static HTML, css, javascript and images are better placed in Storage
Avoids additional bandwidth on your Web Site (potentially stay shared longer for lower cost)
Can be CDN Enabled, provides a better experience for International markets
Easier to update web assets when application is migrated to Cloud Services
Storing User content
If your application already stores to the Storage Service, there is one less code modification in the future when moving to cloud services.
Make it easy to discover patterns in your Data
The benefit of Cloud Services is it enables you to reduce cost by only scaling what needs scaled. Starting the process of identifying your scale units i.e. How you partition your database or Tables in Storage.
I read all post and all of them are very helpful.
In addition to all post , I found an info on msdn : Windows Azure Websites, Cloud Services, and VMs: When to use which?
With Windows Azure Websites you can:
Build highly scalable web sites on Windows Azure.
Quickly and easily deploy sites to a highly scalable cloud environment that allows you to start small and scale as needed.
Use the languages and open source applications of your choice then deploy with FTP, Git or TFS, and easily integrate Windows Azure services like SQL Database, Caching, CDN and Storage.
With Cloud Services you can:
Build or extend your enterprise applications on Windows Azure.
Create highly-available, scalable applications and services using a rich PaaS environment. Support advanced multi-tier scenarios, automated deployments and elastic scale. Deliver great SaaS solutions to customers anywhere around the world.
And also there is summarizes the option on msdn :
And comparing some features Web Sites and Cloud Services on msdn:
Azure is a great place to have your app, but there are some considerations you need to know before start migrating it.
Azure Websites and Hosted Services are really trivial to deploy. With
Visual studio you generate the package and simply upload it. Then you
have a Development environment to check it. If it's ok for you, swap
ips. If it's not ok for you, upgrade again.
Your instances have some properties that could be annoying. For
example, you cannot be sure about your IP. Then if your app works
with some provider using IP restriction, you will need to figure out
how to proceed.
More considerations. Your "server" could be reimaged at any moment.
If you store something on the local disc, that file could go away at any moment.
Azure works very nice if you have at least 2 instances or more for
each website. Maybe your app is not prepared for that. The first step
will be managing the sessions with the appFabric. Is really
easy, just a change on your web config. Be careful because this
session state doesn't work exactly as the "old one". You cannot store
non-serializable objects (should be easy to adapt) or a very large objects (more than 8MB).
If you are going to develop something from zero, I suggest you to start into azure from the beginning. The reason is simple: it's really cheap to start and you will not pay serious money until the app have lot's of visits. It's also very cheap to setup a SQLAzure and a storage account. One you have all in place, it's easy to add more instances or scale up.
Example:
Imagine you have an idea and you wish to show up to some possible investors.
You start setting up a little SQLAzure database (1GB ), $9,99 monthly.
Then you build a site and you put 2 extra small instances, $18,72 monthly.
Let's say you need 100 GB of space (images, backups, ...), $12,50 monthly.
At his point, you have all in place to start your business paying less than $50 monthly.
If you site have exit and the visits starts to come, you change your instances for small instances (it's really dangerous to have production environment with extra small instances, because do not have cpu reservation). Then you change the extra small cost ($18,71) up to $57,60. Maybe you need more space to that SQL Azure? etc...
prices calculated from here: http://www.windowsazure.com/en-us/pricing/calculator/?scenario=web .
Those are few tips, there is a lot more. My advice is to start a trial account and play with it.
Final advice: Its very easy to solve everything just purchasing more resources. Sometimes you need to refactor and optimize your code. If you simply add more resources each time you have a problem, you could end with a huge bill and a very messy code.
Hope it helps!
Another advantage of Windows Azure Cloud Services over Web Sites is that a cloud service can be added to an Azure Virtual Network. This can give it access to on-premises resources like databases. So if your requirements are such that you need the scalability offered by Azure but need to keep your data on-premises due to security restrictions, cloud services is a better choice.
Azure web sites cannot be part of an Azure virtual network. To access on-premises resources mechanisms such as Azure Service Bus Relay must be configured.
We've had our web site running on PHP on some hosting and at some point decided to move it to Azure (where sits main part of our service). We've started with Azure Web Sites which was great from development point of view (mainly integration with git). But after about a week of testing (when we've decided to actually move the production web site) we've found that currently
No SSL for custom domains
Custom domains are available only for reserved instances (no shared infrastructure)
SLA
So we moved to Hosted Service. The main problem for us was lack of ability of simple deployment (need to build package and upload whole package of the web site), and found solution was to use dropbox - as a startup task for role, we're installing dropbox service on the machine, which takes all the web site from dropbox, which in turn have SVN checked out folder, so site updates became very easy.
I heard that apps don’t port directly and they have to be specifically written to work with Azure. I’m new to Azure and did some reading but I don’t see anything from their site or documentation that suggests that you must specifically code for Azure, so is it true?
If this question is better suited for another StackExchange site please let me know.
You should take a look at the Windows Azure Platform Training Kit to see some introductory project labs.
While you theoretically can just "drop in" some apps into a Windows Azure VM, it hardly makes sense to do so. Some apps can be migrated with only minor changes, such as an asp.net website - session state is easily handled by AppFabric Cache, and the Web Role VM is Windows Server 2008 with Full IIS. However, you'd still need to integrate with Windows Azure Diagnostics, to be able to have external visibility to the health of your app.
Further, with the example above, there are more optimal things you can do, such as moving static content to blob storage, and taking load off your VMs. This requires you to upload this content, and then change your IMG and other tag URLs to point to a slightly-different URL.
Just remember that you're moving to Windows Azure to take advantage of its platform and related services, not just to be a rack to host a server. To take advantages of these services, you're going to have to target them specifically, such as:
Access control services
Caching
Connectivity (vpn, service bus)
Diagnostics
Database (SQL Azure)
Synchronization services
Traffic management across data centers
This is somewhat true. Your apps will typically run as-is. You just need to add an azure project to the solution, and add your MVC apps as roles to the Azure Project.
I found O'Reilly's "Programming Windows Azure" to be a good conceptual introduction to Azure.
I am trying to understand exactly an AppFabric in Windows Azure, What is the difference with Worker Role and Web Role and How to create a project of AppFaric in Visual Studio 2010, i mean which kind of project ?
Thx.
Adding a bit to vtortola's answer:
There are three core areas of the Windows Azure platform:
Windows Azure (which provides virtual machines and massively-scalable storage through Blobs, Tables, and Queues
SQL Azure (which is a large subset of SQL Server), offering a full relational database up to 50GB
Windows Azure AppFabric (a set of services that you can opt into, currently comprising access control, connectivity, and caching)
When you construct your Windows Azure application, you can really pick and choose what pieces of the platform you're interested in. For instance, Windows Azure provides Web and Worker roles (both essentially identical virtual machines running Windows Server 2008 or R2, but Web roles have IIS enabled). If you need a relational database, you can very easily set up a database. And, then there's AppFabric:
If you need to connect to a set of web services on premises, for instance, you can use the AppFabric Service Bus (a secure way to connect without having to open up a firewall)
If you need to actually connect to an entire computer on-premise, use Azure Connect (a software VPN).
If you want to cache data (such as asp.net session state) between instances of your virtual machines, enable and use the AppFabric Cache (currently a Community Technology Preview, so no pricing yet).
If you need to add access control to your application, use AppFabric's Access Control Service, which essentially lets you outsource your identity management.
There are quite detailed examples in the Platform Training Kit that vtortola referenced. Additionally, there's a complete Identity Management training kit.
Azure AppFabric is a suite of middleware services and technologies to help you develop and manage services/applications that use Windows Azure. Middleware is typically defined as software that helps connect other pieces of software, and this definition is pretty accurate for the services appFabric provides.
You don't create an App Fabric per say. AppFabric services are used by your other applications as needed, so setup is typically configuring certain items in the Azure Portal, then implementing libraries of config entires in your web/worker roles that leverage the resources.
Essentially AppFabric provides certain resources that you need when composing complex applications as services, vs. you having to implement and maintain these resources yourself.
The basic offerings are:
Service Bus: A message relay that can be consumed by other .NET technologies (and others). SB helps you connect different cloud services as well as "hybrid" services. The hybrid is a big deal, as SB helps you easily connect on-premise web services with services you run in the cloud, w/o having to mess around with VPN, protocols, server setups, certificates, etc etc.
Access Control: An authentication and authorization service, helping you manage user-level access without having to extend/implement Active Directory, LDAP, and custom user authentication modules throughout Azure.
Caching: an in-memory distributed caching layer for your applications. This is typical to memcached or the Windows Server version of AppFabric
Integration: a PaaS service of EDI/transport technology like BizTalk server
Composite App: allows the composition of complex applications using a compistion language versus just putting a bunch of code together. You basically define your application using a designer like you would a EF.Net data model or a Windows Workflow
So basically AppFabric provides you with a lot of services that you likely need, but the typical cloud developer may not want to "mess with" at least at first. This way you have these great building blocks to help you focus on your core logic/needs during development cycles while not limiting what your application can ultimately do. This "focus" is one of the core benefits to cloud computing, especially Platform as a Service, and is one area where Azure really shines compared to other offerings.
Some of these technologies are still in beta. The AppFabric site makes this very clear, but its important to be aware of.
Great place to start is the Azure AppFabric site itself, which breaks a lot of this down, gives you great examples of how to use, and some sample code for you to get your feet wet.
http://www.microsoft.com/windowsazure/AppFabric/Overview/default.aspx#top
Basically:
WebRole : similar to a web
application.
WorkerRole: similar to a Windows
service.
AppFabric: Group of services that
allow you interconnect applications inside and outside Azure.
Download and read/do the Azure training kit, it will solve those questions and tell you how to create that project in Visual Studio step-by-step.
I am a web developer that are working on several web applications. For my projects (running in a production environment), I always strive good performance.
So, I have started to look into Microsoft Azure. I have deployed some test-apps and they all work fine. They all run a lot quicker than on my regular shared hosting environment.
My questions are:
1. What should be ran at Azure? Are you suppose to deploy your whole web app (along with images, scripts etc) or are you just suppose to deploy services? (such as WCF)
2. It says "Data transfers within a sub region are free.", but what is a sub region?
3. CNAME works, but is it possible to use A-records of a domain to Azure?
For web sites that are just jQuery slabs calling web services Azure is very easy to adopt. Azure can store any type of file, so for traditional web sites follow this guide
Azure process to Azure process, or Azure SQL etc. May included other non Azure services within the same Microsoft network area. Basically they are saying LAN access if free, whoopee
What would you point you A-Name too? Azure is virtual
Here are the answers I can give you:
It depends on what you want and what kind of (web)application you want to build for Windows Azure. If you're going for fast performance, perhaps it is faster to deploy everything to the cloud (but face the financial costs)
A sub-regio is North-Europe, another one is West-Europe. So data transfering inside North-Europe will be free of charges. But if you have data transfering between North- and West-European hosted application/services you pay for this.
Note: North- and West-Europe form 1 region
Sorry, can't give an answer to this one
Azure is definitely geared to handle more than just hosting web services.
Putting all your web site's static content in Azure storage should enable you to take advantage of the Windows Azure Content Delivery Network (CDN) service, which basically replicates your static content out to geo-local caches at the edge of the cloud to reduce network load on your Windows Azure web roles and improves the responsiveness of your web app for your end users scattered around the world.
Read more about the Windows Azure CDN here: http://blogs.msdn.com/windowsazure/archive/2009/11/05/introducing-the-windows-azure-content-delivery-network.aspx