I am currently developing an MVC app using asp.net. My final aim is to deploy the saas on Azure.
But would it be feasible to do it at a later stage or should i incorporate it into my development?
When it comes to use Azure authentication etc i will require that due to the app being multi tenancy.
Just wanted to know peoples thoughts on this?
Cheers
It would be better if you can provide more information. Do you want to know if you ignore Azure at the moment, how much effort you need to take if you decide to deploy the application to Azure? In general it would not take too much effort, unless you want to use Azure services, such as storage, ACS, and so on. Deploying an ASP.NET application to Azure web site is just like deploy to a remote IIS. Deploy to web role requires you to create an additional cloud service project. Deploy to virtual machine usually does not require any modifications to the project, but requires you to setup all the environment.
In addition, please note there’re still some difference between Azure and local environment. For example, we usually use Azure SQL Service instead of connecting to the local SQL server.
Best Regards,
Ming Xu.
I'm doing something similar, but without developing on Azure right now. I have prepared for it though by making sure I use interfaces as much as possible. For instance, I don't write to a file system using File and Directory, but to interfaces IFile and IDirectory.
If you can avoid assuming anything based on your current localised, Windows Server environment then you can at least write implementations to satisfy requirements that do work in Azure. I'm planning to deploy to Azure and local Web servers and use Dependency Injection to satisfy the concrete implementation of the interfaces. I could just as easily use the same codebase entirely and have it detect the environment before injecting the implementations.
Related
I am building a web application where development teams can install and use inside their companies. I am exploring the possibility of adding SSO support with Github since it is very convenient for developers.
In Github API, Auth0, Google etc. you need to specify Callback URLs.
The problem is that since everybody can deploy an instance of my application they can host it under any valid domain or just use a local ip address. So the Callback URLs cannot be predefined.
One option is to instruct people to deploy the app under certain local domains/subdomains. However, I don't think this is a good solution.
Do you know any other options that might solve my problem?
Is SSO only suitable for apps that run under global(already known) domains?
I have developed an application with Laravel5.1. Now I need hosting suggestion for deploying my application. I know it's a silly question but I want a reliable answer. Before buying a hosting I want to know which hosting service will provide proper environment to run a laravel5.1 application.
Php version required >= 5.5.9
This is such a hard question to answer as it all depends on what you're after.
Some questions to consider:
Do you want to set the server up yourself?
If this is the case then any unmanaged provider will do the trick, you'll just need to set it all up; LAMP, Git, Composer etc.
Do you want to manage the server itself but you aren't sure how to set it up?
Digital Ocean (and other providers I'm sure) offer one-click apps where you can deploy whatever you want. For Laravel you would probably want to pick the LAMP app install. These deploy all the packages you will require and set them up for you so that you don't need to - the rest of the server management would be up to you from there.
Do you want to use Managed Hosting where they do it all for you?
OVH have been pretty good for me in the past, I've never used their managed option, although I know they have it - and I've had great service from them too.
If you're still not sure then I would suggest looking for a provider that provides servers that come with a LAMP stack (as this covers everything you need for Laravel) or one that supports PHP applications - if you're not sure then just contact the company and ask. Or find someone (a friend or a professional) who can help you get started online.
One suggestion because you are using Laravel is to look at https://forge.laravel.com/ where you can handle servers that runs in Digital Ocean and other providers.
Fits perfectly for Laravel.
So after beginning my azure websites-adventure, I have been encountering disappointment after disappointment to the point of 'almost' regretting taking the azure route..the latest: my app uses wkhtmltopdf(Rotativa) for all its PDF generation. And as I discovered now during my staging testing...that doesnt work. According to most info on the web, azure websites cannot run .exe's. However, most info I've seen is by now 2 years old and I know Azure development is going fast.
Is there by now a way to run wkhtmltopdf on azure websites, or a workaround atleast? I cannot really find a free alternative like wkhtmltopdf to seems to be working.(Itextsharp doesnt seem to like my html, so thats no option).
Running wkhtmltopdf is now supported in Azure Web Apps - just make sure you are using Basic, Standard, or Premium App Service Plan. Consumption Service Plan and Free App Service Plan have a more limited sandbox and are NOT supported in my testing. MS confirms supportability of wkhtmltopdf in Azure Web Apps.
Hosting - App Service Plan
There are numerous wrappers available (TuesPechkin, Codaxy, etc.). Codaxy is an EXE wrapper in .NET while TuesPechkin is a .NET wrapper around C++ runtime using P/Invoke over wkhtmltox.dll.
Running wkhtmltopdf in Azure Websites in a simple way seems to be impossible, still.
Static .NET wrappers like Pechkin wont work either in WebSites, there are very few alternatives that are 1. free and 2. dont use wkhtmltopdf or similar under the hood. Most alternatives like iTestSharp are not very advanced when it comes to html/css3/javascript reading (as I do some design changing with .js on page load).
I ended up creating a Azure Cloud Service, that runs wkhtmltopdf.exe without any issues. I send the html to the service, and get a byte[] in return. So far this seems to be working fine.
Hope this helps others with similar problems.
I will developp and host an e-commerce website based on Asp.Net MVC4 (with several SQL Server Jobs).
I think use Azure in order to stay in Microsoft's world and avoid dedicated server management.
The package Web Site Shared with 1 site / 5Go SQL Server Database / 200Go Bandwidth is very interesting with the price based on 12 months.
But i don't know if this configuration is enough specially on the bandwidth.
What do you think of ? Did you use Azure with this type of application ?
Regards,
Guillaume.
If you want to develop E-Commerce application you will have to secure customers' sensitive data i.e. credit cards, address details etc. via secure connections (HTTPS; in many countries this is legal requirement). For that reason you will have to have SSL support.
Azure Website do not support SSL for custom domains. However, they support SSL for *.azurewebsites.net DNS name. So if your E-Commerce application DNS will be, say, my-ecom-app.azurewebsites.net then it's fine. Otherwise, I would not recommend Azure Website solution yet (I am sure SSL support for custom domains on Azure Website will be implemented).
Azure Cloud Services, on the other had, have full support of SSL for custom domains.
One of the really good websites to check Azure features and development roadmap is ScottGu's Blog
Azure Web Sites do not support SSL and I really don't know of any successful e-commerce site that does not run SSL for at least part of the website. If you really want to host your e-commerce on Azure today your only real choice is to run Virtual Machines for your web front end servers and use them for your DB or use SQL Azure.
We developed platform called Virto Commerce that does just that, MVC4 website hosted on Azure. There was also a need for SQL Jobs (indexing, payment processing, cart cleanups and so on) for which we used WorkerRole (instead of WebRole). WorkerRole and WebRole can actually be combined as part of a single deployment, however it is better to use a different instance for worker roles. In our case WorkerRole acted as a scheduler for multiple jobs defined in the database.
The challenge with WorkerRoles however is to make sure they scale well when new instances are added. So the workload needs to be distributed between multiple instances. This is done through the use of queues and blob locks, where each job is now split into two, one that schedules and partitions the work and the second that actually picks up the next partition and completes it.
Hope this helps!
PS: Virto Commerce is now available as an open source project on codeplex, go to http://virtocommerce.codeplex.com
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am starting to migrate a couple of applications to Azure. Seems very straightforward and all I have to do is add an addiitonal Azure project to my solution and point it at my web project.
However what concerns me is that the team starts contaminating my applications with Azure specific functionality and relying on it. For example File uploads would be to Azure storage, azure caching etc. All well and good if we stay Azure and all clients are happy to use Azure. If we find a client isn't happy with Azure I'd like not be into a lot of work removing Azure functionality.
Just wondering if anyone had experience similar issues. I guess ideally I'd like to be able to have the project right publish to Azure and it uses Azure features, Azure Code etc and a second publish that just allows me to use IIS with non Azure features.
I assume I just need to be careful use interfaces correctly and DI etc. FileUpload vs AzureFileUpload. What about issues like resources coming from Azure storage for CSS/scripts etc rather than local? Should I look at using Azure Cloud Drive to simulate just standard NTFS environment
Is there any advice/patterns/practices? Has anyone experiences with similar? How about separating projects up and project structure etc? I guess a lot of is it just standard design. Just wondering how other people were approaching avoiding lock in with Azure.
There's a couple things you can do if you're concerned:
Stick to the core technologies like asp.net, ado.net, sql which also exist outside of Azure.
Abstract away code which uses Azure specific services.
For the first one, simply scan your code to ensure the runtime services don't include Azure namespaces.
But, to be a cloud like service and get it's benefit, you should look into adopting azure services.
For the second, you can create a cloud services layer abstracted away by an interface. Only that layer communicates with azure specific services. If you need to work outside of azure, you just need a plug-in for that layer.
If you want the app to be able to run on IIS or Azure, and those are your only 2 targets, my only advice is don't overdo the abstracting / interfaces. There are some differences that can be handled in web.config and WebRole.OnStart(), such as using cache as a session provider or logging diagnostics to table storage.
Some things it will help to create interfaces for, and then inject those interfaces in the config depending on your deploy target (web config transform is what we use). For example in IIS you might want to send an email in a separate thread, whereas in Azure you might use a worker role and a queue. You can set up a web.config transform with 1 implementation of ISendEmails for IIS, and different one for Azure.
Another thing you could do, depending on how much file data you have, is store files as blob columns in the db. I'm sure someone will tell me this isn't good for performance, and can get expensive with GB of file data in sql sever, and they have a point. It may be worth considering though if having IIS/Azure flexibility is of high concern.
I would design a cloud interface (as an abstraction of an actual cloud/network) that your applications can use, together with an Azure implementation of that interface.
Then later, when needed, you can make other cloud implementations that your apps can use using the same interface.
When designing the interface, the challenge is to include only generic methods that are relevant on every kind of cloud/network. So this will prevent using any Azure specific features directly by your applications, but that is exactly the purpose.