I am about to develop a new website (SaaS) project and want to use Azure as the platform. I want every clients data to be isolated from each other which i chose to achieve by using elastic database engine.
Each client must have a specific endpoint like bla.siteName.com, bla2.siteName.com, bla3.siteName.com this is easily achieved by subsomains and usage of custom domains.
And finally website itself should be hosted on azure web app but here is where i hit a wall.
I want to be able to move each client at a time to the newer version of the web application.
So if My web app is runing version 1.0, and i add a new feature in version 1.1, i want to be able to move client and clients db to version 1.1 without them noticing it.
So far my thought is to publish new web app version 1.1 and move subdomain name of that specific client to version 1.1 web app. But this will end up in downtime, because switch of subdomains take time.
Am i missing something or am i just about to overengineer something that is very simple?
Or should i just focus on single website serve all approach, and just upgrade all clients databases at once?
You may want to try Azure Deployment Slots. It has many uses, including the one you describe. You can use Azure Traffic Routing to route a subset of your users to one of your deployment slots.
Related
I build a web based mobile app (using react), which I'm hosting as an Azure Web app. This website is connected to a node server, which I'm hosting using a azure virtual machine (I don't know if this is the best approach, maybe I should host this as a webapp instead of VM ?).
I'm still new to this strategie of developing a web based mobile app and connecting it to a hosted backend in the cloud so I apologize if this is a trivial question.
I'm using websockets to connect my frontend to the node server and then I consume messages. I don't have a database it is a simple application.
The steps I'm doing to run the app are:
I connect to the Azure VM from my laptop with ssh
run my server using node server.js
When the server is runing, I can refresh my website and everything works fine
Now, the problem is that I want the node server to run all the time. However, I noticed that the server stops running when I deconnect (ssh) my laptop from the virtual machine. So I find myself doing these steps (connecting to the VM with ssh and running the server manually) each time I want to use the app.
Is there a way to do this so that the node server runs all the time without stoping? Also since I'm new to this, is this the right way to deploy frontend and backend? I assume I can't deploy both frontend and backend in the same Azure webapp or am I wrong?
(Since part of your question is around "Is there a better way?", I would answer that instead of fixing the issue in your current VM hosting :)).
To take full advantage of cloud for your applications, PaaS is always preferred over IaaS. In this case, unless you have any specific reason, you should deploy your backend Node app in another App Service (aka Web App). Or you can consider Azure Function also if your node app has a small set of APIs, but it will require code update. Both support multiple platforms including node.js. Since you mentioned you are leveraging Web App for your react mobile app, so I hope you are already bit familiar with it. Also since Azure Function would require code change, so Web App is preferred this case.
Note: I omitted other solutions like AKS, Service Fabric etc. for now, since currently we are talking about the problem of deploying only a single app, for which those will be overkill at this moment.
Also, to your point
I assume I can't deploy both frontend and backend in the same Azure webapp or am I wrong?
Yes technically you can, depending on your scenario by "bundling" into a single app if both are in same platform (like Node in this case). Though whether one should do that would be an opinionated answer. But even if you keep those separate, you can still leverage single App Service Plan for cost saving. So keeping separate like you have now is what I would suggest to maintain "separation of concern".
Is it possible use have a web-browser control inside a UWP app that connects to a local web server?
I can have the app connect to a live service, but some users need to be able to get access to web pages while working off-line.
Ideally, I'd like to replicate the feature on a local service, but I can't find anything to support this sort of feature. My guess is, it breaks the sandbox rule for UWP apps, but I thought there may be somebody that has been able to make this happen.
Can I use one azure mobile app as a backend to support for mobile app and website?
I need it to support push notification and authentication as well as CRUD operation. Should I use API app or Mobile app or something else?
An Azure Mobile App is just a regular ExpressJS app with the Azure Mobile Apps SDK implemented. Here is a good example of a combined web + mobile:
https://github.com/adrianhall/azure-mobile-apps-html-quickstart
The 'public' directory contains the static website, complete with JS and CSS files. The app.js is your app (note the serve-static module usage to serve up the static content).
Now that Mobile App, Web App, and API App are under one roof so to speak you have several options.
They are all part of App Services.
The easiest way to think about App Services is in terms of a VM that hosts multiple web apps in isolation.
You create an App Service that is like a VM and then you create multiple apps that run in that VM.
You could create a Mobile App and a completely separate Web App that share a common database for instance.
You pay for the App Service instance, not each app, so it's really up to you how you want to divide up the functionality.
Now before someone cries foul on my VM analogy, I said it was the easiest way to visualize it, not the most accurate.
What you really get is a "Virtual Virtual-Machine" that could be one or many VMs. You see it as one logical thing in terms of management, deployment, etc. but it could really be multiple VMs. It can scale up or down based on your configured options (eg 1 VM always, scale up to 5 VMs if CPU or Memory exceed thresholds you set, etc.).
I'm currently developing a mobile app which will be pushed world-wide across the app stores. This app uses a WebAPI REST service as the backend which I currently have running on MS Azure in Europe (which backs onto a database also in Europe).
My problem is, I'd like to create multiple Azure WebApi endpoints (i.e. Australia, US, etc for latency reasons), each with their own database which has geo-replication enabled.
Does anyone know a method/product/service I could use which allows me from the app to either:
Connect to a single domain which behind the scenes picks the closest server to the user.
OR
The app itself is able to determine based on a given list the closest server and connect to that?
I've looked at Azure CDN but this is for static content which is great but I need something for dynamic content.
What you're looking at is Traffic Manager. Traffic manager enables that exact scenario, of finding the closest service that hosts your REST API.
Keep in mind though, that the database replication is (for the time being) a thing you have to do yourself, although we do provide you with the tooling and guidance on how.
I'm fooling around with a WebAPI application I've developed in two solutions: one solution is the WebAPI / serverside solution with db access using SQL server, the other is a durandalJS client application. I have the WebAPI bits hosted in an Azure Website right now, but I'm not sure where to put the client solution.
Should I throw it in its own website and just have it make requests within azure across to the other website? I want to avoid putting them in the same solution because I would eventually like to practice load balancing the front-ends when I have more dough to play with.
Idea of cloud like Azure is pay as you go. If you do not have the volume currently to load-balance, why create two websites and pay for them both regardless of the usage? You can have just one web site and host both the web application and web API. In the future, if you want to separate out API piece and load balance web app, you can do that when you have the volume. For this approach to work, structure the solution like this. The Web API piece will be just an assembly which you can reference in the Web application itself and host it in the same web site as the web application. In future, if you want to separate out, create a new empty ASP.NET Web application and host the Web API referencing your Web API core assembly.