We have an old SBS2008 server that is on the way out. We only use it for Authentication as all our apps are in the cloud now. Is it possible to be done with an in-house server altogether and use cloud services to do some/all of what SBS does? Has anybody done this?
[my thoughts so far]
Azure Active directory Looks like it might do the authentication part, and very cost effective.
Azure Domains services look like it might to the Group policy part, but looks expensive ( probably more expensive than a server for a small business).
Azure DNS looks like it might do the DNS part and cost effective as well.
Obviously, DHCP would now go on the router
Please don't shut this question down, I need a helpful answer to a specific question, I will reword it if need be ( just comment ). :-)
You have to look at your overall roadmap and strategy for the company really, rather than just replacing what you have with new technologies.
I'd recommend that you try and move away from using ADDS and modernize workstations to Windows 10, being Azure AD joined. Move away from Group Policy, and look at using Intune for policy management.
For your cloud apps, look at using Azure AD for authentication and not something like ldap or the sorts. Basically, standardize using Azure AD for auth across all your access mediums, and stay away from traditional AD or using ADDS.
These recommendations might seem drastic and rather large effort, however if your company is running SBS still, it might be that you have a low enough amount of apps and infrastructure to take on a transformational change.
Related
Currently our DB works in customer's local network and we have client app on C# to consume data. Due to some business needs, we got order to start moving everything to Azure. DB will be moving to Azure SQL.
We had discussion about accessing DB. There are two points:
One guy said that we have to add one more layer between our app (that will be working outside Azure at end-user PCs) and SQL Azure. In other words he suggested adding API service that will be translated all requests to DB, i.e. app(on-premises) -> API service (on Azure)-> SQL Azure. This approach looks more reliable and secure, since we are hiding SQL Azure behind facade of API service and the app talks to our API service only. It looks more like a reverse proxy. Obviously, behind this API we can build more sophisticated structure of DBs.
Another guy suggested connecting directly to DB, i.e. app(on-premises) -> SQL Azure. So far we don't have any plans to change structure of DB or even increase count of DBs. He claims it more simple and we can secure our connection the same way. Having additional service that just re-translates our queries to DB and back looks like wasting time.In the future, if needed, we would add this API.
What would you select and recommend, and why ?
Few notes:
We are going to use Azure AD to authenticate users.
Our application will be moving to Azure too, but later (in 1-2 years), we have plans to create REST API and move to thin client instead of fat client we have right now.
Good performance is our goal, we don't want to add extra things that can decrease it, but security is our most important goal as well.
Certainly an intermediate layer is one way to go. There isn't enough detail to be sure, but I wonder why you don't try the second option. Usually some redevelopment is normal. But if you can get away without it, and you get sufficient performance then that's even better.
I hope this helps.
Thank you.
Guy
If your application is not just a prototype (it sounds like it is not), then I advise you to build the intermediate API. The primary reasons for this are:
Flexibility
Rolling out a new version of an API is simple: You have either only one deployment or you have something like Octopus Deploy that deploys to a few instances at the same time for you. Deploying client applications is usually much more involved: Creating installers, distributing them, making sure users install them, etc.
If you build the API, you will be able to make changes to the DB and hide these changes from the client applications by just modifying the API implementation, but keeping the API interfaces the same. Moving forward, this will simplify the tasks for your team considerably.
Security
As soon as you have different roles/permissions in your system, you will need to implement them with DB security features if you connect to the DB directly. This may work for simple cases, but even there it is a pain to manage.
With an API, you can implement authorization in the API using C#. Like this, you can build whatever you need and you're not restricted by the security features the DB offers.
Also, if you don't take extra care about this, you may end up exposing the DB credentials to the client app, which will be a major security flaw.
Conclusion
Build the intermediate API. Except you have strong reasons not to. As always with architecture considerations, I'm sure there are cases where the above points don't apply. Just make sure you understand all the implications if you decide to go the direct route.
I have an Azure Cloud Service published at Microsoft and it's draining all my credit!
Payment
Pay as you go
Service resource
Minimal resource, 1 SMALL web role and 1 SMALL worker role.
I knew Azure wasn't cheap, but this is just too much. Currently my monthly cost is just under 80 USD. The only person that use this service is me, noone else, and I barely use it. So the cost is just for the upkeep.
Is this normal?
70 bucks a month!?
How much does it cost for YOU?
What Microsoft support told me
I am afraid the Cloud Services has a fixed price, and I am not aware
how it could be lowered. Maybe you want to check on how the service
itself could be tweaked to get it working as per your needs. You may
want to go through the Community Forum for that.
Community = Stackoverflow, so here I am!
If I look at my Azure subscription page I can see that it's the:
CALCULATING HOURS - Europe, Western
That is taking all my hard earned money. My service also uses SQL, storage and cache but, if I understand it correctly, these are not the cause for my expensive bill.
Before I leave you to it I just want to say that I can't use a simple web app because of my requirements. I know web apps are super cheap, but in this case I must use a cloud service..
Thank you
Update
I found out I was using A1 (small) and not A0 (extra small). The instance type for a cloudservice can be set in the servicedefinition file.
It's sad that not even Microsoft themselves could inform me about this.
Web and worker roles are like dedicated VMs if they are on, they will cost you money.
You can do one of two things
1) Stop the machines when no one is using them ( say in the off business hours). I am not sure if this is possible to do or not in your case. But if it is possible, you can run a small script to start/ stop the roles. You can even do so via apps on your phone. For example - https://itunes.apple.com/us/app/azure-management/id826446897?mt=8
2) Move to Azure Web Apps and Azure Web Jobs - Both these services are "multi-tenant" and cost much less and in fact offer a free tier. If and when you need to scale, you can always scale as your need
Hope this helps
I am a newbie to web development
I would like to host my site in azure.
There are so many subscriptions plans.
So which subscription is reasonably good and give me price details of that?
Thanks in advance
Windows Azure has few types of hosting. For a website you might want to look at the following -
Web Sites - You can host right away without modification of your existing project.
Cloud Services - I used this, but it requires changes such as Caching.
Here is the calculator based on your need.
FYI: Rule of thumb is you need a least two instances in Production to minimize the downtime.
If you are a newbie , I would strongly suggest using azure websites for now, and you can always move to a custom solution using webroles/caching Etc later if you feel it doesn't cater all your needs..
Azure websites pricing can be obtained from here :
https://azure.microsoft.com/en-us/pricing/details/web-sites/
Again on what parameters would you choose the right package, you are the best judge for that since you know what traffic are you expecting and how much memory etc you need
We have got an application running fine on On premises and plan to move it to IaaS on Ms Azure, do we need to make any changes to it or will it work as is?
I agree with the above post. You have not detailed if you are using Virtual Machines (Sql server or going to use Azure SQL). You will have to make choices about fail-over and geo redundancy, cloud services, etc. There are IP restrictions that may affect you (I don't know since I am not sure what you are moving). More than anything, I always warn people about the cost, it is difficult to understand. Here is an article series I wrote on Azure & SharePoint, you can skip the SharePoint stuff but the cost/limitation/VMs and such would still apply.
http://www.matthewjbailey.com/sharepoint-azure-guide/
We've managed a lift-and-shift of an on-premise Windows app into Azure, but I wouldn't say it's been without its pain. The above comments definitely ring true; you need to provide a bit more of an overview of what the current application does so that people can help answer your question.
In my experience, the only stumbling blocks to moving on-premise into Azure are:
Hardware requirements; i.e. if your application requires some specific hardware
Cost: It's not always cheaper to move large systems into Azure
Licensing: Make sure that your existing licensing is compatible with a cloud system which you don't control
Windows Azure has a store.
The stuff you can by there are called Add-Ons, and they fall in two categories: Service and data.
I understand the point of some of the service offerings, but not all, and I don't yet understand the point of the data offerings at all.
With services, some offerings are database deployments such as ClearDB (MySQL) and MongoLab. That makes sense to me: You get those databases deployed and monitored with a few clicks, yet those databases run in the same data center as the applications that consume them, which is good for performance and security.
For most other services (there is a simple scheduler application, for example), it seems that the only advantage is the unified billing method. Is that a correct observation, or is there more to it?
Then the data offerings: The fact that I can buy bing query transactions cannot really have anything to do with the rest of my azure account, right? Technically, it's just bing (or whatever other data offering you look at) and presumably I'm going against the same bing api that I would have used previously (I'm assuming that was possible). There is nothing really deployed in any Azure data center the moment I buy it, is there? So in what sense is that an Add-On?
In a nutshell, am I missing something or are most Add-Ons just a method of buying external services and having the billed on my Azure account?
If you can answer the question for other 'app stores', you can answer it for Windows Azure. We know about THE App Store (as per the court battles over the name) which is the only way to get applications onto the closed (iOS) device. There is also a Mac App Store which would seem unnecessary because of the ability to install apps by yourself (which makes it more similar to the Azure store). In this case the reason for the store is discoverability, association with the store brand (where the buyer assumes a degree of vetting), a single point for updates, and simplified billing.
The Windows Azure Store (and data marketplace) exist for similar reasons. It is less about the technical benefits than the association with the Azure brand. Since SO is technical, let me highlight some (largely) technical aspects:
Don't assume that the service will run in the same data centre. In most cases it probably won't.
There is an advantage of having everything in one place from an operational point of view. Granting of operator access to the subscription means that you don't have to administer accounts on the service. I have had problems with this though - where the service made it difficult to do other things (such as get support) because the Azure identity wasn't handled very well. (I had this with New Relic).
The combined billing works on credit card payments only. Last time I checked (Summer 2013) there was no way to get an add-on with a pay-by-invoice subscription, so a second subscription (with credit card) was needed anyway.
Add-ons seems to still be in 'preview', which may indicate low adoption. Microsoft probably hasn't seen it grow the way they expected and may not be developing it much in future. This is opinion only, and shouldn't affect the service (after all the store is just a gateway, and has no (little) technical impact on the service provided)
Don't completely ignore the store however. The biggest benefit seems to be the free tier of the servers and reduced pricing, where Microsoft has managed to get service providers to make the store attractive. For example, the SendGrid free option provides 25,000 emails per month, and there doesn't seem to be a free option on SendGrid.com. New Relic pricing was (and maybe still is) significantly less.
Pay attention mainly to the pricing benefits, rather than perceived technical benefits.