Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm evaluating MS cloud Windows Azure for hosting 3 completely separated websites.
Every website has its own database and they are not connected, so 3 websites and 3 databases.
My aim is to optimize costs for a start-up project with the possibility to scale up on demand.
I would like to know:
If is possible to host 3 websites on the same instance (Extra small instance or Small instance).
if is possible to host 3 databases on the same Sql Azure database (so I would use the total amount of SQL storage for my 3 databases) or for each website database I have to pay an instance of SQL Azure.
Thanks for your time on this.
You can absolutely run multiple web sites on the same instance, starting with SDK 1.3, as full IIS is now running in Web Roles. As Jonathan pointed out with the MSDN article link, you can set up the Sites element to define each website. You should also check out the Windows Azure Platform Training Kit, which has a lab specifically around building a multi-site web role.
You can also take advantage of something like Cloud Ninja or Windows Azure Accelerator for Web Roles, which provides a multi-tenant solution that you can load into your Web Role (check out the Cloud Cover Show video here for more info).
When hosting multiple websites, remember that they're all sharing the same resources on an instance. So you might find that an Extra Small instance won't meet your performance needs (it's limited to 768MB RAM and approx. 5Mbps bandwidth). I think you'll be fine with Small instances and scaling out as you need to handle more traffic.
For the past several months, I've been running three websites on a pair of extra small instances, including albahari.com, linqpad.net and the LINQPad licensing server (which uses LINQ to SQL). The trick is to serve large static content directly from blob storage so that it's not subject to the 5MBit/second I/O bandwidth restriction. And I've never got anywhere close to running out of memory.
A pair of extra small Azure instances is a great alternative to shared hosting when you need better reliability, security and performance.
Edit: close to a year now, still no problems with multiple websites on Azure. I will never go back to shared hosting.
You can definitely run 3 websites in the same instance. Check out this MSDN article that shows you how to form your configuration file such that you can host multiple websites within a single role. One thing to note though since you mentioned "scaling on demand" - when you scale an instance with multiple websites, you are scaling the instance, which means all of the sites will scale together. You can't scale just one of the sites on the shared instance.
For the databases, in theory this can be done, but it would be "manual" in that you would have to all of your tables across the three databsaes in the same database and you would probably want to prefix them with some sort of indicator so that you know which table belongs to which application. This is certainly not a recommended practice, but if it works for your solution, then there is nothing technical preventing you from doing it. If at all possible, I would recommend multiple databases.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I am using a Bitnami Wordpress for Google Cloud. Now, I need to setup a Instance Template -> Group of instances -> Load balancer and with this, my system will be autoscaling :)
But, I have the VM instance created using an boot image by Bitnami, and I need to put in a group of instance.
Can you help me with this, please?
The answer for creating a Highly scalable web application on GCP is very long and could be made as a blog post. Since writing the whole answer here will be very long and difficult to read, I have split the answer into 3 parts.
As you have mentioned, the steps for creating a Highly scalable web application on GCP can be divided as:
Instance template
Managed Instance Group and autoscaling
Network / HTTP(s) load balancer
1. Instance Template: This is first step in creating this high scale web app. I have listed out the steps for creating an Instance Template here. One change, that you have to make in the template, is to change from CentOS 6 image to bitnami image.
Best practices: From my perspective, it is better to create a custom image with all your software installed than to use a startup script. As the time taken to launch new instances in the group should be as minimum as possible. This will increase the speed at which you scale your web app.
2. Managed Instance group and Autoscaling: I have written about the steps for creating Managed Instance group and Autoscaling here. As autoscaling and load balancing are independent, either of them
can be set up first.
Best practices: Both autoscaling and load balancers offer health check to the instances. From my perspective, setting up the health check for both the services are redundant and I think health check for load balancer alone would do good.
3. Load balancer: GCP offers two types of load balancers namely, Network and HTTP(s) load balancer. I have written about the differences Network Vs HTTP(s) here. Since I assumed that you will be building a web stack out of bitnami image, I have written about the steps for setting up the HTTP load balancer here.
By following these three steps, I hope you would be able to build an highly scalable web app. This answer is based on my perspective. If anything is incorrect or If I had missed something, please feel free to comment and I will add it to the table.
Good day.
I'm wondering if the Enterprise Library Caching using isolated storage (disk, not DB) can be accessed by multiple apps in IIS? That is , can they all share the same instance of it.
I have various WCF services running on one machine, set up in different web apps (and potentially in different app pools, if that makes a difference). They all need access to a shared cache.
I had been told that this is possible with EntLib, but after doing some reading I'm not entirely sure this is the case. All of the services are running under NETWORK SERVICE user, but since they are all different apps in IIS does this prevent the sharing? I know having a different user certainly would.
So, can the same user use the same cache across multiple apps, or is it limited to within one app?
Any guidance would be appreciated!
If you want to share your cache across several services it would be better to go with App Fabric caching. See: http://msdn.microsoft.com/en-us/windowsserver/ee695849.aspx
I ended up not using EntLib for this and just used isolated storage.
In case anybody has the same problem, you can see the following question where I posted the code I used, as well as an issue I hit while using it plus the resolution.
Can't share isolated storage file between applications in different app pools
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
It is unclear to me how cloudControl MySQLd addon works.
My understanding of MySQLd is that it is a MySQL server that can/will work with unlimited apps.
But since all addons are only app based, this could also mean that I cannot use the same MySQLd server on multiple apps.
Could anyone please help me understand if one MySQLd instance can be used with multiple apps hosted on cloudControl?
There are two concepts on the cloudControl PaaS. Applications and deployments. An application is basically just grouping developers and deployments together. Each deployment is a distinct running version of the app from a branch matching the deployment name. More details on this can be found in the Apps, Users and Deployments documentation.
All add-ons are always per deployment. We do this because this way we can provide all credentials as part of the runtime environment. This means you don't have to have credentials in version controlled files. Thich is a huge benefit when merging between branches, because you don't risk accidentally talking to e.g. the live database from a dev deployment. Also add-on credentials can change at any time at the add-on providers discretion.
For this reason separation between deployments makes a lot of sense. Usually your dev deployments also don't need the same database power as the production deployment for example. So you can easily use a smaller plan or even a shared database (e.g. MySQLs) for development. You can read more about how to use this feature inside your code in the Add-on documentation.
Also as explained earlier, add-on credentials are always provided as part of the runtime environment. Now credetials can change at any time at the add-on providers discretion. These changes are automatically provided in the environment and the app processes restarted. If you had hard coded the credentials as would be required for the second app, this would mean the app would probably experience downtime.
Last but not least, it's usually very bad practice to connect to the same database from two different code bases in different repositories, which would be the reason to have a second app. This causes all kinds of potential conflicts and dependencies that make code changes and database migrations extremely hard to maintain over time. The recommended way would be to have the data owned by one code base only and provide an API to access that data from the second code base.
All this being said, it is technically possible to connect multiple deployments or even apps to the same add-on (database or anything else) but highly advised against.
If you have a good reason to connect two apps/deployments to the same database I would suggest you manually launch an RDS instance at Amazon (MySQLd is based on RDS) and provide credentials for that through the custom config add-on to both of your apps/deployments.
I hope this answers your question and also explains the reasons.
I was reading this article Build Your First Cloud Application Using Visual Studio 2010 when It hit me:
Why would I switch from my normal
hosting (shared account, VPS, or
whatever) to host it on cloud
servers ?
Do I have to build my website with
ASP.NET Cloud Application to be able
to host it with any cloud providing
service company ?
How can I edit my ASP.NET Web
Application to be an ASP.NET Cloud
Application ?
Those are the questions I thought would help to gather a full picture about this new technology and it's own application template! but please feel free to add more points to consider in the answers.
Edit
so beside the difference in implementing a website between Azure and other cloud server
is there is a performance difference or any other differences between Azure and the other cloud servers ?
I didn't quite get what you meant by "bringing your app on site with your own staff may become more economical"
the Azure pricing are high and requires a whole new dedicated project to work with it restrictions. so both the hosting and the development are costy
I hope if there's any article about the good cloud hosting out there and perhaps any articles about the user experience (a legitimate review and maybe yours if you have any)
First, I believe "cloud" in the context of the blog article you read should really be more granularly defined as Azure. There are several cloud solution offerings and Azure is only one although it is gaining immense popularity in the MS community space. The Azure cloud is fairly unique compared to products like Amazon's cloud in that it requires applications that use it to comply to a specific set of APIs. To build an application for azure requires you to embrace certain architectural principles from the beginning and to build your app using its web and worker roles. To "fit in" to these roles, your app must be built within a special VS project that references the Azure SDK.
If you were to use another cloud solution like Amazon, it is more similar to firing up a VM or group of VMs that can host your app as is without the constraints of specific APIs. You simplu would fire up a windows server instance, install what you need on it like any other server you would use in a hosted or or leased data center environment.
I am not implying that the azure solution is flawed or overly restrictive. Rather, I think it supports some architectural constraints that will allow you to "fall into the pit of success." However, it may be difficult to effortlessly migrate many brown field apps to azure without making significant changes.
As far as why host a application in the cloud as opposed to a normal hosted environment. It really depends on your app, your business/budget constraints and your traffic level. For many small, hobby sites, you may be better off keeping your app on a traditional hosted environment. For larger scale apps, the cloud begins to make more sense. The cloud is really supporting a "pay per use" model. If you need to have the ability to scale out quickly without the funds or the ability to wait on a purchase of lots of additional hardware, the cloud is a good option. Cloud providers have deep pockets and plenty of server resources and bandwidth to send your way at a moments notice that you can rent instead of buy.
Also, because cloud providers are large and typically highly reputable, they can afford to hire expert staff and follow best practices that you may not be able to afford on your own. They can and will handle a lot of the day to day ops administration enabling you as a developer to not have to think of things like security and redundancy.
So as I see it, cloud solutions are ideal for apps that are beginning to see a fair amount of traffic, need guaranteed up time, and do not want to pay or bother themselves with their own admin staff, server purchasing and data center management. I think they are not practical for many small hobby sites and once you become really big, bringing your app on site with your own staff may become more economical.
That all said. it has become "cool" in the .net space for any site to run on azure. I'll admit that some of the architectural models are interesting and seem fun to work with. However, if you take a close look at the pricing model, you may find you are better off with your hosted plan.
Moving your .NET application to a cloud or hybrid infrastructure allows you to start evolving to a Microservices Architecture, with the ability to phase in Containers and a Serverless architecture.
You mentioned that Azure costs are high and maybe cumbersome in your situation.
Maybe consider other popular cloud providers like AWS. They have a ton of vendors and services all readily available to help make the adoption easy, in fact over 57% of Windows workloads currently run on AWS.
Here is an eBook we recently published about this exact topic.
We are currently finishing a web-based time-tracking software built on ASP.NET and WCF (for different desktop-clients). Our customers can register an account and add an unlimited number of users to their account. Pricing is tied to the number of active users in the companys account.
To keep things simple and easily scalable we thought it would be a good architectural decision if we design each account to run as a single IIS-website with it's own application-pool, SQL-Server database and subdomain.
Unfortunately we rapidly run into memory-shortage, due to the fact that a single worker-process will consume at least 150mb, which means that for every single trial-account we need approx. 200mb more of memory...
Beside the heavy costs of such an architecture (trial-accounts!), we are not sure if it was a good decision for scaling, to design the architecture that way.
How would you design such
SAAS-applications?
Single app-pool for many sites?
Single website for many accounts with shared database?
Scaling vertically (more power) over scaling horizontically (more servers)?
Any good books or blogs on this topic?
Thank you!
What are the reasons for creating a new site and application pool for each account?
A single site with a shared database (number 3 in your list) is a much easier solution that can scale much better. You can then scale up the number of web or database servers when needed. This architecture is used in e.g. Sharepoint and most public web sites.