After going through several similar questions I am still not entirely sure about the pros and cons of the two approaches; hence this question.
Based on my understanding it is possible to have
Multiple roles (Web and/or Worker) in a single Cloud service.
Alternatively we can have these roles separated in their own Cloud
service (our current approach).
What are the benefits of either approach over the other and particular use cases where either one should be preferred/avoided.
Also how do they compare to each other when it comes to scalability and availability?
When do I choose which? My understanding at the moment is both offer the same except maybe the pricing.
if you did not see that Azure Multitenancy Guidance, i highly recommend to take a look, because they wrote it using Cloud Services as an example and the link above discusses some of the architecture decisions you are asking of.
IMO, it is difficult to say that first approach is better then the second somehow, it depends on what is the scenario in your project.
I would say that one of the important things are the limits of one Cloud Service. If you have the project that has instances that should be unique for the customer, then it can be more difficult to isolate your users if the solution is in the same CS, etc. A lot of decisions - mostly depends on the project specifics.
One difference between the two approaches is in deployment. Cloud services are deployed with all their web roles and worker roles together. If you need to have separate deployment schedules for some of your roles, separating them into different cloud services will allow you to do that.
As for pricing, I don't think there is a difference as cloud services are billed on a "per (role) instance" basis and this does not change between the two options you described.
Related
I have managed to get the C# and db setup using ListMappings. However, when I try to deploy the split/merge tool to Azure cloud classic the service it states 'The requested VM tier is currently not available in East US for this subscription. Please try another tier or deploy to a different location.' We tried a few other regions with the same result. Do you know if there is a workaround or updated version? Is the split / merge service even still relevant? Has anyone got this service to run on Azure lately?
https://learn.microsoft.com/en-us/azure/azure-sql/database/elastic-scale-overview-split-and-merge
The answer to the question on whether it is still relevant, in my opinion is ...no. Split\merge is no longer relevant with the maturation of elastic pools. Elastic pools with one data base per tenant seem the sustainable way to implement multi tenancy with legacy code. The initial plan was to add keys to each of our tables to have multiple tenants per database. Elastic pools give us the same flexibility without having to make breaking changes our existing code.
Late post here, but we are implementing ElasticScale for a client to split ~50 clients into a database-per-tenant model. I don't think the SplitMerge tool will be used over the long term, just for the initial data migration from one db to many shards, but it has been handy for that purpose. We are using the ElasticScale SDK to allow a single API to route queries to the appropriate shard(s) based on sharding key. Happy to compare notes with you if you are still working on this.
I am using Azure Table storage to store the data of my application. I need to build an API to retrieve the data from Azure table storage. There are like a million records in the table. In the initial stage, my API would be getting approximately 100-1000 hits per day. What would be the best choice to develop that API on, API apps or Service Fabric?
It depends on a lot of aspects:
How do you want to maintain it?
What performance requirements do you have? Do all those 100-1000 hits per day happen at the same time or are they distributed across the day?
How do you want to handle scaling?
As described by #feranto the main difference is the architectural pattern. The decision will have a lot of implications for you, not only when it comes to development, but you will have to consider how to maintain your application.
Only based on your short description, it sounds like a relatively straightforward solution and not very complex nor very high performance/scale requirements. Given that, it might be easier for you to go for a more basic API App. Service Fabric is an excellent framework and architecture that allows us to build very flexible, highly scalable solutions, but it should be noted that that also comes with a lot more complexity when it comes to handling, monitoring and maintaining both the underlying service cluster and it's applications.
Setting up an API App, connecting to an Azure Storage table and control that with for instance Application Insights is relatively straight forward and you can find a lot of documentation and samples for that. As a contrast, Service Fabric is fairly nascent in documentation and samples, and you would have to read up on a lot to get a basic stable solution running if you are new to it.
The main difference between Azure API and Azure Service Fabric is the architecture pattern each one follows:
Azure API APPs supports a monolithic architecture. You have all your code running as one single package. You can develop this using Java, PHP, nodejs, python or .net.
Service Fabric follows a microservice architecture. Every service is deployed on a separate node, which can scale independently, and you can monitor the health of every service in every node. You can develop this using Java or C# mainly.
Here you can see advantages and disadvantages between microservices and a monolithic architecture.
I've deployed web sites and services to the cloud before but it was a while ago and I wanted to revisit my approach to inventorize my skills. During the research, I've been told to use a worker role but I'm not sure in what constellation to apply it.
The image presents my choices. I'll be setting up two things (preferably on the same base URL).
1. A web site (ASP.NET, most likely MVC powered by Razor)
2. A service layer (guessingly WCF, as there's not much else to pick from today)
So, in my naive ignorance, I added ASP.NET Web Role for the former and WCF Service Web Role for the latter. Then, according to the hint, I also added Worker Role. And this is where I got humble and started to suspect that my ignorance was rather an arrogance...
Do I need all the three of them? Or is it perhaps so that Worker Role covers the others? Or are the others sufficient and I need to Worker Role? Or am I totally confusing the concepts here?
I've tried to google those but I realize that I haven't reached the threshold of learning by doing in this area yet. I get more confused and headacheish the more I read. Admittedly, my problem might lie in the wrong choice of search words and/or linguistic misconception. If so, my apologies...
The answer is, it depends...
A web role is essentially a Worker role with IIS installed + configured. You could host a WebApi/MVC, WCF AND process events all from the same web role if you really wanted to, reducing costs.
Remember that each role is a separate VM that you have to pay for, so adding extras roles to keep everything separate may not always be the best idea.
In one of our projects for example, we use a web role to host a WebApi. A Worker role to process internal events, and a worker role to host WCF services (you can also use a web role for this). We split them because they take very different workloads and perform separate functions, so being able to scale them independently made sense.
HTH
There's no right answer to how many roles to use in a cloud service. But it's important to understand exactly what those roles are.
Adding a bit to #Peter's answer: Each role is a definition of a VM (its contents) - think of it as a VM template. And for each role (template), you must have a minimum of one instance (VM) running. If you have one role, your minimum footprint will be one VM (of whichever size you specify for that role). If you have three roles, you'll have minimum 3 VMs running.
Whether you have one role or many depends on how you want to scale your application. Each role defines not only what goes in it, but also the size of the VMs uses by the role instances. By having different roles for different parts of your architecture, you can choose to scale those parts differently. For example, you might only need low-resource instances to handle your web tier, but maybe more CPU power for your service tier. And maybe your web tier scales dynamically based on user traffic, but you're able to handle, say, your service tier with just one or two instances. Of course, you can put everything in one role definition, and scale everything together. It's totally up to you.
Iam relatively new to Cloud Computing and azure. I was wondering whether you can have more than one web and worker role in an Azure application. If so what advantages can I get using multiple roles and where do they apply?
Yes, you can have more than 1 web or worker role in an Azure Cloud Service. You can have up to 25 different roles per deployment I believe in any mix of Web and Worker roles. See the Azure Subscription and Service Limits, Quotas and Constraints link for more information.
The advantage of having the roles within the same cloud service is simply that within that cloud service they can see all the other roles and instances easily (unless you configure them otherwise). They will all be relatively close to each other within a data center because a cloud service is assigned to a stamp of machines and controlled by a Fabric Controller assigned to that stamp. You can watch this video by Mark Russinovich which sheds more light on the inner workings of Azure and talks a bit about stamps I think. A cloud service is a security boundary as well, so you get some benefits from that encapsulation if you need to do a lot of inter machine communication that ISN'T going across a queue for some reason.
The disadvantage of batching a whole bunch of roles together is that they are tied pretty closely together at that point. You can certainly scale them separately, and you can do updates that target only a single role at a time. However, if you want to deploy changes to multiple roles you may end up having to do a full deployment to all roles (even those that haven't changed) or do updates to single roles one at a time until all the ones you need updated are, which can take some time. Of course, it could be argued that having them in separate cloud services would still have you doing updates concurrently depending on your architecture and/or dependencies.
My suggestion is to group only roles that REALLY belong together in the same solution. These are role that have workloads that are interrelated. Even then, there's nothing stopping you from separating these as well into separate deployments (though you may benefit from the security boundaries that being within the same cloud service). Think about how each role will be updated, and if they would generally be updated together or not. There are many factors in thinking about how to package roles together.
I am designing the architecture for an Azure application, and I have a few questions on how to proceed. I am familiar with the basics of Azure, but have never built and deployed an Azure application before. I have extensive experience with conventional non-cloud, web-hosted applications, though.
My application will be the usual database-centric business system with a web user interface. We want to start very small and grow it slowly as we gain user base. I am planning to use an SQL Azure database for relational storage as well as blob storage for documents and the like. These will be accessed by a Data Access Layer, which in turn will be operated by a Business Layer. The web user interface will be built using ASP.NET and will rest on the Business Layer.
All this is very traditional, but I wonder how well it fits with Azure. I have some specific and inter-related questions:
I see the Data Layer and Business Layer as part of an Application Tier that can be deployed on a worker role, whereas the web user interface can be deployed as a Front-End Tier on a web role. Is separating the business and presentation logic like this a wise decision on Azure?
Having said the above, having two separate roles wouldn't make sense while the user base is very small, so I would rather deploy everything together on a single web role until we get bigger. What do I need to do to make sure that these two tiers can be easily reconfigured to work as either one or two roles with any recoding?
The communication between the web user interface and the Business Layer must be fast; I am concerned that it won't be very fast especially when these two are deployed as separate tiers on different web/worker roles. What is the best communications mechanism in Azure that I should use? I have considered queue storage, service bus and virtual network, but I am not sure how to make a decision here.
I have been reading some best practices posts and documents online, but they seem to address advanced issues. I would rather like to have answers to these quite basic concerns in the form of pointers to best practices articles or the like. Thank you.