Application Security » Enrique Castro-Leonhttp://blogs.intel.com/application-security
Intel Security Expert Musings on App & Web Services SecurityThu, 10 Apr 2014 22:57:59 +0000en-UShourly1From ESBs to API Portals: an Evolutionary Journey Part 4http://blogs.intel.com/application-security/2013/04/18/esbs-apis-application-security/
http://blogs.intel.com/application-security/2013/04/18/esbs-apis-application-security/#commentsThu, 18 Apr 2013 20:50:22 +0000http://blogs.intel.com/application-security/?p=1021The continuing transformation of the IT industry around the externalization of service components constitutes an exercise in abstraction. The transformation assumes that any IT application can be recursively decomposed into constituent services. An application that has been re-architected or engineered … Read more >

]]>The continuing transformation of the IT industry around the externalization of service components constitutes an exercise in abstraction. The transformation assumes that any IT application can be recursively decomposed into constituent services. An application that has been re-architected or engineered this way is known as a composite application.

As with any abstraction exercise, the devil is in the details. When a particular capability is to be replaced with a service, just as good is not sufficient to trigger change; it needs to be much better to make the change justifiable from a business perspective, anywhere from 3X to 10X to overcome the change hysteresis or the incumbent alternative stays.

One challenge is that in many cases there is no tradition in the organization of measuring service components. For instance if a replacement service is said to be more energy efficient and it comes with the metrics to prove it, these numbers are not useful if the contracting organization does not keep energy consumption statistics at the level of granularity of the service offering: if the available historical data is at the power distribution unit (PDU) level measuring consumption at the rack or even row level, this information is of little use if the unit of delivery for a service is a virtual machine (VM) and the provider furnishes energy data on a per VM basis.

The semantic gap between VM power and PDU power could be in principle bridged by aggregating VM power into rack power. However doing so would require significant research and would difficult to do without industry consensus because the actual numbers would be dependent on the measurement method.

One of the most obvious metrics for a service is pricing. For instance one could use the total cost of ownership (TCO) of a storage appliance to derive a cost per byte over the lifetime of the appliance. This number can be compared with the cost of a cloud storage service offering. The cost of the service may be accrued on a monthly basis, where the cost of the appliance comes in a big chunk of petabytes over the 3 to 5-year lifetime of the appliance. This suggests that there are more dimensions in the process of making a decision between doing nothing or breaking up the application into service components and start factoring out these components, SOA style or externalizing the components through cloud service providers. What are these dimensions? Let’s explore a few.

Performance and Quality of Service

Assuming that a prospective service alternative passes the cost test the IT organization will look at performance. It will be of little consolation if a service offering saves money if the quality of service (QoS) deteriorates to the point that complains pile up. The expectation is that service offerings tend to be remote and hence result in higher latency due to distance and lower bandwidth due to network limitations. A cloud bursting solution may be implemented via a VPN link to remote resources offered by a service provider. This link is a potential weakness, inducing a “tromboning” or barbell effect with two large resources connected through a relatively thin tether, resulting in large latencies between entities connected across the tether.

Performance deserves a careful consideration because performance behaviors tend to be highly discontinuous. For instance, if a service offering doubles storage latency, this may trigger transaction timeouts. Because of the transaction retries, the actual latencies experienced by the end users served by the IT organization may not just double, but increase by an order of magnitude. On the other hand, a global company replacing a centralized database location with storage from a provider may actually end up with improved QoS if the provider caches and mirrors the data in the appropriate locations.

Another dimension of performance is scalability. In the industry cloud computing is economically feasible because of specialization: the assumption is that one entity able to fulfill a specific function on behalf of a community of service customers more efficiently than each customer separately through resource pooling and specialized expertise. Therefore the service provider can deliver the function at a lower cost than the in-sourced alternative enough and still make a profit to stay in business. The size of the pooled resources needs to be larger than the largest request expected from any of the customers; otherwise there will be cases where the provider will not be able to honor a request.

Security

Security is a first order concern on par with performance and cost. It relates to preserving the privacy and integrity of the data and governance, risk and compliance (GRC) practices. Security is often cited as a roadblock to cloud adoption in the industry. An approach to addressing this conundrum is to look at the problem as a continuum, not as a black or white issue and to look at capabilities available today. Different application deployment models have different levels of security associated with them. A classification of infrastructure deployment from the most to least secure could be as follows:

1) Corporate assets deployed in corporate infrastructure

2) Private cloud on corporate premises

3) Provider hosted private clouds

4) Public clouds

One solution to improve cloud security outcomes while minimizing cost is to define different types of data and institute a policy for the deployment of the data. One example would be to have company secrets under #1, corporate e-mail stores under #2, CRM data under #3 and product brochures under #4.

IT and Business Process Standardization

This is a big one. One of the purposes of an ESB is to ensure there are commonly enterprise-wide procedures (“patterns” in SOA speak) for functions such as pub-sub and event notification. For a single enterprise a single, company-wide proprietary ESB implementation, either cobbled up in-house or from a single vendor is a workable solution. Extending this notion across multiple companies and providers is much harder. Arguably cloud computing is still an
emerging discipline with the standards to enable these capabilities not yet in place.

Even the simpler problem of moving a workload from one hypervisor environment is currently a nontrivial undertaking. The author had the privilege of serving as an architect for a proof of concept exercise sponsored by T-Systems. The goal of the exercise was to demonstrate the ability of moving virtual machines across hypervisor environments using publicly available conversion tools. This was a straight implementation of the VM Interoperability Usage Model as defined by the Open Data Center Alliance. We used four of the most well-known hypervisor environments. We found roadblocks across
most conversion paths. Moving VMs to public cloud providers posed additional challenges because of the degree of para-virtualization or customization in public vendors’ hypervisor environments.

Metaservices

In addition to the intrinsic functional capabilities implemented by servicelets, composite applications need a number of ancillary capabilities: service customers need to find them. A service registry would allow service provider to publish their offerings and users to discover, assess and bind the
service offerings to their applications.

Another metaservice is data encryption and transformation: data needs to be striped, replicated, compressed, encrypted and replicated to meet target quality criteria. On the business side reliable, non-repudiable mechanisms for billing and cost settlement that work across composite applications. For some customers the ability to do audit trails or even cloud forensics is a must have feature. Unfortunately the state of the art leaves much to be desired, as panelists declared at a recent RSA Conference.

Epilog

In the next installment we’ll take a look at how Intel® Expressway API Manager and Intel® Expressway Service Gateway offer brokerage, discovery and security services as a present day embodiment of an ESB. In so doing API management addresses some of the challenges for the implementation and deployment of composite applications mentioned above, not just for a single enterprise, but for whole ecosystems comprising both developers and end user communities.

]]>http://blogs.intel.com/application-security/2013/04/18/esbs-apis-application-security/feed/0From ESBs to API Portals: an Evolutionary Journey Part 3http://blogs.intel.com/application-security/2013/03/28/from-esbs-to-api-portals-an-evolutionary-journey-part-3/
http://blogs.intel.com/application-security/2013/03/28/from-esbs-to-api-portals-an-evolutionary-journey-part-3/#commentsThu, 28 Mar 2013 14:34:14 +0000http://blogs.intel.com/security-gateways/?p=747In this article series we build the case for API portals, out of which the Intel® Expressway Service Gateway and the Intel® API Manager, powered by Mashery are representative examples, as the contemporary manifestations of the SOA movement that transformed IT in the … Read more >

]]>In this article series we build the case for API portals, out of which the Intel® Expressway Service Gateway and the Intel® API Manager, powered by Mashery are representative examples, as the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s execution of a business strategy and revenue generation. In the introductory article in Part 1, we discussed some of the business dynamics that led to cloud computing and the service paradigm. In part 2 we took look at the SOA transformation in the big enterprise. Let’s now examine the influence of SOA in small and medium businesses. At a first blush it would appear that only large organizations have the critical mass to a large number of application instances to make reuse under SOA economically justifiable. This is not really the case because of some unintended consequences and fortunately, a happy ending.

Let’s do a brief introduction to small businesses first to establish a context for the discussion. Between large companies and individual consumers lies the vast ecosystem of small and medium business, from mom and pop outfits to sizable companies, but perhaps not yet with global reach, the small and medium businesses or SMBs.

According to the U.S. Small Business Administration, small firms, defined as independent business having fewer than 500 employees, constitute 99.7 percent of all employer firms in the United States. Furthermore, small firms pay more than 42.9 percent of total U.S. private payroll and have created more than half of nonfarm private gross domestic product (GDP). According to the US Small Business Administration, the number of businesses in the United States in 2010 totaled about 27.9 million, out of which only 18,500 are were large firms. In other words, looking at the statistical distribution of all businesses in the United States, there is a long tail represented by SMBs. This long tail has a significant economic impact that cannot be ignored.

By their very nature of SMBs typically do not have a large IT budget, or a large IT department. Many of them have only a few IT literate employees acting as part time IT support. They could not afford the kind of “internal-only” or inside-out SOA adoption model described in Part 2. This fact effectively precludes the conditions under the inside-out SOA model.

However, it turned out that small businesses started partaking of the third party IT services used by large firms. How was this possible? That’s because service oriented IT, with metered, a la carte services enabled the delivery of IT in small, reasonably priced doses. Even a company without the resources to purchase and maintain a backroom server can purchase a cloud backup service for an affordable monthly sum.

Two factors are driving this demand from SMBs: the capital costs for a corporate owned data center, an insurmountable barrier for small firms, is now spread out over a large customer base. The service provider takes care of finding financing for the infrastructure acquisition and converts these costs to a monthly fee. The second factor is that although demand for IT services in any single SMB may be small when compared with a large company the aggregate demand is enormous as evidenced by the US Small Business Administration data, and hence serving the SMB segment can be a profitable endeavor. Companies like N-Able, CoSentry and Dataprise actually target small businesses.

Hosted servers may be an alternative. However if an IT department consists of two or three people, there may not be enough time or expertise to nurse the equipment through the entire life cycle and maintain the applications that run on them.

The dynamic playing out is that if a service can be delivered in small doses, the services used by large firms under the inside out SOA model are just as good for SMBs, and hence third party service providers enjoyed an additional tailwind coming from small businesses.

On the supply side, demand from SMBs represents a significant driver for the IT economy and presents opportunities to software and service developers in the supply chain. On the demand side we can safely claim that the IT economy has effectively reached not just SMBs but individual consumers as well. An individual consumer also follows this service model whenever she downloads a mobile application from the iPhone App Store or from Google Play, installs a Dropbox file hosting instance or activates Windows Skydrive. This practice is so commonplace today that it’s hard to imagine how revolutionary and how recent the concept is. Google Play started in 2012 and the “grandfather” of the app store, iPhone started in 2008. See Figures 1 and 2.

Figure 1. Web Search Interest for “Google Play”. Source: Google.

Figure 2. Web Search Interest for “Apple App Store”. Source: Google

Figure 3 illustrates the outside-in service integration process where a business application is built out of one or more service components available from a portal such as Intel® API Manager. The central application core described in the previous article that gets smaller as services get outsourced no longer exists. Instead applications are built from third party services, or more appropriately “servicelets” from the ground up.

Figure 3. A Compound Application with no Central Core

Given the “outside-in” potential, we conjectured back in 2008 that SOA would flourish in small organization environments as well. See the book “The Business Value of Enterprise Service Grids”, Intel Press. This prediction came to be, but with a twist: these service components live today in the cloud.

The democratization of SOA has taken a different dynamic: SOA has fled the enterprise and instead of reuse from within, or across organizations in large enterprises, a condition we thought necessary for critical mass for adoption, the critical mass actually happened across whole ecosystems, not just a single enterprise. In the process, these service components are remaking the IT industry and touching service consumers, providers and developers all the same. This dynamic essentially defines the third incarnation of the service ecosystem.

In the book, we proposed a model for SOA deployment that depended on a variety of ecosystem players providing composite applications that are used to build more complex SOA-style composite applications. Today we call these players cloud service providers or CSPs. Under this environment we can expect a degree of specialization where the individual services are provided by smaller players with the appropriate expertise. This situation is illustrated in the figure below.

To distinguish this approach from the traditional “internal only” or “inside-out” approach to SOA specific to large enterprises, we call it outside-in SOA.

The end state is a rich, diverse economic ecosystem with an excellent impedance match between technology and business needs

Who has a vested interest in making the transformation to outside-in SOA take place? It is a truism in an economic ecosystem that the cost equation for some players translates into an identical revenue consideration for another player. The whole ecosystem benefits when the value received greatly exceeds the cost expended for purchasers, and when sellers realize additional demand for products and services because of this value.

Consumers of services stand to gain because of the lower cost overall for procuring application capabilities via composite applications through composite services. SMBs get access to capabilities otherwise they could not afford. Large enterprises and service providers can generate additional cash flow from reduced capital expenses.

Canonical service components, i.e., services designed as services from the ground up, are not essential to make this scheme work. The traditional stovepiped applications in can be retrofitted through middleware shims to behave as composable services, in a manner not unlike screen scraping programs are used to extend the life and usefulness of legacy mainframe applications. The barriers to the outside-in model are lower than they appear at first analysis because the industry does not need to wait until a large repertoire of canonical reusable services becomes available.

The dynamic of this process is that as service economy matures, services will become and will be traded as commodities. This is leading to varying degrees of specialized providers. It simply will be cheaper to build specific functionality by contracting out constituent components in the marketplace rather than build the same functionality wholly in house.

The outside-in approach differs from traditional outsourced arrangements: the negotiation of an outsourced payroll function may involve months and real people at the table. On the other hand, outside-in transactions will be eminently automated, machine to machine and highly dynamic through automated registries and discovery services and using open standards. One such transaction might take from a fraction of a second to no more than a few seconds.

The externalization of service components allowing the quick assembly of applications from third party offerings brings challenges to service providers, developers and consumers alike. We will cover some of these issues in Part 4.

]]>http://blogs.intel.com/application-security/2013/03/28/from-esbs-to-api-portals-an-evolutionary-journey-part-3/feed/0From ESBs to API Portals, an Evolutionary Journey Part 2http://blogs.intel.com/application-security/2013/03/04/from-esbs-to-api-portals-an-evolutionary-journey-part-2/
http://blogs.intel.com/application-security/2013/03/04/from-esbs-to-api-portals-an-evolutionary-journey-part-2/#commentsMon, 04 Mar 2013 22:32:07 +0000http://blogs.intel.com/security-gateways/?p=737In this article series we would like to build a case that API portals, with the Intel® API Manager and Intel® Expressway Service Gateway, powered by Mashery are representative examples, are the contemporary manifestations of the SOA movement that transformed IT … Read more >

]]>In this article series we would like to build a case that API portals, with the Intel® API Manager and Intel® Expressway Service Gateway, powered by Mashery are representative examples, are the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s execution of a business strategy and revenue generation. In the introductory article in Part 1 we discussed some of the business dynamics that led to cloud computing and the service paradigm. Let’s now take a closer look at the SOA transformation in the big enterprise.

If we look at the Google Webtrends graph for the term “SOA”, we can use the search popularity as an indicator of the industry we can see that the interest in SOA peaked at around 2007, just as the interest on cloud computing started rising. There was a brief burst of interest on this term at the end of 2012 which can be attributed at people looking for precedents in SOA as the industry moves to cloud services.

Figure 1. Google Webtrends graph for “SOA.”

Figure 2. Google Webtrends graph for “Cloud Computing.

The search rate for the term “cloud computing” actually peaked in 2011, but perhaps unlike SOA, the trend is not an indication of waning interest, but that the focus of interest has shifted to more specific aspects. See for instance the graphs for “Amazon AWS” and “OpenStack”.

Figure 3. Google Webtrends graph for “Amazon AWS.”

Figure 4. Google Webtrends graph for “OpenStack.”

SOA brought a discipline of modularity that has been well known in the software engineering community for more than 30 years, but had been little applied in corporate-wide IT projects. The desired goal for SOA was to attain a structural cost reduction in the delivery of IT services through re-use and standardization. These savings needed to be weighed against significant upfront costs for architecture and planning as well as from the reengineering effort for interoperability and security. The expectation was a per instance lower cost from reuse in spite of the required initial investment.

Traditionally, corporate applications have been deployed in stovepipes, as illustrated in Figure 5 below, one application per server or server tier hosting a complete solution stack. Ironically, this trend was facilitated by the availability of low-cost Intel-based high volume servers starting fifteen years ago. Under this system physical servers need to be procured, a process that takes anywhere from two weeks to six months depending on organizational policies and asset approvals in effect. When the servers become available, they need to be configured and provisioned with an operating system, database software, middleware and the application. Multiple pipes are actually needed to support a running business. For instance, Intel IT requires as many as 15 staging stovepipes to phase in an upgrade for the Enterprise Resource Planning (ERP) SAP application. The large number of machines needed to support most any corporate application over its life cycle led to the condition affectionately called “server sprawl.” In data centers housing thousands if not tens of thousands of servers it is not difficult to lose track of these assets, especially after project and staff turnover from repeated reorganizations and M&As. This created another affectionate term: “zombies.” These are forgotten servers from projects past, still powered up, and even running an application, but serving no business purpose.

Figure 5. Traditional Application Stovepipes vs. SOA.

With SOA, monolithic applications are broken into reusable, fungible services as shown on the left side of Figure 6 below. Much in the same way server sprawl used to exist in data centers, so it was with software, with multiple copies deployed, burdening IT organizations with possibly unnecessary licensing costs, or even worse, with shelfware, that is, licenses paid for software never used. As an example, in a stovepiped environment each application that requires the employee roster of a company, namely user accounts, phone directory, expense reporting, payroll would each require a full copy of the employee information database. In addition to the expense of the extra copies, the logistics of keeping each copy synchronized would be complex.

What if instead the need to replicate the employee roster somehow it was possible to build a single copy where every application needing this information can “plug in” into this copy and use it a needed. There are some complications: the appropriate access and security mechanisms need to be in place. Locking mechanisms for updates need to be implemented to ensure integrity and consistency of the data. However the expense of habilitating the database for concurrent access is still significantly less than the expense of maintaining several copies.

If we access this new single-copy employee database through Web Services technology, using either SOAP or REST, we have just created a “service”, the “employee roster service”. If every application layer in a stack is
re-engineered as a service with possibly multiple users, the stacks in Figure 5 morph into a network as shown in the left part of Figure 6. The notion of service is recursive where most applications become composites of several services and services themselves are composites of services. Any service can be n “application” if it exposes a user interface (UI) or a service proper if it exposes an API. In fact a service can be both, exposing multiple UIs and APIs depending on the intended audience or target application: it is possible to have one API for corporate access and yet another one available to third party developers of mobile applications.

Applications structured to operate under this new service paradigm are said to follow a service oriented architecture, commonly known as SOA. The transition to SOA created new sets of dynamics whose effects are still triggering change today. For one thing, services are loosely coupled, meaning that as long as the terms of the service contract between the service consumer and the service provider does not change, one service instance can be easily replaced. This feature simplifies the logistics of deploying applications enormously: a service can be easily replaced to improve quality, or ganged together with a similar service to increase performance or throughput. Essentially applications can be assembled from services as part of operational procedures. This concept is called “late binding” of application components.

Historically binding requirements have been loosened up over time. In earlier times most applications components had to be bound together at compile time. This was really early binding. Over time it became possible to combine precompiled modules using a linker tool and precompiled libraries. With dynamically linked libraries it became possible to bind together binary objects at run time. However this operation had to be done within a given operating system, and allowed only within strict version or release limits.

We can expect even more dynamic applications in the near future. For instance, it is not hard to imagine self-configuring applications assembled on the fly and real time on demand using a predefined template. In theory these applications could recreate themselves in any geographic region using locally sourced service components.

There are also business considerations driving the transformation dynamics of application components. Business organizations are subject to both headcount and budgetary constraints for capital expenses. Under these restrictions it may be easier for an organization to convert labor and capital costs into monthly operational expenses by running their services on third party machines hiring Infrastructure as a Service (IaaS) cloud services, or take one step further and contract out the complete database package to implement the employee roster directly from a Software as a Service (SaaS) provider. All kinds of variations are possible: the software service may be hosted on infrastructure from yet another party, contracted by either the SaaS provider or the end user organization.

The effect of the execution of this strategy is the externalization of some of the services as shown in the right hand side of Figure 6. We call this type of evolution inside-out SOA where initially in-sourced service components get increasingly outsourced.

Figure 6. The transition from internal SOA to inside-out SOA.

As with any new approach, SOA transformation required an upfront investment, including the cost of reengineering the applications and breaking them up into service components, and in ensuring that new applications themselves or new capabilities were service ready or service capable. The latter usually meant attaching an API to an application to make the application usable as a component for a higher-level application.

Implementation teams found the extra work under the SOA discipline disruptive and distracting. Project participants resented the fact that while this extra work is for the “greater good” of the organization, it was not directly aligned with the goals of the project. This is part of the cultural and behavioral aspects that a SOA program needs to deal with, which can be more difficult to orchestrate than the SOA technology itself. Most enterprises that took a long term approach and persisted in these efforts eventually reached a breakeven point where the extra implementation cost of a given project was balanced by the savings by reusing past projects.

This early experience also had another beneficial side effect that would pave the way to the adoption of cloud computing a few years later: the development of a data-driven, management by numbers ethic demanding quantifiable QoS and a priori service contracts also known as SLAs or service level agreements.

While the inside-out transformation just described had a significant impact in the architecture of enterprise IT, the demand for third party service components had an even greater economic impact on the IT industry as a whole, leading to the creation of new supply chains and with these supply chains, new business models.

Large companies, such as Netflix, Best Buy, Expedia, Dun & Bradstreet and The New York Times found that the inside-out transformative process was actually a two-way street. These early adopters found that making applications
“composable” went beyond saving money; it actually helped them make money through the enablement of new revenue streams: the data and intellectual property that benefited internal corporate departments was also useful to external parties if not more. For instance an entrepreneur providing a travel service to a corporate customer did not have to start from ground zero and making the large investment to establish a travel reservation system. It was a lot simpler to link up to an established service such as Expedia. In fact, for this upstart did not have to be bound by a single service: at this level it makes more economic sense to leverage a portfolio of services, in which case the value added of this service upstart is in finding the best choices from the portfolio. This is a common pattern in product search services whose function is to find the lowest price across multiple stores, or in the case of a travel service, the lowest priced airfare.

The facilitation of the flow of information was another change agent for the industry. There was no place to hide. A very visible example is effect of these dynamics on the airline industry, and how it changed irrevocably, bringing up new efficiencies but also significant disruption. The change empowered consumers, and some occupations such as travel agents and car salespeople were severely impacted.

Another trend that underlies the IT industry transformation around services is the “democratization” of the services themselves: The cost efficiencies gained not only lowered the cost of business for some expensive applications accessible only to large corporations with deep pockets; it made these applications affordable to smaller businesses, the market segment known as SMBs or Small and Medium Businesses. The economic impact of this trend has been enormous, although hard to measure as it is still in process. A third wave has already started, which is the industry’s ability to reduce the quantum for the delivery of IT services to make it affordable to individual consumers. This includes social media, as well as more traditional services such as email and storage services such as Dropbox. We will take a look at SMBs in Part 3.

]]>http://blogs.intel.com/application-security/2013/03/04/from-esbs-to-api-portals-an-evolutionary-journey-part-2/feed/0From ESBs to API Portals, an Evolutionary Journey, Part 1http://blogs.intel.com/application-security/2013/02/26/from-esbs-to-api-portals-an-evolutionary-journey-part-1/
http://blogs.intel.com/application-security/2013/02/26/from-esbs-to-api-portals-an-evolutionary-journey-part-1/#commentsTue, 26 Feb 2013 18:56:25 +0000http://blogs.intel.com/security-gateways/?p=662A number of analysts are beginning to suggest 2013 will likely signal the awakening of a long night in the IT industry that started with the beginning of the third millennium with the Internet crash. And just as recovery was … Read more >

]]>A number of analysts are beginning to suggest 2013 will likely signal the awakening of a long night in the IT industry that started with the beginning of the third millennium with the Internet crash. And just as recovery was around the corner, the financial crisis of 2008 dried the IT well once more. Both crises can be characterized as crises of demand. Just past 2000, the Y2K pipeline ran dry. Some argue that the problem was overstated, whereas others argue that the problem was solved just in time. In either case this event triggered a significant pullback in IT spending.

Faced with an existential threat after Y2K, the IT industry did not sit still. The main outcome from these lean years has been a significant increase in efficiency where the role of IT in companies with most advanced practices shifted from being a cost center to an active participant in the execution of corporate business strategy. Capabilities evolved from no accountability on resource utilization to efficient use of capital to nimble participant in a broad range of organizations and initiatives. The second crisis reaffirmed the continuing need to do more in the face of shrinking budgets and very likely provided the impetus for the widespread adoption of cloud technology.

The state of the art today is epitomized by cloud computing under the service paradigm. From a historical perspective the current state of development for services is in its third iteration.

The early attempts came in various forms from different angles and as many vendors. The most prominent examples of this era came from application server and connectivity ISVs (independent software vendors) and from operating system vendors: Microsoft, IBM, TIBCO and various Unix vendors of that era. The main characteristic of this era that went roughly from 1995 to 2005 was single-vendor frameworks with vendors attempting to build ecosystems around their particular framework. This approach did not take off, partly because concerns in IT organizations about vendor lock-in and because the licensing costs for these solutions were quite high.

The second era was the era of SOA that lasted roughly from 2000 to 2010. The focus was to re-architect legacy IT applications from silo implementations to collections of service components working together. Most of the service components were internally sourced, resulting perhaps from the breaking former monoliths, and combined with a few non-core third party services. Vendors evolved their offerings so they would work well in this new environment. The technology transformation costs were still significant as well as the demand on practitioners’ skills. Transformation projects required a serious corporate commitment in terms of deferrals to accommodate process reenginering, licensing fees and consulting costs. As a result, the benefits of SOA were available only to large companies. Small and medium businesses (SMBs) and individual consumers were left out of the equation.

Cloud technology drives the current incarnation for IT services following the crisis of 2008. Clouds notwithstanding, if we look at the physical infrastructure for data centers, it is not radically different from what it was five years ago, and there are plenty of data centers five years ago or older still in operation. However, the way these assets are organized and deployed is changing. Much in the same way credit or other people’s money drives advanced economies, with the cloud other people’s systems are driving the new IT economy.

Scaling a business often involves OPM (other people’s money), through partnerships or issuing of stock through IPOs (initial public offerings). These relationships are carried out within a legal framework that took hundreds of years to develop.

In the real world, scaling a computing system follows a similar approach, in the form of resource outsourcing, such as using other people’s systems or OPS. The use of OPS has a strong economic incentive: it does not make sense to spend millions of dollars in a large system for occasional use only.

Large scale projects, for instance a marketing campaign that requires significant amounts of computing power are peaky in the usage of infrastructure assets, usually start with small trial or development runs, with large runs far and few between. A large system that lies idle during development would be a waste of capital.

Infrastructure sharing across a pool of users increases the duty cycle of infrastructure assets through the sharing of these assets with multiple users. Cloud service providers define the sandbox whereby a number of corporate or individual users have access to this infrastructure. Cloud computing increases the efficiency of capital use through resource pooling delivered through a service model.

The first step in the infrastructure transformation came in the form of server consolidation and virtualization technology. After consolidation became a mainstream IT practice, the trend has been toward the support of more dynamic behaviors. IaaS allows the sharing of physical assets not just within the corporate walls, but across multiple corporate customers. A cloud service provider takes a data center, namely $200 million asset and rents individual servers or virtual machines running inside them by the hour, much in the same way a jet leasing companies takes a $200 million asset, namely an airliner and leases it to an air carrier which otherwise would not be able to come up with the upfront capital expense. The air carrier turns around and sells seats to individual passengers, which is essentially renting a seat for the duration of one flight.

In other words, the evolution we are observing in the delivery of IT services is no different than the evolution that took place in other, more mature industries. The processes that we are observing with cloud computing and associated service delivery model is no different than the evolution of the transportation industry, to give one example.

As we will see in the next few articles, the changes brought by the cloud are actually less about technology and more about the democratization of the technology: the quantum for delivery used to be so large that only the largest companies could afford IT. Over the past few years IT became accessible to small and medium businesses and even individual consumers and developers: businesses can purchase email accounts by the mailbox with a monthly fee, and deployment models allow individual consumers to sign up for email accounts at no out of pocket cost. We will look at the evolution of the service model from a corporate privilege to mass availability. From a practical, execution perspective, products like the Intel® Expressway Service Gateway and Intel® API Manager were developed to support the life cycle of cloud enabled applications, and I’ll be pointing to aspects of these products to provide specific examples of the concepts discussed.

In the next article we’ll discuss the “big guns” services represented by the SOA movement in the first decade of the millennium.