Architecture + Strategy

Musings from David Chou - Architect, Microsoft

  • Architecture + Strategy

    Cloud Computing and the Microsoft Platform


    It has been a couple of months since I wrote about cloud computing and Microsoft’s plans and strategies. Now that Azure Services Platform has been unveiled at PDC2008, and after having the opportunities to discuss it with a community of architects from major enterprises and startups via the Architect Council series of events, I can talk about cloud computing from the perspective of the Microsoft platform, and the architectural considerations that influenced its design and direction.


    Okay – cloud computing today is a really overloaded term, much more than SOA (service-oriented architecture) when it was the hottest ticket in IT. There are a lot of different perspectives on cloud computing, adding to the confusion and the hype. And unsurprisingly, there are a lot of confusion around Microsoft’s cloud platform too. So here is one way of looking at it.

    Microsoft’s cloud includes SaaS (Software-as-a-Service) offerings as shown in the top row of the above diagram, such as Windows Live and the Business Productivity Online Suite; and the PaaS (Platform-as-a-Service) offering currently branded as the Azure Services Platform. For the rest of this article we will focus on the Azure Services Platform, as it represents a platform on top of which additional capabilities can be developed, deployed, and managed.

    Comprehensive Software + Services Platform

    At Microsoft, we believe that the advent of cloud computing does not necessitate that existing (or legacy) IT assets be moved into the cloud, as it makes more sense to extend to the cloud as opposed to migrate to the cloud. We think that eventually, a hybrid world of on-premise software and cloud-based services will be the majority norm, although the balancing point between the two extremes may vary greatly among organizations of all types and sizes. As a platform company, Microsoft’s intention is to provide a platform that can support the wide range of scenarios in that hybrid world, spanning the spectrum of choices between on-premises software and cloud-based services.

    Thus Microsoft’s cloud platform, from this perspective, is not intended to replace the existing on-premises software products such as our suite of Windows Server products, but rather, completes the spectrum of choices and the capabilities required for a Software + Services model.

    Cloud Platform as a Next-Generation Internet-Scaled Application Environment

    So what is a cloud platform? It should provide an elastic compute environment that offers auto-scalability (small to massive), and ~100% availability. However, while some think that the compute environment means a server VM (virtual machine) allocation/provisioning facility that provides servers (i.e., Windows Servers, Linux Servers, Unix Servers, etc.) for administrators to deploy applications into, Microsoft’s approach with the Azure Services Platform is remarkably different.

    Azure Services Platform is intended to be a platform to support a “new class of applications” – cloud applications.

    On the other hand, the Azure Services Platform is not a different location to host our existing database-driven applications such as traditional ASP.NET web apps or third-party packaged applications deployed on Windows Server. Cloud applications are a different breed of applications. Now, the long-term roadmap does include capabilities to support Windows-Server-whichever-way-we-want-it, but I think the most interesting/innovative part is allowing us to architect and build cloud applications.

    To clarify, let us take a quick look at the range of options from an infrastructure perspective.

    The diagram above provides a simplified/generalized view of choices we have from a hosting perspective:

    • On-premises: represents the traditional model of purchasing/licensing and acquiring software, install them, and manage them in our own data centers
    • Hosted: represents the co-location or managed outsourced hosting services. For example, GoGrid, Amazon EC2, etc.
    • Cloud: represents cloud fabric that provides higher-level application containers and services. For example, Google App Engine, Amazon S3/SimpleDB/SQS, etc.

    From this perspective, “Hosted” represents services that provide servers-at-my-will, but we will interact with the server instances directly, and manage them at the server level so we can configure them to meet our requirements, and install/deploy applications and software just as we have done with existing on-premises software assets. These service providers manage the underlying infrastructure so we only have to worry about our servers, but not the engineering and management efforts required to achieve auto-scale and constant availability.

    “Cloud” moves the concerns even higher up the stack, where application teams only need to focus on managing the applications and specifying to the environment their security and management policies, and the cloud infrastructure will take care of everything else. These service providers manage the application runtimes, so we can focus on deploying and managing business capabilities, as well as higher-level and differentiating aspects such as user experience, information architecture, social communities, branding, etc.

    However, this does not mean that any one of these application deployment/hosting models is inherently better than the other. Yep, while most people look at “hosted” and “cloud” models as described here, both as cloud platforms, they are not necessarily more relevant than the on-premises model for all scenarios. These options all present varying trade-offs that we as architects need to understand, in order to make prudent choices when evaluating how to adopt or adapt to the cloud.

    Trade-Offs in the Cloud

    Let us take a closer look at the trade-offs between the on-premises model and the cloud (as differences between “hosted” and “cloud” models are comparatively less).

    At the highest level, we are looking at trade-offs between data consistency and scalability/availability. This is a fundamental difference between on-premises and cloud-based architectures, as “traditional” on-premises system architectures are optimized to provide near-real-time data consistency (sometimes at the cost of scalability and availability), whereas cloud-based architectures are optimized to provide scalability and availability (by compromising data consistency).

    One way to look at this, for example, is how we used to design and build systems using on-premises technologies. We used pessimistic locking, optimistic locking, two-phase commit, etc., methods to ensure proper handling of updates to a database via multiple threads. And this focus on ensuring the accuracy and integrity of the data was deemed one of the most important aspects in modern IT architectures. However, data consistency is achieved by compromising concurrency. For example, in DBMS design, the lowest transaction isolation level “serializable” means all transactions occur in a serial manner (in a way, single-threaded) which promises safe updates from multiple clients. But that adversely impacts performance and scalability in highly concurrent systems. Raising the isolation level helps to improve concurrency, but the database loses some control over data integrity.

    Furthermore, as we look at many of the Internet-scale applications, such as Amazon S3/SimpleDB, Google BigTable, and the open source Hadoop; their designs and approaches are very different from traditional on-premises RDBMS software. Their primary goal is to provide scalable and performant databases for extremely large data sets (lots of nodes and petabytes of data), which resulted in trading off some aspects of data integrity and required users to accommodate data that is “eventually consistent”.

    Amazon Web Services CTO, Werner Vogels, has recently updated his thoughts on “eventual consistency” in highly distributed and massively scaled architectures. An excellent read for more details behind the fundamental principles that contribute to this trade-off between the two models.

    Thus, on-premises and cloud-based architectures are optimized for different things. And that means on-premises platform are still relevant, for specific purposes, just as cloud-based architectures. We just need to understand the trade-offs so each can be used effectively for the right reasons.

    For example, an online retailer’s product catalog and storefront applications, which are published/shareable data that need absolute availability, are prime candidates to be built as cloud applications. However, once a shopping cart goes into checkout, then that process can be brought back into the on-premise architecture integrated with systems that handle order processing and fulfillment, billing, inventory control, account management, etc., which demand data accuracy and integrity.

    The Microsoft Platform

    I hope it’s kind of clear why Microsoft took this direction in building out the Azure Services Platform. For example, the underlying technologies used to implement Azure include Windows Server 2008, but Microsoft decided to call the compute capability Windows Azure, because it represents application containers that operate at a higher level in the stack, instead of Windows Server VM instances for us to use directly. In fact, it actually required more engineering effort this way, but the end result is a platform that provides extreme scalability and availability, the transparency of highly distributed and replicated processes and data, while hiding the complexities of the systems automation and management operations on top of a network of globally distributed data centers. This should help clarify, at a high level, as to how Azure can be used to extend existing/legacy on-premise assets, instead of being just another outsourced managed hosting location.

    Of course, this is only what this initial version of the platform looks like. From a long-term perspective, Microsoft does plan to increase parity between the on-premise and cloud-based platform components, especially from a development and programming model perspective, so that the applications can be more portable across the S+S spectrum. But the fundamental differences will still exist, which will help to articulate the distinct values provided by different parts of the platform.

    Thus the Azure Services Platform is intended for a “new class of applications”. Different from the traditional on-premise database-driven applications, the new class of “cloud applications” are increasingly more “services-driven”, as applications operate in a service-oriented environment, where data can be managed and provisioned as services by cloud-based database service providers such as Amazon S3/SimpleDB, Google MapReduce/BigTable, Azure SQL Services, Windows Azure Storage Services, etc., and capabilities integrated from other services running in the Web, provisioned by various private and public clouds. This type of applications inherently operate on an Internet scale, and are designed with a different set of fundamentals such as eventual consistency, idempotent processes, federated identity, services-based functional partitioning and composition (loose-coupling), isolation, parallel and replicated data and process architecture, etc.

    This post is part of a series of articles on cloud computing and related concepts.

  • Architecture + Strategy

    Describing Cloud Computing


    Cloud computing, the buzzword du jour and hottest cliche in IT at the moment, is a source for extensive debates as well as general confusion. Just like the other buzzwords, SOA, Web 2.0, Software-as-a-Service (SaaS), "cloud computing" is a very general term, and there are many interpretations of what it means.

    And just like those buzzwords, cloud computing represents the convergence of many other megatrends and evolutionary developments leading up to this point. For example, SOA, Web as a platform, SaaS, utility computing, grid architectures, on-demand computing, outsourced hosting, managed/application service providers, etc., can all be considered contributing components to cloud computing.

    This slide from Gartner has a nice list of some common misunderstandings of cloud computing.

    So what is cloud computing then? Taking a similar approach to my last year's post on Web as a platform, a formal definition of cloud computing won't be attempted here. Instead, we will try to describe the emerging phenomenon by looking at the components and contributing aspects and patterns, as well as some of the current issues and challenges.

    Fundamental Aspects of Cloud Computing

    Again, this is just one way of looking at cloud computing, among many others. Basically, a couple of fundamental aspects I think are relevant:

    • Service Delivery
    • Service Composition
    • Service Consumption
    • Economies of Scale
    • Network Effect
    • Ubiquity / Pervasiveness

    Service Delivery

    The cloud has become an alternative means of delivering various types of capabilities as services. Software-as-a-service (SaaS) is one that receives a lot of attention, but from a cloud computing perspective, it can be any type of technology-enabled capabilities, delivered as-a-service. For example, virtualized storage, communication, compute capacity (utility computing), are all existing forms of capabilities delivered as services, but are not categorically defined as software capabilities.

    In the SaaS space, has been cited as one of the prime examples, as a complete end-to-end solution delivered as a service. Earlier examples include outsourced hosting providers, managed service providers, etc. Today the cloud-based delivery model is being applied across all types of scenarios, including delivering traditional desktop applications as cloud-based services, such as Google Apps and Zoho Office. Microsoft of course has its own set of cloud-based services as well.

    Service Composition

    Not all services are of the same type. In fact many types exist as well as many ways to categorize/describe them. They include infrastructure, platforms, building blocks, etc., that operate on a technical level, to finished services that users can interact with directly.

    The fundamental aspect is that individual services can sometimes be integrated or composed or aggregated into higher-level services that perform a specific function available in the cloud. This is essentially the extension of SOA principles into the cloud, and enabling the Web as a platform.

    Service Consumption

    Web browsers will continue to serve as the primary means of accessing cloud-based services. But the cloud does not dictate the use of browsers as the only means to do so. In fact, cloud-based services provide the ideal environment to enable users consume services from all kinds of interfaces and devices.

    We are already seeing many vendors pushing the envelope beyond HTML-based browser interfaces. For example, on-line in-browser RIA platforms such as Adobe Flash, Curl, JavaFX, and Microsoft Silverlight, etc.; off-line desktop RIA platforms such as Adobe AIR, Google Gears, Yahoo Konfabulator, and Microsoft Live Mesh; and increasingly, mobile device platforms such as Apple iPhone, Google Android, Java ME, Adobe Flash Lite, Yahoo GO!, Microsoft Silverlight, etc.

    The fundamental aspect is that, cloud computing enables a seamless and consistent service consumption experience regardless of the type of device or interface used at the edge. In addition, differentiated and specialized user experiences can be delivered to different types of devices and form factors.

    Economies of Scale

    The most effective design for cloud-based services use multi-tenancy architectures, and standardize on operational and management processes. This allows service providers to share costs between multiple users, which results in lowered overall cost of service. And as the scale of usage/adoption increases, so do the economies of scale. This is not limited to managing costs; monetization models behave similarly such as in the case of Google's search advertising business.

    The cloud provides the ideal environment for service providers to leverage massively-scaled capabilities to achieve intended economies. But this does not mean all services providers have to plan for similar scales. For example,'s scale in terms of managing its userbase, is significantly different from the type of scale that Google or Amazon has to deal with.

    Network Effect

    The cloud is more than a huge collection of isolated services and islands of services. Its true power is unlocked when individual services become more inter-connected and inter-dependent. With increasing levels of interoperability, composability, data portability, semantic consistency, etc., the cloud moves away from disconnected services that require specialized integration efforts, to a dynamic system that is much more interactive and intelligent.

    Ubiquity / Pervasiveness

    The word cloud implies a level of ethereal ubiquity and pervasiveness. And cloud-based services should be provisioned such that users should not have to be concerned with how to access these services, or differences between platforms. In addition, details of the technical implementations, scaling options, etc. should be completely transparent to the users as well.

    Users should be able to interact with cloud-based services in a consistent context, even when navigating between the public cloud and private clouds.

    Challenges and Issues

    Undoubtedly, cloud computing presents many disruptive forces to existing models of using on-premise and locally installed software and applications. But some questions are still relevant. For example,

    • Who owns sensitive and confidential data?
    • How is SLA managed and enforced/guaranteed?
    • Regulatory compliance?
    • More potential points of failure?
    • Typical operational concerns, such as fine-grained control over security/privacy, governance, support for troubleshooting, overall performance, disaster recovery, planned downtimes, change management, etc.
    • Does it really cost less to users?
    • How will I differentiate?

    Another Gartner slide has a good list of common concerns.

    For example, some of the recent reported issues underscore the difficulty in maintaining massively-scaled cloud services (of course Microsoft had its share of outages too):

    And a recent BusinessWeek article "On-Demand Computing: A Brutal Slog" pointed out:


    And Nicholas Carr's post back in 2005 on "The amorality of Web 2.0" succinctly points out the changes in monetization models in the shift towards the Web.

    While we can expect that the industry as a whole will continue to move into the cloud, and gain more maturity in deploying cloud-based services, these fundamental questions and challenges will have to be addressed as well. Although, some issues inherent in highly distributed architectures will persist and need to be evaluated as trade-offs.

    Forward Looking Perspective

    It seems we are in a land-grab mode today, with organizations rushing towards the cloud, including Microsoft. Next we should expect to see the similar hype-boom-bust cycle play out, where many attempts will fade into non-existence, major consolidations occur in the market, and finally a handful of strong players remain standing and owning a major portion of the collective cloud.

    However, when the dust (or the pendulum) finally settles, will we see cloud computing supplanting the "legacy" models? Most likely not, though cloud computing will become one of the viable options for organizations to choose from. And we can expect that there will not be a one-size-fits-all approach on a "right" way to decide between on-premise and cloud-based services. Just like all previous megatrends such as SOA and Web 2.0, each organization may have a different mix of options and the degree to which they are adopted.

    Technically, we can anticipate advances towards context-aware computing as a convergence of semantic Web, data portability, derived collective intelligence, intent-driven systems, etc.; which should result in a much more intelligent and interactive cloud.



  • Architecture + Strategy

    Run Java with Jetty in Windows Azure

    Windows Azure




    The Jetty project provides:

    • Asynchronous HTTP Server
    • Standard based Servlet Container
    • Web Sockets server
    • Asynchronous HTTP Client
    • OSGi, JNDI, JMX, JASPI, AJP support


    Java Support in Windows Azure






    Run Jetty in Windows Azure in <10 Minutes



    Worker Role Implementation


    string response = "";
        System.IO.StreamReader sr;
        string roleRoot = Environment.GetEnvironmentVariable("RoleRoot");
        Process proc = new Process();
        proc.StartInfo.UseShellExecute = false;
        proc.StartInfo.RedirectStandardOutput = true;
        proc.EnableRaisingEvents = false;
        sr = proc.StandardOutput;
        response = sr.ReadToEnd();
    catch (Exception ex)
        response = ex.Message;



    Add the Java and Jetty Assets



    Configure the External Input Endpoint




    Configure Jetty (updated 2010.03.28)





    <Call name="addConnector">
    New class="">





    Download the project

    Download the project






    Lastly, these are the tools I used:

  • Architecture + Strategy

    Run Java with GlassFish in Windows Azure





    Java NIO now works!




    Deploying GlassFish







    • lib\ICSharpCode.SharpZipLib.dll
    • Launch.ps1
    • Run.cmd




    <ServiceDefinition name="GlassFishAzure" xmlns="">
      <WorkerRole name="GlassFishService">
          <Import moduleName="Diagnostics" />



    # JRE
    $jre = ''
    # GlassFish
    $glassfish = ''
    # Launch Java and GlassFish

    Essentially, update the script with:

    • Actual file names you’re using













    Java deployment options for Windows Azure










  • Architecture + Strategy

    .NET and Multiple Inheritance


    Occasionally I get questions on why does .NET not support multiple inheritance. It is actually a pretty interesting question to contemplate with, though I usually start the conversation by asking: "what issue requires multiple inheritance to solve?".

    More often than not, the question surfaces when people are trying to "do the right thing" by correctly refactoring code in an object-oriented manner, and facilitate code reuse by using inheritance, but encounter challenges when trying to reuse methods and code behaviors defined in separate places of the class hierarchy. Thus the most "natural" question was, if I can just inherit the code from these classes...

    Many decisions in language design, just like software projects, are balancing acts between various trade-offs. There are many very interesting conversations happening in the community, such as the debate on generics and closures on the Java side (for example: How Does Language Impact Framework Design? and Will Closures Make Java Less Verbose? and James Gosling's Closures). Interesting to see how much thought goes into each seemingly small decision on adding specific language features, or not adding them.

    There were many factors that influenced the .NET team to favor not implementing multiple inheritance. A few of the more prominent ones include:

    • .NET was designed to support multiple languages, but not all languages can effectively support multiple inheritance. Or technically they could, but the complexities added in language semantics would make some of those languages more difficult to use (and less similar to their roots, like VB, and for backward compatibility reasons) and not worth the trade-off of being able to reuse code in the manner of multiple inheritance
    • It would also make cross-language library interoperability (via CLS compliance) less of a reality than it is today, which is one of the most compelling features of .NET. There are over 50 languages supported on .NET in over 70 implementations today
    • The most visible factor is language semantics complexity. In C++ we needed to add explicit language features in order to address ambiguities (such as the classic diamond problem) caused by multiple inheritance, such as the "virtual" keyword to support virtual inheritance to help the compiler resolve inheritance paths (and we had to use it correctly too)
    • As we know code is written 20% of the time, but read 80% of the time. Thus advocates on simplicity side prefer not to add language features for the sake of keeping semantics simple. In comparison C# code is significantly simpler to read than C++ code, and arguably easier to write

    Now Java doesn't support multiple inheritance as well, though probably for a different set of reasons. Thus it is not a case of simple oversight in design or lack of maturity, as it was a careful and deliberate decision to not support multiple inheritance in the .NET and Java platforms.

    So what's the solution? Often people are directed to using interfaces, but interfaces don’t lend themselves very well to meet the requirements of reusing code and implementing separation of concern; as interfaces are really intended to support polymorphism and loosely-coupled/contractual design. But other than trying to tie behaviors into object inheritance hierarchies, there are many alternative approaches that can be evaluated to meet those requirements. For example, adopting relevant design patterns like Visitor, frameworks like MVC, delegates, mixins (interfaces combined with AOP), etc.

    Bottom line is, there are considerably elegant alternatives to inheriting/deriving behavior in class hierarchies, when trying to facilitate code reuse with proper re-factoring. Plus trade-offs in code reuse vs. the costs incurred to manage the reuse is another full topic in itself. In some cases it may have been simpler to have multiple inheritance and access to sealed classes, but the trade-offs may have been greater costs in other areas.

Page 1 of 28 (137 items) 12345»