I'm looking for examples that show Azure scales up well. Does anyone know of any large, high-volume sites that run on Azure?
This type of question seems out of scope. That said, try looking at some Windows Azure case studies. This is where you're likely to find information on deployment details. Typically, deployment details aren't revealed to the general public, and those of us who do know about such deployments are usually bound by NDA's.
Related
Is it possible to learn Azure practical skills without paying or providing my card info?
I found out about the https://portal.azure.com/. And about the modular tutorials https://learn.microsoft.com/en-us/learn/browse/?products=azure. But I am not sure whether or not it will be feasible for me to cover all important for the commercial development topics with just the free resources above.
Maybe there are other ways to learn Azure profoundly without paying or providing my card info? It is an important question for me, because I really want to learn Azure a lot, but if there is no free plan to learn it, then I will have to pick something else (e.g. AWS or Heroku).
Here learning Azure implies being able to access theoretical knowledge base and documentation (both of which I am sure are present) and also being able to use a fully free (and without any card info) sandbox environment. And the question is a doubt that such a free sandbox environment exists.
The Microsoft Learn resource is very good and free. I use it all the time. However, not every learning module is free. Some require an account. This might be around 5% that require your own Azure account.
Can you learn Azure for free with Microsoft Learn? Absolutely YES. There are almost 1,000 modules on the site to choose from. I recommend this site even for very experienced Azure developers. For example, the VPN Gateway modules are free to practice with.
Microsoft Learn
After a while I was able to come over the Azure sandboxes. And that is what I was looking for in the question. E.g. this article explains how to use them.
Made a rather complex Asp.Net Core (2) App for a NGO, deployed on Azure, do we need WAF?
Thanks for your answer(s).
(Got the idea that most providers offer it for free. Money is a bit of an issue for the NGO).
I'm afraid that your question is not suitable for asking on StackOverflow, which seems to be not a technical issue about coding as my view. Infomation Security forum is more suited to ask for your needs, I think so.
However, Considering for reducing the cost for using some specifical secure services or features, such as WAF, you can directly realize some simple features by using Filters in ASP.NET Core as a simple secure middleware for your app, or search on GitHub to find some opensource components that features could satisfy your needs to integrate into your app.
As references, there are two GitHub repos which you can refer to.
dustinmoris/Firewall
saineshwar/Secure-ASP.NET-Core-MVC-Application
Hope it helps.
We just suffered a SQL Database connectivity issue on Azure. Although very quick, around 1 minute, it did kick all users out, and/or raised Elmah Errors such as:
The wait operation timed out ...
at System.Data.ProviderBase.DbConnectionPool.TryGetConnection
Even glitches like this compromises confidence. I am trying to understand about good approaches to confront these transitory outages. Some thoughts that come to mind include:
Have some code that checks that all required services are running before using them and keep checking with provide friendly error message until they are. I think there is a tendency to assume all is available and working, and I wonder whether this is a dangerous assumption in the world of cloud. I suppose this is more an approach one would take when building a distributed application, although one may not for a database which is usually close to the web application.
Use failover procedures such as TrafficManager. However it is expensive as one now has >1 instance and also one needs to take care of the syncing data across >1 DB etc. Associated link on Failover procedure in Azure
Make sure Custom Error pages are used so Yellow Screen of death (YSOD) is not seen:
<customErrors mode="RemoteOnly" defaultRedirect="~/Error/Error" />
Although YSOD was seen by a colleague, not sure how with the above in force. Once criticism I have of Azure is that if Websites are down, then one can get bad error pages, only provided by Azure and not customisable, although I was advised that using something like CloudFlare can sort this issue.
I think a) is the most interesting concept. Should we code Azure Web Apps as if they are WAN rather than LAN applications, and assume nodes could be down, and so check beforehand?
I would really appreciate thoughts on the above. Our feeling is that Azure is getting a few too many of these outage blips now, which may be due to increased customers... not sure. Although no doubt within the 99.9% annual SLA.
EDIT1
A useful MSDN Azure Cloud Architecture article on this:
Resilient Azure Website Architectures
I've been working on a web application and finally published it to Azure. The application is not critical and currently I use only one role to keep costs down.
I would like to start try and get a feel of who (if anyone is using my site). Can anyone give me some suggestions on how I could do this. What I would really like is not to use anything like the google scripts that I see some web sites use for monitoring page hits. I would like to do as much as possible on the server.
Help advice on where to start and what to look at would be much appreciated.
Katarina
Aside from things like Google Analytics and StatCounter, you'd want to set up some performance counters that you can watch externally. This requires you to use the Diagnostic Monitor:
Set up performance counters to track, and how often to poll for values
Set up frequency to upload to Table Storage
Diagnostic data is aggregated from all your instances, so then you can run queries against the diagnostic tables. Cerebrata has a page that details these table names (you can also use their Diagnostics Manager tool, other 3rd-party tools, or roll your own).
Igork posted this StackOverflow answer as well, which references some blog posts by Azure MVP Neil Mackenzie.
To add to Dave's answer, there are three levels of monitoring you can do:
If you want to know who is using your site, Google Analytics is best and free... There are a few others, but all involve injecting small javascript on your pages
If you want to know the load your site is under, inspecting performance counters via Cerebrata's tool is likely best # http://www.cerebrata.com
If you want to go one step further and be notified when the load on your site is outside your predefined conditions (active monitoring) or have your website automatically scale up when the load is too high, AzureWatch is probably the best option # http://www.paraleap.com
HTH
I am learning SharePoint and the different kind of solutions you can deploy. From the training I am watching it seems like you should try your best to use a Sandbox Solution when ever possible. This is because Farm Solutions can mess things up too much.
However, two of the main things I would do with WebParts are not supported in Sandbox Solutions. Those are Visual WebParts and WebPart communication. (The first is not allowed because it needs to hit the file system and the second is disallowed because it uses reflection).
It seems to me that my WebParts will always want to do at least one of those things. (WebParts that don't communicate are not really that modular are they?)
Am I missing the point or are Sandbox Solutions a "nice idea" that are not really used in actual code?
Yes, I agree with you that Sandbox solutions are very restrictive.
But, it is that restriction that gives them their value. Due to the restrictions a Sandboxed solution cannot bring down a farm (atleast that is the theory, someone may find a way to do it).
This means that you can open up to many more users to deploy things on the farm. It is also a requirement to deploy things to SharePoint Online.
That Sandbox solutions are more restrictive, means that development is more cumbersome, you have to program your way around the restrictions. This makes solutions more expensive. Therefore, the default should be farm unless you have a good reason not to use it.
I think some of the comments here are missing the entire point of a Sandbox solution, they have been deliberately given a reduced set of privileges for many reasons:
a) A site collection administrator can add a SB solution hence they need not be farm admins therefore better security of the farm.
b) You can trust that an SB will NOT bring down the farm, they don't even run under the normal SharePoint worker process, instead they are hosted under their own process that acts as a host to check to see if the resources accessed are allowed for an SB solution.
c) The cloud is coming, there’s no getting away from that fact, when somebody else is hosting your SharePoint solution do you really think you'll get access to the farm?
I think understanding the impact of running as a Sandbox Solution from a non-developer perspective is important, after all you wouldn't create a custom solution of any kind and expect the customer to grant you domain level accounts to run it, therefore when creating SharePoint solutions, think running your solution with the minimal amount of permissions by default, if there is really no other way then explore farm solutions.
Here's a useful guide from MS:
http://msdn.microsoft.com/en-us/library/ff798382.aspx
If your environment allows you to install farm solutions, then yes, sandboxed solutions are restrictive and stop you doing what you want.
However, if your environment does not allow regular solution deployment, as is the case with shared hosting and some large corporates then they are not restrictive because without them you wouldn't be able to use custom code at all.
Sandbox is horrible, i totally disagree with the statement "it is that restriction that gives them their value". you cannot do a many thing in sandbox.
1. no session
2. no web-part communication
3. no file upload controls
4. no redirect...
and it just makes things painful as hell. we are in the midst of developing an enterprise application facing outside users, my advice, if you considering Sandbox for these purposes, i would say add 150% more time for your project just to deal with sandbox issues.
most people talk about benefits, but all the benefits are not really benefits.. for example, if even a single sandbox application code raises exception which is unhandled... good luck, it will crash the entire farm, and tracking the issue is real nightmare.
if you can stay out of sandbox