Active Directory and BizTalk in the Cloud?

A colleague pointed me to an interesting blog post – Two products Microsoft should set free into Cloud, which ended with this question:

So Microsoft – here is a market that is begging to be served and yours to lose. While you still have work to do to make your to Azure Platform, Business Applications, Office Suite widely adopted in Cloud, BizTalk and Active Directory are the need of the hour and are ready to go. So waste no more time – let them free and watch them soar in Cloud.

Now, if cloud computing is simply outsourced hosting, then Microsoft could just start selling Active Directory and BizTalk as a SaaS offering today. But I tend to think that cloud computing represents a new paradigm (basically, more distributed computing than utility computing), and more value can be gained by leveraging cloud as a new paradigm.

Below is the rather lengthy comment I left on that blog.

Active Directory and BizTalk not being part of the Microsoft cloud platform today (either in SaaS or PaaS model) doesn’t mean Microsoft doesn’t want to “set them free into cloud”. In fact, our long-term roadmap has been to make all of our software products and platforms available in the cloud in some form.

So then why haven’t we? Shouldn’t it be pretty simple to deploy instances of Active Directory and BizTalk in Microsoft data centers and let customers use them, a-la-SaaS-style? The answer lies in the fundamental question – is cloud computing simply server hosting in other people’s data centers, or is it a new paradigm we can leverage to do things differently?

Microsoft’s approach to cloud computing is exactly that – provide the right solutions for cloud computing to effectively support the new paradigm. For example, as today you can see that in Microsoft’s SaaS offerings, there are both single-tenant and multi-tenant versions of Exchange, SharePoint, Office Communications Online suites; and in the PaaS offerings, SQL Azure is a fully multi-tenant relational database service and not simply hosted SQL Server, and Windows Azure’s native roles are provided via a higher abstraction, container-like model, and not simply hosted Windows Server.

So then the question is, what’s the right cloud model for Active Directory? That is still under consideration, but my personal opinion is that we still need to carefully evaluate a couple of factors:

• Do customers really want to outsource their identity management solution? Is there really a lot of demand for hosted enterprise identity management services?
• What are the true benefits of hosting the identity management solution elsewhere? Just some cost savings from managing your own servers? That might be the case for smaller companies but larger organizations prefer the private cloud approach
• For example, the identity management solution is essential in managing access control across an IT architecture. Wouldn’t it work better if it’s maintained closer, in terms of proximity, to the assets it’s intended to manage? Keep in mind that most “pure cloud” vendors who advocate otherwise, use their own identity management infrastructure hosted in their own data centers
• And from an external, hybrid cloud, and B2B integration perspective, identity federation works pretty well to enable single sign-on across resources deployed in separate data centers and security domains
• Lastly, what’s the right model for cloud-based identity management solution? Is it making the online identity metasystem more “enterprise-like”, such as adding some of the fine-grained management capabilities to the Live ID infrastructure, or developing a multi-tenant version of Active Directory that can better address some of the consumer identity scenarios?

Similarly for BizTalk, many of the above points apply as well for its cloud aspirations, plus a few specific ones (again just my personal opinion):

• Process and data integration between organizations (such as traditional B2B scenarios) and different cloud-based services operated by separate organizations, is a lot different from traditional enterprise integration scenarios where enterprise service bus type of solutions fit in today. It has a lot more to do with service management, tracking, and orchestration in an increasingly more service-oriented manner; as opposed to having system and application-specific adapters to enable communication
• Also, EAI and ESB type of integration places the center of gravity in terms of context and entity definition within one enterprise. Cloud-based integration, such as outsourced process management, multi-enterprise integration, etc.; shifts the center of gravity into the cloud and in a much more shared/federated manner
• Question then is, what is the right type of integration-as-a-service solution that would work well for cloud-based integration scenarios? We have many integration hub service offerings today, many grew from their EDI/VAN, managed FTP, B2B, supply chain management, e-commerce, and RosettaNet, ebXML, HL7 roots. The landscape for external integration is vastly more diverse and generic (in each vertical) than any one organization’s way of managing processes
• Some initial direction can be observed in Windows Azure AppFabric today, with the Service Bus offering. It works as an Internet service bus to help facilitate communication regardless of network topologies. It advocates a federated application model in a distributed environment, where processes and data are integrated in a service-oriented manner. It’s a much more dynamic environment (changes are more frequent and preferred) than a more static environment in an on-premise systems integration scenario
• Thus is it correct to simply have BizTalk hosted and sell it as a cloud-based integration solution? Will an on-premise systems integration approach effectively handle integration scenarios in a more dynamic environment?

Pure cloud pundits often ask “why not cloud?” But I think it’s also fair to counter that question with “why?” Not all IT functions and workloads are ideally suited for external deployment. A prudent architect should carefully consider what are the right things to move into the cloud, and what are the right things to still keep on-premise, instead of doing external cloud deployment just for the sake of doing so. There’s a big difference between “can” and “should”.

One way of looking at finding the right balance between what should move into the cloud, is where the users are. Applications that are consumed by users on the Web, are excellent candidates to move into public clouds. Internal business applications that support a back-office operation, often are still better maintained on-premise; closer to an organization’s workforce. It’s also a nice general approach of balancing trade-offs between security and control, scalability and availability.

Thus eventually Microsoft will have some form of enterprise-level identity management solution, and multi-enterprise integration solution, available as cloud-based services. But these don’t necessarily have to be hosted Active Directory and BizTalk Server as we know them today. :)

Comments

• Anonymous
  June 30, 2010
  David, On behalf of other architects, thank you for saying what we are thinking with respect to being a prudent architect and that one should think before leaping into something unknown. Regards, -Rob

• Anonymous
  June 30, 2010
  For myself, I wouldn't necessarily want to buy hosted AD. However, I have a large number of customers with their own domains or workgroups that I manage. They also access my services. These security islands are hard to manage, and they can make some hosted services tricky. If I could host a cloud based AD forest, I could tie all of these seperate domains into together. Then I could easily manage all of them as a single entity, rather than having to maintain numerous different sets of credentials.

• Anonymous
  July 01, 2010
  Hosted BizTalk is not the answer. But neither is Azure minus any integration functionality. Users often need adapters to connect to Cloud and on-premise Apps and translation to convert data that moves between all that. Today's Azure reponse -- connect to BizTalk somewhere on-premise and use that to deal with heterogeneous connectivity -- falls pretty short of the mark. Let me know when you incorporate some integration as a service features in Azure. :)

• bjl

• Anonymous
  July 01, 2010
  @Devin – thanks for visiting! One thought – managing the domains and managing access control across those domains can be considered as separate responsibilities. From the access control perspective, identity federation works pretty well to integrate the separate identity domains and facilitate access across them without having to replicate or centralize identity domains into a single unity. And that’s exactly the model Windows Azure AppFabric Access Control is designed to support, plus a roles and privileges mapping and claims mapping facility. Personally I prefer the distributed and federated identity domains approach for the “secure by default” enterprise environments as it provides more control over exactly how each organization wants to manage its own identities. On the other hand, a centralized identity management approach works pretty well for consumer environments as online identity metasystems, such as Live ID, provide more ease-of-use for those scenarios. Of course, a distributed/federated identity domains approach makes managing them more challenging, especially in your case. Though I tend to think the solution to that lies on the management process side of things and can leverage separate strategies there. Just my thoughts. :) Best! -David

• Anonymous
  July 01, 2010
  @Benoit Lheureux – also thanks for visiting and sharing your thoughts! :) Personally I tend to prefer looking at (public) cloud computing as a paradigm or model that is different from on-premise computing (or simply utility hosting in public clouds). From that perspective, integration in the cloud should be facilitated in a service-oriented manner, and native interfaces with heterogeneous connectivity should be service-enabled locally (regardless where those systems and applications are deployed) with the use of appropriate adapters. In addition, I also think that outsourced process management, multi-enterprise integration, data transformation, etc. are the higher-level information integration scenarios that are more appropriate for cloud computing, than the lower-level systems integration scenarios. In that model, Windows Azure AppFabric Service Bus, as an Internet service bus (ISB), can be leveraged to build a distributed and federated application environment, where applications deployed across the Internet (whether on-premise or in other public clouds) can be integrated in a service-oriented ecosystem. And since AppFabric Service Bus also supports port forwarding scenarios, a particular software or systems vendor can technically “forward” (securely of course) communication from on-premise deployments of their software or systems to a cloud-based adapter service via AppFabric Service Bus, which then can convert the native interfaces into more interoperable forms. And this proprietary cloud-based adapter service can also participate as one of the available applications in the federated environment. Consequently, in a federated application model, Microsoft doesn’t necessarily have to be the one developing and managing those adapter services. This view may be a bit idealistic, but from a computing model perspective, crowd-sourcing a federated integration-as-a-service should be more comprehensive and valuable than any one organization. Just my thoughts. :) Best! -David