When I talk to customers and colleagues about cloud offerings, most of them are still concerned about the cloud, and especially about the security of public cloud offerings. One of the most mentioned concerns is based on the belief, that each and every cloud-based VM is publicly reachable over the internet. This can be so, but it does not have to. It relies on your design. Maybe that is only a problem in germany. German privacy policies are the reason for the two german Azure datacenters. They are run by Deutsche Telekom, not by Microsoft.
Okay, the headline of this blog post is a bit provocative. This blog post is not written from the vendor perspective. It’s the perspective of someone, who’s sitting between the vendor and the customer. A value-added reseller (VAR) is typically located between vendor and customer. And the business model of a VAR is typically based on selling hardware, software and service.
The typical customer doesn’t have the time, money and the know-how to transform business requirements into a bill of materials (BOM). It’s a “make-or-buy” decision. And “buy” is often better than “make”. The customer needs a partner who helps him to transform the business requirements into a solution and a BOM.
Before you can manage Azure services with Azure Automation, you need to authenticate the Automation account against a subscription. This authentication process is part of each runbook. There are two different ways to authenticate against an Azure subscription:
- Active Directory user
If you want to use an Active Directory account, you have to create a credential asset in the Automation account and provide username and password for that Active Directory account. You can retrieve the credentials using the Get-AzureAutomationCredential cmdlet. This cmdlet returns a System.Management.Automation.PSCredential object, which can be used with Add-AzureAccount to connect to a subscription. If you want to use a certificate, you need four assets in the Automation account: A certificate and variables with the certificate name, the subscription ID and the subscription name. The values of these assets can be retrieved with Get-AutomationVariable and Get-AutomationCertificate.
Automation is essential to reduce friction and to streamline operational processes. It’s indispensable when it comes to the automation of manual, error-prone and frequently repeated tasks in a cloud or enterprise environment. Automation is the key to IT industrialization. Azure Automation is used to automate operational processes withing Microsoft Azure.
The very first thing you have to create is an Automation account. You can have multiple Automation accounts per subscription. An Automation account allows you so separate automation resources from other Automation accounts. Automation resources are runbooks and assets (credentials, certificates, connection strings, variables, scheudles etc.). So each Automation account has its own set of runbooks and assets. This is perfect to separate production from development. An Automation account is associated with an Azure region, but the Automation account can manage Azure services in all regions.
Building networks in the cloud is sometimes hard to understand. A common mistake is to believe that all VMs can talk to another, regardless of the owner, and that all VMs are available over the internet.
Some basics about Cloud Service Endpoints and Virtual Networks
When we talk about Microsoft Azure, a Cloud Service Endpoint is the easiest way to access one or multiple VMs. A Cloud Service contains resources, like VMs, and it’s acting as a communication and security boundary. All VMs that use the same Cloud Service get their IPs via DHCP and share the same private IP address range. The VMs can communicate directly to each other. To access these VMs over the internet, a Cloud Service Endpoint is used. Each Cloud Service has a internet addressable virtual IP address assigned. And that’s the Cloud Service Endpoint. With PAT, ports for RDP or PowerShell are forwarded to the VMs by default. If you deploy a webserver and an application server, both can be provisioned to the same Cloud Service and therefore, they share the same Cloud Service Endpoint. But you can only forward http traffic to the webserver. Therefore only the webserver is available over the internet, not the application server.
VMware vCloud Hybrid Service (vCHS) stands in one line with Amazon Web Services, Microsoft Azure, Rackspace Cloud or other cloud offerings. I don’t want to compare the different provider with vCHS. To be honest: This article is more a summary for myself, than really new content. I just want to summarize information about the IaaS offering of VMware. If you want a comparison of vCHS and AWS, I recommend to read this article written by Alex Mattson (AHEAD).
Introducing VMware vCloud Hybrid Service (vCHS)