Day 2 has come to an end, and my brain feel packed to the rafters with new information and ideas. The Azure Stack track (or as Microsoft calls it the Platform Vision & Strategy track) has become the place to be, with every session filling up to capacity. Seriously, I tried going to the first session today about the Server Virtualization Overview, and I was turned away 10 minutes before the session even began. It really looks like Microsoft's Azure Stack landed in a big way, and people are taking notice. Below the break are my thoughts from day 2 at the Ignite conference.
As I said, I couldn't make it into the the first session of the day. And that was a common theme all day long. The Platform Vision & Strategy track is a monster, and it quickly became clear that if you didn't get there at least 15 minutes early, you weren't getting in the door. Once I was turned away, I attended the Azure IaaS Deep Dive session (https://channel9.msdn.com/Events/Ignite/2015/BRK3505) and I am glad I did! One of the questions swirling in my mind after the announcement of Azure Stack was how to get the extensive catalog of templates from the Azure portal down to the local datacenter. It seems like Azure has already done all the heavy lifting, and I should be able to leverage that set of templates and images on the local end. This breakout session showed me how to utilize the new Azure resource groups, and how to create json templates to deploy Azure services to the cloud using Azure Resource Manager. This is the same manager which will be used to deploy resources in the Azure Stack. By extension, the same templates developed for Azure in the cloud should also apply to Azure Stack. The session reviewed how the templates are constructed and that some basic and advanced templates are available for download from a Github repo. This is some truly powerful stuff for automation and repeatability. The final demo of the session showed the deployment of a full SharePoint instance to the cloud, with the ability to be scalable via a parameter file. I highly encourage you to watch the session. By using these templates, DSC, and third party tools like chef, you can now easily deploy applications in a consistent and repeatable manner across multiple environments both on premise and in the cloud. This is no vaporware, but a serious opportunity to realize the promise of DevOps.
That was just the first session of the day. From there I went on to attend three sessions based around the introduction of Exchange 2016. The central message from the sessions was this: Exchange 2016 will be the logical extension of Office 365 to your on-premise environment. All features for Exchange 2016 are being pioneered in Office 365 first, and then through a series of feedback loops, they are refined and incorporated into the on-premise product. This isn't exactly news, but as they ran through all the new features of Exchange 2016, I kept thinking how closely it mirrors my most recent experiences with Exchange Online. The introduction session was mostly marketing fluff, and honestly not really worth viewing. More important was the preferred architecture for Exchange 2016, that got into the nitty gritty of what the Exchange team wants to see deployed on-premise. Here are the highlights:
- Every server is an island
- All roles have been merged into the Mailbox role
- The server is the basic building block
- Upgrades from Exchange 2013 will be a breeze
- Upgrades from Exchange 2010 are basically the same as upgrading to Exchange 2013
- The Office Web Application Server is now a separate and required role for rich document editing in OWA
- EWS is no longer the focus for extensibility, the REST APIs are the future
- MAPI/CDO is dead
- RPC over HTTP is dead, move to MAPI over HTTP
- Exchange 2007 is not supported with Exchange 2016
- Passive search index can use passive database for up to 40% reduction in WAN traffic
- Server 2008 R2 domain-level, forest-level, and DCs are the minimum required
- Outlook 2010 is the minimum required
That's a short list and I plan to have a separate post all about Exchange 2016. The other important item is that Exchange 2013 and 2016 will now be supported to run in Azure. Just check out the website http://www.isexchangesupportedonazure.com/. There's several caveats and a lot of planning that goes into getting it working, but the essential part is that with the GA of Azure Premium Storage, VMs in Azure can now have the guaranteed IOPS and latency required by Exchange. It's mostly about the latency of storage, which Premium Storage more than takes care of. Based on that, you could now deploy Exchange in the cloud for several possible scenarios:
- Dev/Test environment
- Second datacenter site if you don't have one
- DAG file share witness in the cloud
- Hybrid components for long term coexistence
- All-in with all Exchange components in Azure
Those are some powerful options, and for the moment Azure is the only supported IaaS platform. The session leader Jeff Mealiffe laid out what an IaaS provider needs to have to be supported for Exchange. With those items in mind, it's entirely possible that other vendors might meet the requirements as well.
My final session of the day was for ExpressRoute in Office 365. Mike Cessna has already covered that in detail
here, so I won't rehash the sessions. My main takeaway was that ExpressRoute will be highly recommended, if not required for many hybrid scenarios including running Exchange in Azure.
Once the week of Ignite is done, I am definitely going to need to circle back and post about Exchange 2016 and Azure Stack. For the meantime, you should check out these
sessions on Exchange and
these on Azure Stack.
Labels: Azure Stack, Exchange 2016, IaaS, Microsoft Ignite