It’s been a long time since my last post, I actually have a ton of materials to work on, but hardly found the time to settle down and share it in my blog.
Recently I’ve been involved in a demo run, proof of concept session, for a prospect involving end to end management of a software as a service (SaaS) solution, delivered from the public cloud. It has been a challenging task, indeed. In this first installment I will focus on the high level choices I made, I’m going to share my honest, unbiased notes from this journey. As such I can be badly wrong, I can have missed important alternatives or taken wrong assumptions, but in the end I can say this journey can be traveled with Microsoft technologies today.
In follow up posts I’m going to share the samples I used and the lesson learned, a warning once for all, we’re talking cloud technologies what’s true today can be different in a month. I plan to keep this a work-in-progress for some time, at least until all the involved technologies mature.
Returning to my challenge, the task was to deliver a complete cloud agnostic (target public clouds were Azure and AWS) solution from resource provisioning to application monitoring, including application deployment and patching, using current Microsoft Technologies.
Is it possible you may ask? The short answer is yes, but… you don’t have to expect a smooth and integrated user experience. We’re not there yet.
The prospect goal was using IaaS to deliver their solution, but everything is still valid with PaaS set of technologies if we choose not to be cloud agnostic. PaaS delivers tremendous savings and possibilities, but it definitely ties you to a specific cloud provider.
Technologies, why and where
Let’s be honest, right now the Microsoft story on management technologies is a little complicated. We have old school products like System Center, we have the new cloud architected products like Operations Management Suite (OMS), we have overlaps, we have missing pieces that can only be filled through third party solutions, we don’t have a end to end, consistent UX to achieve our goal. On the other end, we have a few strongholds:
- A common management and automation language (i.e. Powershell) broadly adopted even by Microsoft competitors
- A well established and integrated hybrid cloud experience
- A well established IT life cycle solution for the hybrid cloud (i.e. System Center) that can be enriched and complemented by cloud based technologies (OMS)
- A public cloud we can leverage for our management infrastructure needs
From all the considerations above I produced a simple mapping matrix between deliverables and technologies
|Deliverable||Main technology||Cloud Agnostic story||xPlatform (*)||Test scenarios|
(VMs, virtual networks, storage, web services, …)
|Azure Automation||Leveraging the powershell modules for the different clouds (Azure, AWS, Hyper-v / VMM, VMWare)||Yes||Azure: ARM templates
AWS: declarative model
|Platform provisioning (application server deployment)||Azure Automation||Powershell remoting and Powershell DSC||Yes||IIS deployment
SQL Server deployment
|Platform change (configuration, modules management)||Azure Automation||Powershell remoting and Powershell DSC||yes||IIS features management|
|Application provisioning (any packaging)||Azure Automation||Powershell remoting and Powershell DSC||Yes||WingtipToys deployment webdeploy package
|Application change (any)||Azure Automation||Powershell remoting and Powershell DSC||Yes||Webdeploy update
SQL custom import
|OS / Platform patching||Azure Automation / SCCM||Powershell remoting and Powershell DSC, xplat agents for SCCM||Yes||Security fix deployment|
|End to End monitoring||Operations Manager, Operation Insights||Ops Manager can monitor virtually anything, OpInsights adds analytics and efficient log collection||Yes||APM for .net and JEE
OpsMgr and OpInsights integration
Public Cloud monitoring (AWS, Azure)
(*) With xPlatform I simply state if the same technology / process can be applied to non Windows Operating Systems.
Every single choice can be debatable, so let’s see the rationale for every single deliverable. Just remember my focus was on Microsoft solutions and in particular my reference technologies were System center at large or if you want System Center and OMS.
It was clear to me this should have been the only part of the solution tied to cloud providers interfaces. I cannot think of a product that can expose the full capabilities of Azure, AWS, Virtual Machine Manager (VMM) and Hyper-v based clouds, VMware clouds using a common model. (btw If you know one just let me know). If you take into considerations those four technologies and think about a common denominator in terms of management interfaces then Powershell is probably the best abstraction we can have over their native APIs. Once agreed Powershell was the only common abstraction I could have used, the choice was limited between Azure Automation (AA) and System Center Orchestrator. There’s indeed a lot of overlap, but it seemed to me very clear I could leverage Azure Automation (AA) to provide a platform agnostic solution. Azure Automation is the cloud borne version of System Center Orchestrator, particularly the Service Management Automation (SMA) module. AA is part of OMS, it’s ready to use with no on-premises infrastructure needed, it leverages Powershell Workflow, it can work as a Powershell Desired State Configuration (Powershell DSC) pull server. As a plus, Azure Automation can have hybrid workers, or your own controlled Virtual Machines (they can run on every cloud solution) where the AA controlled workflows can be run. This proved handy when I had an issue with the AWS powershell module.
In terms of test scenarios I decided to use Azure Resource Manager (ARM) templates and a simple declarative model for AWS. I could have used CloudFormation for AWS (the ARM equivalent if you want on AWS), but I didn’t due to lack of time. I could have used as well the old Azure Service Management model, but since this was a green field deployment I focused on new technologies with a clear roadmap. I must say there have been moments when I regretted this decision. Don’t get me wrong, I believe ARM is the way to go, but it’s just not ready for prime time primarily due to lack of documentation and samples not always working as stated. I’m going to share the details in my next post.
At the end of the day, I had two different workflows in Azure Automation to provision the required resources on Azure and AWS respectively, the parameters were more or less the same and both were able to provision multiple Virtual Machines on a single virtual network, publishing the required management ports required for further automation in a secure and encrypted way.
Platform provisioning and management
Once the basic resources had been provisioned I wanted to have automations that can be run ubiquitous on any cloud. To do this I had to dump any cloud specific interface and work at the resource / VM level. We’re talking about IaaS platform provisioning and change management was very similar to application related activities (see next topic). Basically I had a couple of choices: System Center Configuration Manager and Powershell and better yet Powershell DSC. I tried to summarize the two approaches:
|Compliance drift reporting||Partially||Yes|
|Data Center designed||Partially||Yes|
|Needs infrastructure||Yes||No / limited|
As you can guess Powershell DSC orchestrated via Azure Automation had been my choice:
- I was already using that solution and I wanted to limit the different UIs at a minimum
- I wanted to keep the infrastructure overhead to a minimum, since this was a greenfield deployment
- ConfigMgr is more and more focused on end user devices I want be surprised if in the future it will be replaced inside the datacenter with something else
- The number of applications was limited, application were developed in house (SaaS prospect)
Choosing Powershell DSC and Azure Automation had the side effect of being able to use Azure Automation as a pull server, obviously the single VMs must be configured to refer to Azure Automation as pull server. I must add that pull servers are great to maintain a configuration, but partially due to the polling timing, partially due to the difficulties of managing partial configurations (not yet available on AA, see http://www.powershellmagazine.com/2014/10/02/partial-dsc-configurations-in-windows-management-framework-wmf-5-0/ for more info) I opted for a push methodology. As far as Powershell remoting is available we can do almost everything and Powershell remoting was enabled during the resource provisioning phase.
Azure has a very nice interface to prepare DSC packages (Publish-AzureVMDscConfiguration) and to push them to virtual machines (Set-AzureVMDscExtension), since I must remain cloud agnostic I couldn’t use the latter, but anyway leveraged the former to have a DSC packages repository in a secure https accessible storage on the cloud. I then emulated what the Set-AzureVMDscExtension does using Powershell remoting. This way, exactly the same Azure Automation workflow can be used to address VMs running on any cloud, as far as those VMs have access to the DSC package repository. I could have used other mechanisms but this one had many advantages:
- The same DSC configuration could be loaded inside Azure Automation DSC. So it was up to the prospect to decide which approach (pull, or push with partial configurations) use.
- I leveraged the secure packaging of Azure for DSC not reinventing the wheel in terms of ubiquitous and securely accessible repository on the cloud
Details and code samples can be found in Azure Automation and Powershell DSC related posts.
Powershell is available for *nix systems, too. Now I’m not advising to use Powerhsell on *nix, I’m sure there are many more consolidated technologies, but if you have a bunch of *nix system and have invested in Powershell I think it’s worth a look.
Application provisioning and management
The story for application provisioning and management is basically identical to the platform provisioning one. Again here we don’t have a single packaging technology and no Microsoft solution provides a general purpose packaging technology. We have windows installer packages, webdeploy packages, custom setup.exe solutions, in future we will have docker containers, and sure many more. Yes, is so much easier to deploy apps in Linux where basically we have to copy a bunch of files and editing a couple of text files, and where we can leverage RPM packages. Retrospectively it has not been a good idea to use the same packaging technologies on client and server systems, the needs are so different and windows installer on a server system is really overkilling (imo).
Given all this the choice was easy, use the same approach used for platform provisioning.
OS and platform patching
Patching, what a mess. With patching I’m referring to a process that given a catalog of patches and an approval list, scans for missing patches and applies them. These are the basics, in real world farms patching is much more complicated, it involves maintenance windows, application components dependencies, reporting, pre and post patching validation testing and so on. Now Microsoft story is really a shame:
- We have windows update for end user devices
- We have WSUS for small business, single node focused
- VMM, but just for the fabric and on a MS centric farm.
- Configuration Manager just for Microsoft products and a few partners (Adobe in primis, not useful inside a datacenter), still single node focused, even if we have reporting, we can implement pre and post checks with task sequences and so on
What I demoed was Configuration Manager, but what I advise is to develop your own solution using Powershell as my team did or try to find some sound solution on the market, I know of many but didn’t find anything that fits our needs. This is a huge gap Microsoft must fill, better sooner than later.
End to end monitoring
Honestly the easiest part of my POC was the monitoring one. It’s not because I have worked with Operations Manager so many years, but because it’s easy to monitor everything you need on every single cloud out there. If you add Operational Insights to the picture you have a rock solid solution today and a clear roadmap for an integrated modern monitoring solution. The only thing that’s still missing is an HTML5 console, you know I love SquaredUp solution, and this has been the only third party I used in my demo. I won’t spend much more time here, just remember you can find a Management Pack for AWS as well as Azure (both free) and that you can get Application performance monitoring (APM) for both .net and JEE applications.
Possible future scenarios
As a final advice to the prospect I added the need to explore platform services (I know losing part of the cloud agnostic approach) and the containers approach. Even if I believe they won’t be the panacea for all evils as it hadn’t be the server app-v thing, still worth a look in the Windows Server 2016 time frame. (I strongly suggest this reading http://azure.microsoft.com/en-us/blog/containers-docker-windows-and-trends/)
Is that all? No, not at all. For example data protection and disaster recovery were out of scope in my demo and so I didn’t touch them in this series of posts. Nevertheless using the above mix of technologies I’ve been able to demo an application farm deployment on both Azure and AWS, suing the same tool and mostly the same workflows, from scratch up to APM monitoring, including version upgrades and patching. And I could have achieved the same results on Hyper-v/VMM and VMWare. Is everything ready to go? Again, no. There’s a knowledge gap to fill and some development efforts on the ARM and powershell side, but frankly the same can be said for the other automation and managing platforms I know. Any suggestion welcomed J
Now that I set the scenario and the technologies, let’s see some practical examples of what I learned:
- Azure ARM lessons learned and more
- Deploying #Azure ARM templates with #Powershell
- Azure Automation what’s cool what’s not
- Powershell DSC samples
This posting is provided “AS IS” with no warranties, and confers no rights.