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.
Related
I am evaluating wep api gateway for my new projects. I used azure api gateway in the past. Reading about nginx as it is new and adopted by many. Can someone help me point out with some facts, pros, cons? Bug matrix will be a best help for me
Azure API Management is a mature and widely-used product, with many customers being very respected enterprises. Take a look at some public case studies.
It offers a very wide range of features, which are typical of an API management platform, and it is still being very actively developed. However, one of its biggest strengths lies in integration with Microsoft Azure services and features - multiregional deployments, virtual networks, monitoring and alerting solutions, native support for Service Fabric, Azure Function Apps and Azure Logic Apps, Azure Active Directory and others.
If you are considering hosting your new projects with Microsoft Azure, Azure API Management is a no-brainier.
The product is also one of the main reasons why Gartner named Microsoft a leader in the enterprise integration space.
Disclaimer: Although all of the above is best to my knowledge, I am affiliated with Azure API Management.
Although I have just started looking into this myself, here's what I can already conclude.
Looking at www.nginx.com/blog/deploying-nginx-plus-as-an-api-gateway-part-1/, Nginx requires a lot of manual configuration washed over many text files. That doesn't look flexible or effective, but I may have gotten a wrong impression.
Judging by how you're supposed to define your API keys using the map directive, Nginx API Gateway also looks like a new idea stretched on top of the existing product, while Azure API was designed for that exact purpose from the ground up.
Azure APIs, when published, come with auto-generated documentation and an interactive console that are in sync with all your updates.
With Azure API, you're putting all your eggs into one basket and completely depending on it's pricing and availability. At any moment Microsoft can increase their prices, or discontinue the product, and you cannot migrate elsewhere, at least not easily/quickly. At the same time, you can do your Nginx work once and run it on pretty much any server, starting with a low-end VPS or a Raspberry PI, if you'd like. It's pretty much yours.
As I heard that there are many things need to be considered before Deploying a Meteor App, However, it's still quite vague. Anyone please give me some opinions about this issue. Thanks
This is probably the wrong forum for this type of question, since it's highly opinionated and not really in the Q&A format, but I'll give you some of my personal opinions.
Where am I hosting my app?
This has a lot to do with what your app is (Web-based app, Android-only), how many users you plan to have, if this is a public app or something private, how much you have to spend, and many other factors. Options include:
Host it yourself - Could be on a VPS (Virtual Private Server, like Digital Ocean and others), some cloud offering (AWS or similar), or a bare-metal server you have hosted somewhere (like in your closet).
Pay for dedicated hosting - Several out there that offer many different features, like Galaxy or Modulus, etc.
If you host it yourself, then you have to maintain the hosting solution, I.E you need to support it all on your own. This may mean provisioning/installing the OS, installing and configuring the server apps (MongoDB, Node.js, web servers, etc), and maintaining everything over time. The benefits, however, are potentially cheaper hosting costs (although this could be debated) and custom setups/architectures. If you are creating an app that should remain private (I.E. not a public app) you may want to consider this option so you can host it internal to the company and not make it public-facing. There are some tools out there that can ease the process of setting up the server, for instance MUP/MUPX.
For dedicated Meteor hosting, the benefit is that someone else does the installation, configuration, and maintenance of the core apps, and all you have to do is push the button to move your code in. These options can be more pricey as they are covering the IT costs of supporting the environment, but they usually come with the benefit that a) You don't have to install all that stuff yourself, b) you don't have to be an expert at all the "plumbing", c) You don't have to hire a staff of people to support your infrastructure, d) These hosting services usually know how to optimize things properly to get better performance for your app.
Do I deploy manually or do I use some tool?
This depends highly on the answer to #1, as your hosting decision may come with it's own set of tools used to deploy (ex. Galaxy), or you may need to shop around for the best tool for you. For manual deploys, I'd suggest looking at MUP/MUPX, which can automate the deployment of your app, even configuring the web server, DB server, and setting up everything as Docker images. Or, if you want to have more control, maybe take a look at something like Grunt or Gulp, which are more build-scripting solutions (similar to ANT/Maven/Gradle are for Java).
Do I expect a fast growth, or a slow trickle?
Again, this has a lot to do with where you plan to host. Lots of cloud services make it easy to grow/shrink your cluster of servers based on load, but this takes a LOT of configuration past just installing an OS. VPS and bare-metal solutions will be the hardest to expand. Dedicated hosting will depend on the provider.
You need to serious need to think about how you might handle a fast-growth situation, even if you don't think your app will take off. The internet is riddled with apps that failed because they didn't think they would be as successful as they were. It only takes one mention on something like Reddit, Y Combinator, or Product Hunt for your app to get a sudden and unexpected rush of traffic that takes down the server(s). If you know your growth will be controlled in some way, like if you have a private app with a pre-set number of users, then you might not need to worry about it.
Do I need to monitor my app?
The answer to this is always "Yes", but to what extent? Do you need to provide 24x7 uptime? Would an outage cost you lots of money, make you loose your biggest client, etc? Can the users live without service for a little while if it goes down, or would I loose face and customers? Depending on how serious you need to be, you should consider some sort of monitoring of your infrastructure and app. Again, there are LOTS of options here, and your decision might be swayed quite a bit by the answer to the first question.
I am sure there are other questions, but these are the biggest I could come up with.
I have implemented an asp.net web site and hosted it in Azure as a Web Role. It is a relatively simple application making use of a database.
I am interested in high availability of the web site, thus I am using scale out feature of the Web Role; instant high usage of the web site is expected (peeks), so I am interested that the scale out operation to be fast.
My question is which is better to use in order to achieve high availability - a Web Role or an Azure Website? I observed that scaling out the Web Role takes sometime (meaning about 10-15 minutes for the virtual machine to be created and started);
Is it supposed the scaling out of the Azure website to be faster?
Is there anywhere on the microsoft's azure documentation mentioned about this?
Thanks.
So, a few general observations that are "as of today". Azure Websites have the following advantages
Azure Websites definately scale much faster. New instance comes up really quickly.
Deployment into Websites is usually simpler and easier
However, from other perspective, Web Roles have more of an advantage when it comes to the following:
You can get alot more control over how scaling occurs, especially if you're using services like AzureWatch. This is because, Web Roles are full blown VM's and one can potentially use any performance counter to input into scaling decisions
Web Roles are not as managed as Websites, and are generally less prone to have "Azure issues". The more managed a service is, the obviously, more possibilities there are to occur some "host-related issues"
So, what this means, is that Websites can execute scale actions faster, but with Webroles you'll know better WHEN to execute them.
Which one is more improtant to you?
HTH
I want to know the difference between multi-tenancy and single tenancy.
Is tomcat supporting mutli-tenancy .Can you explain both with an example.
I am asking this question in context to http-servers.
Definition
From Wiki definition
In a multitenancy environment, multiple customers share the same application, running on the same operating system, on the same hardware, with the same data-storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data.
So you can imagine that single tenancy is the other way around.
Example
Let's take JIRA as an example,
If you use OnDemand JIRA Service, it is multi-tenant, cloud-based service.
If you download JIRA Standalone and install it for you organisation. It is single tenancy case.
Designing multi-tenancy software
Designing multi-tenancy software is nothing to do with the hosting technology. It's actually about the way you architect the software.
Tomcat in your case, is absolutely suitable for multi-tenancy software.
platform: ASP.NET 4.5, MVC 4, C#
I'm currently designing a website that's available on the public domain. However, there is a meaningful % of my target market that would be uncomfortable putting some information on a public site, even if it's https etc.
What I'd like to be able to do is allow corporate users use my site, and one way to do that is to allow them to host my website on their intranet. The usual disadvantages are, of course, that they don't get their site updated as fast as the public one would, and it's also a headache for me in terms of support.
My questions are
What are some strategies to make "corporate friendly" deployments easy and hassle-free?
Are there ways I could keep the site public with just the database inside the intranet (can't see how... but then I'm no techno-know-all)
If I have no choice but to make it locally hosted - then what's the best way to do it to keep my development/support overheads at a minimum?
I hope the mods don't lock this. I'm asking for specific methods and technical approaches to a very real problem.
Thank you,
For #1, there's a many facets to the question. A couple thoughts that might help you think it out:
Deploying your app: Make it simple to deploy, and to upgrade, between versions of your application. Try to make it happen as a single operation, not upgrading different parts by hand manually. As Darin Dimitrov mentioned, you could look into a technology like Web Deployment Packages, especially with Visual Studio 2012 which will have incremental database publishing (in VS2010, the database was non-incremental so there wasn't really an "update" story). Keep the cost of deployment down so that they can afford to upgrade more frequently (not the cost of your product, but the overhead of who's getting paid to keep the system updated and running).
Consider differences between running on the Internet and on an Intranet: For example, authentication on the Internet is usually done with forms based authentication. On an intranet, you may want to consider supporting Windows authentication for a seamless login experience for corporate users. This should impact your designs to allow authentication to be modular between your deployments.
Corporate adoption of newer technologies might be slower than you want: You're using the latest and greatest (ASP.NET 4.5/MVC4). Some companies might not be prepared to deploy this now, or for a couple years. Consider if you could use an older, established technology, such as .NET 4 - having been out for a few years, it's already somewhat proven and has adoption.
For your 2nd question, it comes down to what their IT is willing to accommodate. Many corporate sites have the database within a secured LAN, but the web server is accessible from the public Internet. It's certainly a well-understood network design, but depending on the assets involved in your application, your customers may or may not agree to it. This one's a business decision.
For #3 the answer is common to any long term software project. It has to be high quality and maintainable if you want to minimize the hassle.
If you're only going to support the last N versions, make that very clear. Avoid supporting code that you're already fixed long in the past. Consider providing extra support or affordable upgrades to keep your customers on newer (and hopefully better) releases.
Keep in mind what components need to be upgraded between versions. Your web app (obviously), but also your database schema and any dependencies or libraries you're using. This is mostly the same considerations as #1. Make sure you have a good plan for upgrades and rollbacks.
Most importantly, test, test, test. Have functional regression tests and install/upgrade tests, and try out as many possibilities as you can think of.
Answer to only 1) above.
I would recommend a continuous integration tool. We use TeamCity and deploy mvc3 and mvc4 applications to our public as well as privately hosted sites with a click of a button. Previously, we used cruise control, but now we are more satisfied with TeamCity. Read up on them. Might lead you in the right direction.
You may checkout Visual Studio's Web Deployment Packages. They allow you to prepare a package that could directly be installed on your client's web servers.