With the release of Infrastructure as a Service (IaaS) this summer there seems to suddenly be an increased interest for IT Pros in Windows Azure. Originally most of Azure’s features, like Web and worker roles, were focused primarily upon developers. This accidentally led to Windows Azure being erroneously viewed by the IT Pro community as a chance for developers to bleed over into the roles of the IT Pro.  It has also been viewed unfairly as a driver behind their jobs eventually going away. After all – if the Cloud handles all the deployment, installation, and patching of the core software, and provisioning of the hardware, what roles still exists for IT Pros in that environment?

Once you get a better understanding of the types of opportunities that are created by the Cloud you can see that the theory of an obsolete IT Pro replaced by Windows Azure is not very realistic. For the IT Pro Azure VMs and Azure Web sites with the introduction of IaaS, Windows Azure is now also an ITPro platform. As an IT Pro it might help to think of Azure as an extension of your IT department.

Over the next few posts I will be discussing concise Windows Azure tips and best practices for IT Pros.  Let’s start with our first topic – Deployment.

Deployment

  • With Windows Azure, developers can go right to Azure and deploy their applications.  For your on-premise server you would not allow developers to do direct deployment to production. IT Pros need to take this control back! To manage deployment and keep developers from directly deploying from Visual Studio (they can also deploy with configuration files) create two Azure accounts – one account for development and one for production. Give them the development account to work with and do what they want. However, when they have to deploy to production they need to go through your account and you do it for them.
  • When you deploy try to keep the Azure storage and code on the same location.  You can create and use affinity groups to help with that. So if you have a market in the Far East you can easily deploy it all into the Far East.  This is an advantage for deployment you get with the cloud.  You cannot change a data center but you can choose a region of the world. The affinity group guarantees a hosted service and storage will be in the same datacenter. Group application pieces into a single deployment package when they must be hosted in the same data center.    Note – you cannot use affinity groups with Windows Azure SQL Database.

Management Certificates

Closely related to the topic of deployment is the management of certificates in the Azure portal.  Each subscription should have its own separate Azure service management certificate which is unique to that subscription.   To use a management or service certificates it must be uploaded through the Windows Azure Platform Management Portal.  Windows Azure uses both management certificates and service certificates.

  • Management Certificates – Stored at the subscription level, these certificates are used to enable Windows Azure using the ‘management’ tools:  SDK tools, the Windows Azure Tools for Visual Studio, or REST API calls.  These certificates are independent of any hosted service or deployment.
  • Service Certificates – Stored at the hosted service level, these certificates are used by your deployed services.

Typical IT policies define distinct roles for parties associated with application Development, Test, Integration, Deployment, and Production. These policies restrict roles from operations that exceed their defined responsibilities. Here are some suggestions on how to manage certificates for these roles.

Development – Share a certificate between all the developers to allow freedom of development.

Integration – Have its’ own management certificate

Test – Certificate shared only with the Operations team

Deployment – Used for deployment roles and only distributed to parties responsible for application deployment

Production – Certificate shared only with the Operations team

About these ads