Architecture + Strategy

Musings from David Chou - Architect, Microsoft

  • Architecture + Strategy

    Rise of the Cloud Ecosystems

    • 4 Comments

    I had the opportunity to participate at this year’s CloudConnect conference, with my session on Building Highly Scalable Applications on Windows Azure, which is mostly an update from my earlier presentations at JavaOne and Cloud Computing Expo. I was pleased to learn that the cloud-optimized design leveraging distributed computing best practices approach, aligned well to similar talks by well-known cloud experts from Amazon, Google, etc. A more detailed discussion on this topic can be found in my earlier post - Designing for Cloud-Optimized Architecture.

    One of the major takeaways I had from the conference, was the focus on ‘cloud platforms’ (or platform-as-a-service generally) messaging, further reinforcing the platform view of cloud computing, as opposed to the infrastructure-level perspectives, or mixed views around the popular SaaS, PaaS, and IaaS service delivery models.

    Werner Vogels,  Vice President and CTO, Amazon.comIt started with Werner Vogels in his keynote presentation. Werner said, “it is all about the cloud ecosystem”, that “everything are cloud services; everything as a cloud service”, and “not constrained by any model”. And “let a thousand platforms bloom”, where “ecosystems grow as big as possible”. This implies that the popular models (e.g., SaaS, PaaS, IaaS) are irrelevant, because everything are simply services that we can consume, and these services can span the entire spectrum of IT capabilities as we know, and potentially more.

    Infrastructure as a serviceIt is interesting to see how the platform messaging evolved over the past few years. For instance, Werner Vogels used to refer to Amazon Web Services as “Infrastructure as a Service”. However, I think Werner Vogels has always advocated the platform view, similar to Gartner’s notion of “application infrastructure as a service”, instead of the overused IaaS (infrastructure-as-a-service) service delivery model (as popularized by NIST’s definition of cloud computing). Perhaps, it was also because many people started incorrectly referring to Amazon Web Services as IaaS and not seeing the platform view, that Werner chose to clarify that models are irrelevant and “it is all about the cloud ecosystem”.

    I also belong to the camp that advocates the platform view, and the further ecosystem view of cloud computing. The platform and ecosystem views of cloud computing represent a new paradigm, and promote a new way of computing. Though I think the SaaS, PaaS, and IaaS classifications (or service delivery models) still have some uses too. They are particularly relevant when trying to understand the general differences and trade-offs between the service delivery models (as defined by NIST), from a layers and levels of abstractions perspective.

    image

    Perhaps, what we shouldn’t do, is to try to fit cloud service providers into these categories/models. As often, a particular service provider may have offerings in multiple models, have offerings that don’t fit well in these models, or it’d be over-simplifying to refer to cloud platforms, like Amazon Web Services, Google App Engine, Windows Azure platform, etc., strictly in this platform-as-a-service definition. These platforms have a lot more to offer than simply a higher-level abstraction compute service.

    Cloud Platforms

    As Werner Vogels said, “cloud is actually a very large collection of services”, cloud platforms aren’t just a place to deploy and execute workloads. Cloud platforms provide the necessary capabilities, delivered as distinct services, that applications can leverage to accomplish specific tasks.

    Amazon Web Services has always been a cloud platform; today it is a collection of services that provide capabilities for compute (EC2, EMR), content delivery (CloudFront), database (SimpleDB, RDS), deployment and management (Elastic Beanstalk, CloudFormation), e-commerce (FWS), messaging (SQS, SNS, SES), monitoring (CloudWatch), networking (VPC, ELB), payments and billing (FPS, DevPay), storage (S3, EBS), support, etc. It is not just a hosting environment for virtual machines (which the popular IaaS model is more aligned with). In fact Amazon Web Services released S3 into production (March 2006) before EC2 (limited public beta in August 2006, removed beta label in October 2008).

    Similarly, Microsoft has been using the platform-as-a-service messaging when describing Windows Azure platform, but it is also about the collection of various capabilities (delivered as services). For example, below is a visual representation of the application platform capabilities in Windows Azure platform that I have been using since 2009 (though the list of capabilities grew over that period):

    image

    And below shows how those capabilities are delivered as services and organized in Windows Azure platform.

    image

    This is important because the platform view is one of the major differentiators of cloud platforms when compared to the more conventional outsourced hosting providers. When building applications using hosting providers (or strictly infrastructure-as-a-service offerings), we have to incur the engineering efforts to design, implement, and maintain our own solutions for storage, data management, security, caching, etc. In cloud platforms such as Amazon Web Services, Google App Engine, and Windows Azure platform, these capabilities are baked into the platform and available as services that are readily accessible. Applications just need to use them, without having to be concerned with any of their underpinnings and operations.

    An analogy can be drawn from high-level differences between getting food products from Costco to put together a semi-homemade meal, versus getting raw ingredients from a supermarket and prepare, cook, and finish a fully-homemade meal. :) The semi-homemade model offers higher agility (less time and efforts required to put together a meal and to scale it for bigger parties) and economy of scale in Costco’s case, while the fully-homemade model offers more control.

    Another distinction between cloud platforms and typical IaaS offerings, is that cloud platforms are more of a way of computing – a new/different paradigm; whereas IaaS offerings are better aligned towards hosting scenarios. This doesn’t mean that there are no overlaps between the two models, or that one is necessarily better than the other. They are just different models; with some overlaps, but ideally suited for different use cases. For cloud platforms, ideal use cases are aligned to net-new, or greenfield development projects that are cloud-optimized. Again, hosting scenarios also work on cloud platforms, but cloud-optimized applications stand to gain more benefits from cloud platforms.

    Cloud Ecosystems

    The cloud ecosystem view takes the cloud platform view one step further, and includes partners and third parties that enable their services to participate in an ecosystem. The collective set of capabilities from multiple organizations and potentially services spanning multiple platforms and cloud environments together form an ecosystem that feeds and builds upon each other (in composite, federated, application models), and generating best practices and reusable processes, communities, etc. This can also be viewed as a natural evolution of platform paradigms, when drawing inference from other models where the iterations typically evolved from technology maturity, critical mass in adoption, and then building ecosystems. The platform with the largest and most diverse ecosystem, gets to ride the paradigm shift and enjoy a dominant position for that particular generation.

    The Web platform stack model I discussed back in 2007 is one way of looking at the ecosystem model (apologies for the rich color scheme; I was going through a coloring phase at the time).

    In essence, a cloud ecosystem itself will likely have many layers of abstractions as well; one building on top of another. One future trend in cloud computing may very well be the continued climb into higher levels of abstraction, as differences and complexities at one level often represent development opportunities (e.g., for specializations, consolidations/aggregations, derivations, etc.) at a higher level.

    Ultimately, cloud platforms enable the dynamic environments that support the construction of ecosystems. This is one aspect inherent in cloud platforms, but not as much for lower-level IaaS environments. And as the ecosystems grow in size and diversity, the network effect (as discussed briefly back in 2008) will contribute to increasingly intelligent and interactive environments, and generate, collectively, tremendous value.

  • Architecture + Strategy

    Cloud Computing and Microsoft

    • 7 Comments

    Here's a popular topic. ;) A quick search in the blogsphere finds countless number of posts and comments proclaiming the inevitable (or already happening) decline of Microsoft as we near the age of cloud computing.

    A small sampling of some well-known publications finds comparatively less dramatic views, but the theme is quite consistent - cloud computing is heralded as the future, and Google is best positioned to dominate this new era.

    While things look quite certain on Google's side in terms of succeeding on the Internet and leading/riding the cloud computing tidal wave, at this point it doesn't seem to be the case for Microsoft.

    Single-Era Conjecture

    "The invisible law that makes it impossible for a company in the computer business to enjoy pre-eminence that spans two technological eras"; as described in the NYTimes article, "The Computer Industry Comes With Built-In Term Limits". While I think the article did not articulate the precise reasons why Microsoft won't stay on top through a major paradigm shift (other than focusing on where Google is succeeding and where Microsoft isn't), the question is still valid.

    Reason being, cloud computing itself represents a migration from distributed client-server and on-premise software models, to a more centralized model (though logically centralized and physically distributed). Eric Schmidt said, "What [cloud computing] has come to mean now is a synonym for the return of the mainframe... and the mainframe is a set of computers... They're in a cloud somewhere." And this everything-as-a-service (in the cloud) model directly conflicts with what people most commonly identify Microsoft with - software for people to use (and most visibly Windows and Office - client O/S and desktop software).

    More specifically, various trends in the past 10+ years have also influenced this paradigm shift. Just to list the obvious ones:

    • Consumerization of the Web, and use of browsers
    • Application development efforts shifting towards thin clients and server-side programming
    • Improvements in network bandwidth, anywhere wireless access, etc.
    • Increased maturity in open source software
    • Proliferation and advancement of mobile devices
    • Service Oriented Architecture
    • Software-as-a-Service
    • Utility/Grid Computing

    Effectively, the shift towards browsers as the primary channel of access for consumers and deployment target for organizations, has reduced the need to use locally installed software. And this directly impacts Windows and Office, plus server software traditionally acquired and installed on-premise; perceivably the entire Microsoft product portfolio.

    Plus arguably, Microsoft's investments in online services so far have not won leadership positions and profitability. Recent deliverables such as Windows Live have made significant progress, especially Live Search where the technology has closed some gaps with Google, but still trails behind in terms of adoption. And the gap seems to be widening still.

    So it seems the "Single-Era Conjecture" must be true, and that Microsoft is walking towards its impending downfall? That would certainly be the case if Microsoft completely ignores the market and not see the need to change, or is incapable of change.

    However, Microsoft does see the need, and has been working on many significant changes to shift towards the cloud.

    But, then, why does it seem so difficult for Microsoft to make any significant progress in this area? A couple of thoughts:

    • Microsoft still has a $60B/year and consistently growing business in software
    • As a publicly traded company, Microsoft cannot simply abandon the current software customer base to fully pursue the new services model
    • Microsoft's own culture has to shift as well, but that won't happen overnight given the size and complex environment
    • As a software platform company, Microsoft's focus has been delivering innovation-enabling capabilities to IT customers, not massive scale and speed and multi-tenancy in Microsoft's own technical infrastructures
    • Software is a complex business, and Microsoft has built extensive processes and organizations to deliver secure and robust software, compared to Google's rapid release and perpetual beta model. It will require significant changes in Microsoft to compete on the same grounds as Google, or achieve a similar level of agility
    • If the bottle is half-full, Microsoft actually has made very significant progress; but Google has set the bar very high for anyone to be compared against
    • General mindshare shift towards open source software

    What About the Other Guys?

    So much attention has been focused on the perceived "war" between Microsoft and Google. But what about the rest of the IT industry? This shift towards cloud computing also in many ways presents challenges to their existing businesses. I'll bet many organizations are also thinking that they missed the opportunity to land grab some market share in online search.

    But from a corporate strategy perspective, the seemingly different approaches are very remarkable. Microsoft is pursuing the path of organically build towards the cloud. Oracle is starting to build data centers, but seems to in general prefer acquiring its way into the cloud once the market begins to mature; as they have done with the major acquisitions in the past decade. IBM is also building data centers, but seems to leverage and build upon pure cloud players such as their partnership with Google; as they have done with open source software. Similarly, Intel, HP, and Yahoo have teamed up to build towards the cloud as well. Very distinct strategies, but do seem to be the sensible approaches for each organization.

    However, not everyone will be able to afford building massive data centers and establishing clouds. Yahoo Research Chief Prabhakar Raghavan said, "In a sense, there are only five computers (clouds) on earth." He listed Google, Yahoo, Microsoft, IBM, and Amazon. Well, may be not exactly, but that view of the world is also not entirely implausible, and imagine the kinds of changes everyone will undergo in order to achieve that state.

    That view also underscores a complete commoditization of the entire IT industry. While unfathomable by today's standards, it is conceivable that a paradigm shift such as cloud computing could exact such sweeping changes from us. Reason being, cloud-based services have the benefit of the economies of scale, which allows the services to be provisioned at a lower cost. Existing IT shops, which increasingly face the need to reduce maintenance costs and deliver innovation, may very well favor switching over to cloud-based utility-like services; often compromising quality for lower cost.

    Nicholas Carr said in his book, The Big Switch - "In the long run, the IT department is unlikely to survive, at least in its familiar form. It will have little left to do once the bulk of business computing shifts out of private data centers and into the cloud." Plus a very contrarian and sensational blog post "Your new IT budget: $10".

    Which means, IT shops will increasingly need fewer investments on in-house technology and resources to support operations. And that also translates to needing fewer in-house technical specialists. As demand for technology and technical skills decreases, so does their value, which marks the trend of complete commoditization. Scary thought no?

    Of course Nick Carr's view has generated a lot of controversy, as well as an ample amount of vehement disagreement. But in that light, doesn't Microsoft's scramble towards the cloud seem reasonable, and whoever is not doing so may need to be a bit concerned?

    Microsoft's Perspective

    In a nutshell, Microsoft does see the importance of cloud computing, and is actively building towards the cloud. But Microsoft's approach to shift towards the cloud, is based on a considerably pragmatic perspective that the world will not completely move into the cloud. We think that on-premise and local/client software still has value in the future, but the cloud will undoubtedly be a major component as well.

    The moniker that best describes Microsoft's approach is "Software Plus Services".

    Basically, we expect that the world will remain in a hybrid state, where commonly used services (like today's outsourcing of payroll services to ADP) may move into the cloud, but many differentiating capabilities will continue to be implemented and delivered towards the edge. Some potential factors:

    • User experience - browsers tend to constrict differentiation; client software is still best at delivering high-fidelity and robust user experiences
    • Not one-size-fits-all - not all things are suitable for the cloud; many capabilities are still best delivered on the client or on-premise
    • Organizations' need to innovate and differentiate from competitors using the same or similar commoditized services in the cloud
    • Advancements in human-device interface will drive a new class of clients (i.e., Surface, Sphere, 3-D displays, multi-touch, etc.) which may drive entirely new ways to interact with information (and browsers become the legacy mode)
    • Merits of distributed computing may shift attention back towards the edge again, as certain tasks are more suitable for smaller and more distributed units than a few massive centralized clouds (such as disaster recovery, defense-in-depth, data privacy, etc.)

    So what is Microsoft doing to shift towards cloud computing? To list some interesting points:

    • Microsoft's recent surge in investments on building massive data centers around the world (for example, Quincy, WA; Chicago, IL; San Antonio, TX; Des Moines, IA; Dublin, Ireland; Siberia, Russia, etc.). Some of these data centers cost more than $500M each
    • Every one of Microsoft's server products will eventually be offered as subscription-based services in the cloud; though licensing-based on-premise versions will also continue to be offered to provide the full range of choices for customers (reinforcing "Software + Services")
    • For example, Exchange, SharePoint, and Office Communication Servers are already part of the Microsoft Online services offerings; Biztalk and SQL Servers are also being delivered as Biztalk Services and SQL Server Data Services; and Dynamics CRM Online
    • One publicized case is Coca-Cola Enterprises moving 30,000+ knowledge workers to Exchange Online (from on-premise Lotus Notes)
    • Significant investments in advertising solutions; both on-line and off-line
    • Significant investments in leveraging open source software
    • Research efforts in multi-core and massively distributed parallel processing capabilities
    • Closing the gap in online search is just one component of the overall services strategy which includes a full spectrum of target audiences, and different types of services (i.e., infrastructure/building blocks, complementary/attached, consumer/finished services, etc.)

    Thus Microsoft definitely aspires to become a major player in the cloud. What remains to be seen is just how well Microsoft executes towards the cloud.

    Interesting times ahead. One thing is certain - more changes to come, and we can expect Microsoft to ramp up activities in this area very aggressively the next few years. Don't count Microsoft out, just yet. :)

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

     

  • Architecture + Strategy

    Internet Service Bus and Windows Azure AppFabric

    • 3 Comments

    imageMicrosoft’s AppFabric, part of a set of ”application infrastructure” (or middleware) technologies, is (IMO) one of the most interesting areas on the Microsoft platform today, and where a lot of innovations are occurring. There are a few technologies that don’t really have equivalents elsewhere, at the moment, such as the Windows Azure AppFabric Service Bus. However, its uniqueness is also often a source of confusion for people to understand what it is and how it can be used.

    Internet Service Bus

    Oh no, yet another jargon in computing! And just what do we mean by “Internet Service Bus” (ISB)? Is it hosted Enterprise Service Bus (ESB) in the cloud, B2B SaaS, or Integration-as-a-Service? And haven’t we seen aspects of this before in the forms of integration service providers, EDI value-added networks (VANs), and even electronic bulletin board systems (BBS’s)?

    At first look, the term “Internet Service Bus” almost immediately draws an equal sign to ‘Enterprise Service Bus’ (ESB), and aspects of other current solutions, such as ones mentioned above, targeted at addressing issues in systems and application integration for enterprises. Indeed, Internet Service Bus does draw relevant patterns and models applied in distributed communication, service-oriented integration, and traditional systems integration, etc. in its approaches to solving these issues on the Internet. But that is also where the similarities end. We think Internet Service Bus is something technically different, because the Internet presents a unique problem domain that has distinctive issues and concerns that most internally focused enterprise SOA solutions do not. An ISB architecture should account for some very key tenets, such as:

    • Heterogeneity – This refers to the set of technologies implemented at all levels, such as networking, infrastructure, security, application, data, functional and logical context. The internet is infinitely more diverse than any one organization’s own architecture. And not just current technologies based on different platforms, there is also the factor of versioning as varying implementations over time can remain in the collective environment longer than typical lifecycles in one organization.
    • Ambiguity – the loosely-coupled, cross-organizational, geo-political, and unpredictable nature of the Internet means we have very little control over things beyond our own organization’s boundaries. This is in stark contrast to enterprise environments which provide higher-levels of control.
    • Scale – the Internet’s scale is unmatched. And this doesn’t just mean data size and processing capacity. No, scale is also a factor in reachability, context, semantics, roles, and models.
    • Diverse usage models – the Internet is used by everyone, most fundamentally by consumers and businesses, by humans and machines, and by opportunistic and systematic developments. These usage models have enormously different requirements, both functional and non-functional, and they influence how Internet technologies are developed.

    For example, it is easy to think that integrating systems and services on the Internet is a simple matter of applying service-oriented design principles and connecting Web services consumers and providers. While that may be the case for most publicly accessible services, things get complicated very quickly once we start layering on different network topologies (such as through firewalls, NAT, DHCP and so on), security and access control (such as across separate identity domains), and service messaging and interaction patterns (such as multi-cast, peer-to-peer, RPC, tunneling). These are issues that are much more apparent on the Internet than within enterprise and internal SOA environments.

    On the other hand, enterprise and internal SOA environments don’t need to be as concerned with these issues because they can benefit from a more tightly controlled and managed infrastructure environment. Plus integration in the enterprise and internal SOA environments tend to be at a higher-level, and deal more with semantics, contexts, and logical representation of information and services, etc., organized around business entities and processes. This doesn’t mean that these higher-level issues don’t exist on the Internet; they’re just comparatively more “vertical” in nature.

    In addition, there’s the factor of scale, in terms of the increasing adoption of service compositions that cross on-premise and public cloud boundaries (such as when participating in a cloud ecosystem). Indeed, today we can already facilitate external communication to/from our enterprise and internal SOA environments, but to do so requires configuring static openings on external firewalls, deploying applications and data appropriate for the perimeter, applying proper change management processes, delegate to middleware solutions such as B2B gateways, etc. As we move towards a more inter-connected model when extending an internal SOA beyond enterprise boundaries, these changes will become progressively more difficult to manage collectively.

    An analogy can be drawn from our mobile phones using cellular networks, and how its proliferation changed the way we communicate with each other today. Most of us take for granted that a myriad of complex technologies (e.g., cell sites, switches, networks, radio frequencies and channels, movement and handover, etc.) is used to facilitate our voice conversations, SMS, MMS, and packet-switching to Internet, etc. We can effortlessly connect to any person, regardless of that person’s location, type of phone, cellular service and network, etc. The problem domain and considerations and solution approaches for cellular services, are very different from even the current unified communications solutions for enterprises. The point is, as we move forward with cloud computing, organizations will inevitably need to integrate assets and services deployed in multiple locations (on-premises, multiple public clouds, hybrid clouds, etc.). To do so, it will be much more effective to leverage SOA techniques at a higher-level and building on a seamless communication/connectivity “fabric”, than the current class of transport (HTTPS) or network-based (VPN) integration solutions.

    Thus, the problem domain for Internet Service Bus is more “horizontal” in nature, as the need is vastly broader in scope than current enterprise architecture solution approaches. And from this perspective Internet Service Bus fundamentally represents a cloud fabric that facilitates communication between software components using the Internet, and provides an abstraction from complexities in networking, platform, implementation, and security.

    Opportunistic and Systematic Development

    It is also worthwhile to discuss opportunistic and systematic development (as examined in The Internet Service Bus by Don Ferguson, Dennis Pilarinos, and John Shewchuk in the October 2007 edition of The Architecture Journal), and how they influence technology directions and Internet Service Bus.

    Systematic development, in a nutshell, is the world we work in as professional developers and architects. The focus and efforts are centered on structured and methodical development processes, to build requirements-driven, well-designed, and high-quality systems. Opportunistic development, on the other hand, represents casual or ad-hoc projects, and end-user programming, etc.

    This is interesting because the majority of development efforts in our work environments, such as in enterprises and internal SOA environments, are aligned towards systematic development. But the Internet advocates both systematic and opportunistic developments, and increasingly more so as influenced by Web 2.0 trends. Like “The Internet Service Bus” article suggests, today a lot of what we do manually across multiple sites and services, can be considered a form of opportunistic application; if we were to implement it into a workflow or cloud-based service.

    And that is the basis for service compositions. But to enable that type of opportunistic services composition (which can eventually be compositing layers of compositions), technologies and tools have to be evolved into a considerably simpler and abstracted form such as model-driven programming. But most importantly, composite application development should not have to deal with complexities in connectivity and security.

    And thus this is one of the reasons why Internet Service Bus is targeted at a more horizontal, and infrastructure-level set of concerns. It is a necessary step in building towards a true service-oriented environment, and cultivating an ecosystem of composite services and applications that can simplify opportunistic development efforts.

    ESB and ISB

    So far we discussed the fundamental difference between Internet Service Bus (ISB) and current enterprise integration technologies. But perhaps it’s worthwhile to discuss in more detail, how exactly it is different from Enterprise Service Bus (ESB). Typically, an ESB should provide these functions (core plus extended/supplemental):

    • Dynamic routing
    • Dynamic transformation
    • Message validation
    • Message-oriented middleware
    • Protocol and security mediation
    • Service orchestration
    • Rules engine
    • Service level agreement (SLA) support
    • Lifecycle management
    • Policy-driven security
    • Registry
    • Repository
    • Application adapters
    • Fault management
    • Monitoring

    In other words, an ESB helps with bridging differences in syntactic and contextual semantics, technical implementations and platforms, and providing many centralized management capabilities for enterprise SOA environments. However, as we mentioned earlier, an ISB targets concerns at a lower, communications infrastructure level. Consequently, it should provide a different set of capabilities:

    • Connectivity fabric – helps set up raw links across boundaries and network topologies, such as NAT and firewall traversal, mobile and intermittently connected receivers, etc.
    • Messaging infrastructure – provides comprehensive support for application messaging patterns across connections, such as bi-directional/peer-to-peer communication, message buffers, etc.
    • Naming and discovery – a service registry that provides stable URI’s with a structured naming system, and supports publishing and discovering service end point references
    • Security and access control – provides a centralized management facility for claims-based access control and identity federation, and mapping to fine-grained permissions system for services

    A figure of an Internet Service Bus architecture is shown below.

    clip_image002

    And this is not just simply a subset of ESB capabilities; ISB has a couple of fundamental differences:

    • Works through any network topology; whereas ESB communications require well-defined network topologies (works on top)
    • Contextual transparency; whereas ESB has more to do with enforcing context
    • Services federation model (community-centric); whereas ESB aligns more towards a services centralization model (hub-centric)

    So what about some of the missing capabilities that are a part of ESB, such as transformation, message validation, protocol mediation, complex orchestration, and rules engine, etc.? For ISB, these capabilities should not be built into the ISB itself. Rather, leverage the seamless connectivity fabric to add your own implementation, or use one that is already published (can either be cloud-based services deployed in Windows Azure platform, or on-premises from your own internal SOA environment). The point is, in the ISB’s services federation model, application-level capabilities can simply be additional services projected/published onto the ISB, then leveraged via service-oriented compositions. Thus ISB just provides the infrastructure layer; the application-level capabilities are part of the services ecosystem driven by the collective community.

    On the other hand, for true ESB-level capabilities, ESB SaaS or Integration-as-a-Service providers may be more viable options, while ISB may still be used for the underlying connectivity layer for seamless communication over the Internet. Thus ISB and ESB are actually pretty complementary technologies. ISB provides the seamless Internet-scoped communication foundation that supports cross-organizational and federated cloud (private, public, community, federated ESB, etc.) models, while ESB solutions in various forms provide the higher-level information and process management capabilities.

    Windows Azure AppFabric Service Bus

    The Service Bus provides secure messaging and connectivity capabilities that enable building distributed and disconnected applications in the cloud, as well hybrid application across both on-premise and the cloud. It enables using various communication and messaging protocols and patterns, and saves the need for the developer to worry about delivery assurance, reliable messaging and scale.

    AppFabric Service Bus

    In a nutshell, the Windows Azure AppFabric Service Bus is intended as an Internet Service Bus (ISB) solution, while BizTalk continues to serve as the ESB solution, though the cloud-based version of BizTalk may be implemented in a different form. And Windows Azure AppFabric Service Bus will play an important role in enabling application-level (as opposed to network-level) integration scenarios, to support building hybrid cloud implementations and federated applications participating in a cloud ecosystem.

  • Architecture + Strategy

    Office Web Applications as Native Browser Apps in Microsoft Office 2010

    • 1 Comments

    A couple of announcements at the Microsoft Worldwide Partner Conference (WPC09) have been making a lot of noise today. One is the unveiling of the much anticipated Office Web Applications, part of the overall Office 2010 announcements – that Office 2010, SharePoint Server 2010, Visio 2010 and Project 2010 have reached the technical preview engineering milestone.

    Unlike the previous online Office service offerings, such as Office Online, Office Live and Office Live Small Business; Office Web Applications are indeed browser-based Office clients. Specifically, Excel, OneNote, PowerPoint, and Word; in addition to Outlook which had the Web Access version for a number of years already.

    And as part of Office 2010, Office Web Applications will be available to nearly half a billion customers at launch:

    • 400 million users on Windows Live – FREE! 
    • 90 million Office annuity customers will have access to on-premise deployments
    • Office customers will also be able to host and access the Office Web Applications through Microsoft Online Services

    A few screenshots below. As you can see, one of the major common themes is that all of the Web Application clients will use the Office Fluent ribbon menu system as well.

    Excel Web Application

    And in FireFox:

    office2010_tp_sp_12 

    OneNote Web Application

    PowerPoint Web Application

    Word Web Application

    Use Office Anywhere!

    The Office Web Applications can be accessed by simply opening the documents as listed on a web page. Even though not just any web page, but can be document folder pages that are hosted in Office Live Workspaces, Windows Live Skydrive, SharePoint Online, on-premise SharePoint Server 2010 instances, etc. Just opening the document (for editing) will open the Office Web Applications in the same browser.

    These browser-based clients are considered “basic” cousins to the full desktop client versions. But as you can see, the level of fidelity and richness in the Office Web Applications are actually much better than “basic”. In fact, the included features are quite effective at editing documents from any browser.

    Plus some new features in Office Mobile 2010:

    • Full compatibility with the Open XML File Formats
    • SmartArt Graphics for viewing documents and presentations
    • Over-the-air sync for OneNote notebooks
    • The ability to sync SharePoint content to the device

    This means that, users will have access to, and can use Microsoft Office to edit/modify Office documents anywhere. From the most basic experience, but highest mobility on mobile devices, to most common/streamlined experience on any computer with an Internet connection, and to the richest/professional desktop experience installed locally on your own computer.

    Some people may criticize Microsoft for not innovating and still holding on to the desktop dinosaur, but we think a not one-size-fits-all approach, and offering the spectrum of options to use, is actually better for the customer. Someone has used an analogy – trying to fit everything into the browser, and ask all users to use that one model, is like asking everyone to ride mopeds.

    Real-Time Collaboration!

    In addition to the ability to save/store documents and access/edit them anywhere (cloud, server, desktop, device, etc.), users will also be able to share and collaboratively edit the same document over the network. And this will work access the desktop and browser-based clients. With “fast dynamic sync”, changes from multiple simultaneous users can be synchronized across the group almost instantaneously.

    Other new collaboration features include:

    • “Automagic” change merging
    • Unread change highlighting
    • View recent/historical edits
    • Author highlighting
    • Change versioning and management

    Things sure are looking quite interesting with the Office 2010 release.

    For more information:

  • Architecture + Strategy

    Web 2.0 - A Platform Perspective

    • 10 Comments

    Background & Primer

    "Web as a Platform" has been a much discussed topic since Tim O'Reilly used it as a tagline in the first Web 2.0 conference back in October of 2004, then described in more detail in a 2005 article, and the subsequent "Mind Map" graphic:

    800px-Web_2_0_Map_svg

    Since then many interpretations of the "Web platform" have existed, ranging from technical perspectives that focused on tools such as AJAX, RSS, REST, SOAP, mashups, composite applications; user-generated content and collective intelligence such as Wikipedia, Youtube; social bookmarking/syndication such as del.icio.us, Digg; to social networks such as Facebook, Myspace, etc. Just to list a few, but the list of sites and categories of sites that exemplify Web 2.0 principles has undergone an explosive growth in the past few years.

    Collectively, the rich cluster of "Web 2.0" sites on the internet form a services foundation from which applications and functionalities can be built upon, without needing any additional dedicated infrastructure. This marks a significantly different approach from "Web 1.0" site implementations where each organization has to procure dedicated hardware, software, hosting environment, etc. in order to provision a new application on the internet. As a result, the collection of cloud-based services form a new kind of "platform" to create a new breed of applications.

    Understanding Web as a Platform

    Without making this yet another attempt at trying to define the specifics of Web 2.0 (or even Web 3.0 for that matter) and the internet platform, delegating it to those who focus on semantics, I think we can look at "Web as a Platform" in its broadest terms. That is, a platform that provides some sort of framework which allows people to build stuff upon, while encapsulating (or hiding) some of the underlying complexities.

    But this doesn't point directly to technical solutions; it really encompasses many categories of "stuff" (such as media, social interactions, implicit relationships, semantic connections, monetization methods, etc.) that can be leveraged and implemented on the Web today. I liked how Fred Wilson said it:

    I believe the web is a platform. And that everything we need for an open ad market, or an open data architecture, or frankly most anything else, is available on the "web platform" today.

    So what can we do with the Web platform? There are many perspectives on this as well. Such as Marc Andreesen's "layered" perspective:

    Level 1 - API access - Flickr, Delicious, Twitter, etc.
    Level 2 - API plug-in - Facebook
    Level 3 - Runtime environment - Ning, Salesforce.com, etc.

    And Alex Iskold's "building blocks" perspective:

    Storage Services - Amazon S3, GDrive, Windows Live Skydrive, etc.
    Messaging Services - Amazon Simple Queue Service, BizTalk Services, etc.
    Compute Services - Sun Grid
    Information Services - Amazon E-Commerce, Yahoo! Answers, Virtual Earth, etc.
    Search Services - Google Search API, Alexa Search Platform, Live Search, etc.
    Web 2.0 Services - del.icio.us, Flickr, Basecamp, etc.

    Again, without questioning the validity of these categorizations used (as there are lots of discussion about that as well), I think from a general sense, both perspectives are valid. I think that building blocks do exist, but at the same time, there are multiple layers of building blocks (or categories) in the Web platform.

    What this means, is that building blocks in each layer can be utilized in various combinations/permutations to create the next layer up. These layers span between two extremes - information and people. The layers closer to information consist of Web application platforms as we know today, such as ASP.NET, Silverlight, LAMP, Java, Ruby on Rails, etc.; that require more expert knowledge in development and technology but smaller parts of the overall population. The layers closer to people are still being formed as we speak, but in general they rely on higher forms of abstraction that provide services closer to our lives, while enabling the broad reach of larger pools of audiences (consumerization and democratization of technology comes to mind). And today we are seeing higher and higher layers of platforms being created that allow people to connect, to organize, to find and use resources, to be social, and to basically "live" on the Web.

    Of course, the word "platform" is being used very loosely today, and new "platforms" and layers of platforms are being created almost on a daily basis. Marshall Kirkpatrick took a real brief look at some of the most hyped new platforms today. For example, the most recent and significant incarnations of higher-level Web platforms are probably Facebook Platform and Google OpenSocial.

    From a platform layer perspective, the Facebook Platform and Google OpenSocial, even though aimed at doing different things (lots of debate on this too), are built on top of other existing layers. Applications built on top of the Facebook Platform use a combination of traditional Web app technologies like HTML, CSS, JavaScript, XML, etc., but their benefits are derived from building blocks available on the Facebook Platform, in the form of mashups of external services building blocks, explicit foundation blocks (such as News Feeds, Status, Events, FBML, FQL, configuration and provisioning systems, etc.), and implicit foundation blocks (social graphs, software distribution/dissemination channel, monetization, 50+ million and still growing user base, etc.). A major characteristic of this platform is that it is very easy to develop against, which democratizes development and allows more and more people to participate in the social experience. In essence this platform furtherly narrows the gap between technology and people (thus categorized as a higher-layer platform). This resulted in a wildly viral and vital platform that has accounted more than 5,000 applications deployed today and growing exponentially.

    From a higher level, it seems that a "Web OS" of some sort is starting to take shape, as we can draw many parallels to the layered, subsystems and componentized approaches in modern computer operating system and software architectures. But I am not yet sure that it would be of value to try to apply traditional thinking in defining a "standard" Web platform stack, by needlessly preempting more knowledgeable people, and risk further defragmenting the evolution.

    In general though, by today we can definitely see the Web maturing as a very viable platform. News such as Amazon S3 exceeds 99.99% uptime should remove most doubts about the reliability of cloud-based services. But I think it is a platform with a spectrum of choices (layers and building blocks) where people with different skillsets can look to leverage and add value. The choices available in the full spectrum are all relevant, despite some idealists' claim that newer and higher-level models (such as higher layers of the platform used in the context of this post) will completely commoditize and subsume older and lower-level models. I tend to think that, while it is true that more and more attention will be focused on newer and higher-level models, we will continue to see lots of innovation on the lower-level layered platforms. We will just see that more and more people will be involved in the overall ecosystem, with a large infusion of participants with non-technical skillsets increasingly more involved at the higher levels. This I think is the true goal of Web 2.0, connecting people and democratizing/bridging the technology chasm.

    What's Next?

    It's always interesting to try to take a peek at what may be possible in the future.

    Democratization in software development - Recent advances in the Web platform (raising layers of abstraction), model-driven architectures, etc., will increasingly simplify software development efforts for the higher level platforms. Two very notable examples are Yahoo! Pipes and Microsoft Popfly.

    The Implicit Web - Increasing specialization in making sense of the dynamic aspects of user behaviors and activities in the online world. For example, search engines to finally grasp user intent (via click streams, combinational media consumption habits, etc.). This is also an area where the Facebook Platform may be able to glean from the reactions its applications can elicit from the members, based on the static social graphs.

    Privacy Controls - With so much attention on enabling the "read-write" Web, and increasing openness, a need for better privacy control will inevitably arise. Web idealists argue that traditional data silos (or intellectual property as we know today) will need to be opened up and interoperate in the new world. Again, I believe a hybrid model somewhere between the two extremes (of fully open and completely closed architectures) usually work out better to the benefit of its users. From this perspective, yes the highly protected enterprise data silos today will need to open up, but should be just enough to add value for the users. To do that, some kind of interoperable privacy controls is required.

    Ubiquitous Access w/ Rich User Experiences - A consistent and seamless experience for people accessing their information, applications, and services, across a full spectrum of connected devices and systems. At the same time, highly targeted user experiences implemented for the appropriate form factors are available to take advantage of the latest hardware and device innovations.

    There are many more, such as the data/semantic Web, evolutionary intelligence, changes in social trends, etc. It'll be interesting to see how things pan out in this space.

    Share this post :

    This post is part of a series:

Page 3 of 28 (137 items) 12345»