We are a small company and are still unsure how to start all this azure stuff.
Ok, we are clear on the technicalities like table storage and queues and all the that stuff, what we don't know about at all is how to set up the organization around developing for our developers. Which/how many azure accounts, shared or individual ones.
So far we've done classic windows development, so everyone has his environment, unit tests run either locally or on the build server (after pushing to mercurial or git), deployment from the build server.
The thing is that we want to use Azure not just as a hoster, but the full set, like blob/document/table storage, event hubs, storage queues, ReliableActors and everything. Things we can't do locally.
What's the appropriate way for azure then? There are about 20 to 30 developers and most have the enterprise msdn subscription.
What is a "company or organisation" account for? Should developers have their own accounts? Does DevOps need their passwords for all the bamboo or jenkins build stuff?
I went through this recently and I can share a few tips here since I'm also not aware of a DevOps specific platform to share this on StackExhange.
As far as organizing your subscriptions go look at Azure Pay-As-You-Go Dev/Test Subscriptions link
or Enterprise Dev/Test link if you are an Enterprise Agreement customer. These are aimed at development teams, you get discounted rates since you don't pay for software licenses that are already included in your MSDN subscription.
It is best to use individual developer subscriptions for exploration, POC etc while running your main dev workload in the Dev-Test subscription. It looks tempting to try and save a buck by spreading the work across multiple MSDN subscriptions to use the credits but I wouldn't recommend it. It becomes a pain to manage 20~30 subscriptions and they can run out of credits and things stop working. If you remove the spending limit on all the subscriptions you run the risk of racking up a huge bill accidently if multiple devs leave VMs on or add premium storage to VMs etc.
As far as DevOps go, use RBAC and Azure Active Directory to manage access and certificates for your DevOps tooling, build servers, release management etc don't use individual developer credentials for this.
And I agree with the other comments, get in touch with MS as well, this is just the tip of the iceberg but it will get you started.
Related
I'm doing some research to migrate virtual machines(vmware) to the new Azure Resource Manager portal.
I already succeeded doing this with powershell. But I was wondering if there where other methods to do this faster and more efficient with less downtime?
There is the Azure Site Recovery:
https://azure.microsoft.com/en-us/blog/azure-site-recovery-ga-move-vmware-aws-hyper-v-and-physical-servers-to-azure/
"Customers can replicate on-premises workloads to Azure with Azure Site Recovery for 31 days at no charge, effectively making migration to Azure free."
I do enjoy the cunning of #alexandr's solution! However the official solution from Microsoft is that they are currently building the tools to automate this for you.
from the Transitioning to the Resource Manager model blog. There are a basic set of scripts and a timeline for the more complex migrations (no VNet etc)
To directly answer your question, it seems like Powershell is the tool of choice for managing the migration. (I imagine if you leave it for long enough there will be a 'migrate' button in the portal, as they seem very eager to move everyone away from ASM)
We will be hosting TFS in a private cloud on VM(s). Are there technical differences to hosting TFS on Azure or AWS, or is it only a matter of pricing and which cloud a team prefers and has past knowledge of? I also think we won't go the Visual Studio Online route.
At InCycle, we have a full TFS 2015 installation hosted in Azure spread across something like 6-8 VMs. You'll need to take into account the standard considerations (virtual machine sizing and performance), especially on the data tier, which should have plenty of fast disks and lots of CPU and RAM.
You'll also need to consider Active Directory sync and how you'll get access to things like build drops on-premise from Azure.
Honestly, VSO will almost certainly be a lot cheaper for you, and you won't have to worry about the infrastructure requirements or upgrading TFS on a regular basis.
The ALM rangers have excellent guidance on this, as well: http://blogs.msdn.com/b/bharry/archive/2014/06/06/team-foundation-server-on-azure-iaas-guidance.aspx
We're completely upgrading our production and development environment from co-located boxes to an Azure implementation and we'll be developing using Visual Studio Online. Up until this point our dev has occurred on a Remote Desktop environment where developers were logging into Windows server and developing on that RDP box.
We want to set this up and we have some confusion about the Account types/set up types.
It appears there are two ways to set up our Azure and two ways to set up our developers. We are a MS partner w/ some MSDN licenses and Azure credits.
So for Azure we can use our existing MS accounts and just set up an Azure Pay As You Go (PAYG) subscription. This was suggested to us initially but it seems weird to have the entire companies Azure environment going through an individuals live ID. Then we saw we can sign up as an Organization now and it uses Azure AD. We have not been using Active Directory and we're not sure how much complexity this is going to add to our administration. Is there a discernible difference/benefit to going one way or the other?
Then, when we sign up our developers we can either have everyone sign up with their live ID's (we have MSDN w/ VS Premium credits for all developers) or we can set them up using Active Directory with Work Accounts. Having our credits allotted in work accounts sounds like a good way to control things at first reading, but it also seems a bit more complex. I'm wondering if there is much difference between MSDN accounts signed up w/ live IDs or AD Work Accounts. I can't find a real comparison article or pro/con type of discussion anywhere.
It sounds like you have already figured out the main differences. As an organization, I would suggest signing up for Azure as an organization. You can do that here. This is going to give you the management capabilities for resources typically needed by an organization.
Your developers can continue to use the MSDN subscriptions. As Dylan commented, these are not to be used for production environments. You should consider using these for Dev/Test environments and activating your MSDN benefits. This will save you some money. More on that here.
Visual Studio Online will work with your Work Accounts and again give you more control over managing your online resources. This link describes the sign-up process for both Microsoft Accounts and Work Accounts. And if you scroll down a bit you will find your original question specifically addressed.
Finally, you can also add your Work Account(s) to your existing MSDN subscriptions if you like. This way you (and your developers) can use the same account credentials when accessing Azure Subscriptions. Information on how to do that is available in this link.
Your Work Account subscription should be limited to personnel responsible for managing your "production" environment.
After signing up for Azure as an Organization, you can add users to the directory as described here. You can also add "external" users using their existing Microsoft Accounts. It's just a few dialogs to add a user.
My company process sensitive data and needs to restrict access to production environment. How do I organize subscriptons and (storage) accounts so that I have separate environments?
I could have completely distinct subscriptions but I want to give some devs the power to deploy on production while others should only have access to development assets.
In my ideal world, I'd add individuals to security groups. Whenever a thw dev wants to deploy on production, he/she would use his/her credentials plus an extra confirmation step, like an otp. This way I'd avoid mistakes but still keep simple users management. Is that possible in azure?
Eventually what you are wanting to do will be possible, and is possible to some degree depending on the resource. As more of the features of Azure make it into the preview portal (portal.azure.com) they are showing up with Role Based Access Controls, which is what you are looking for. Unfortunately, right now not all of the resources are there and some are there without full RBAC baked in (such as storage accounts).
For now, the best bet is to still separate by subscription. If you need developers to have the ability to perform a deployment you can create a script that performs the deployment (using stored PowerShell credentials or secured management certs) and then give the developers the ability to execute the script.
We started using Azure platform. Especially we are having issues in Web Sites platform. How we give different kinds of access to our development team.
Right now the development team could access the production deployment slots.
We need to be able specify the access to the system according to their roles in the organization.
Have your development team use their own subscription for development. That way, they never have access to your production environment. This is something I personally practice and recommend to customers.
This gives you the added benefit of also separating development and QA costs with your production deployment costs. In development, you may choose to use smaller and fewer instances (to control costs). Yet, in production, you may prefer larger and more instances (to meet demand). Having a separate subscription for each enables these options for you.
This is also an approach demonstrated in the Patterns and Practices Guide. It's a little dated and is in the context of Cloud Services (not Websites). But, the overarching principles still apply.
Microsoft has Role-Based Access Control in the roadmap for the new Azure portal but have not committed to any target dates.
If you're using Azure AD to manage Azure access there are some different roles available there.
Edit: Basic RBAC functionality was added to the new Azure Portal back in September.