Infrastructure Services Model Layers

Infrastructure Cloud Services Model

Cloud API popularity is fueling interest in creating service ecosystems across organizations, teams, and applications.  By externalizing software platform functions from containers, operating systems, and on-premise data center environments, new business opportunities emerge, and development teams gain faster time to market when building scalable business solutions. Is the time right for you to build a cloud ecosystem architecture  based on APIs and supporting rapid application development?

Anne Thomas Manes, Nick Nikols, the Burton Group / Gartner team, and I have been promoting Cloud APIs and ecosystem models since 2004 through 2009 and beyond. The visionary concept is reaching mainstream awareness and viable, enterprise-ready APIs exist today. The time is right for teams to adopt an  Infrastructure Services Model perspective and Identity Services.

The Cloud Services Driven Development Model

Ron Miller (@ron_miller) at @Techcrunch is promoting how open apis fuel creation of new cloud services ecosystems.  Andre Durand, CEO of Ping Identity, and long-term Gartner Catalyst attendee describes the current innovation cycle:

Every technology innovation cycle brings to the forefront not only a new paradigm for computing but also a new set of leaders optimized for delivering it. The generation that preceded the next never establishes their preeminent position. We saw it with big iron vendors as we shifted to a PC-centric client/server world, and then with cloud apps against traditional enterprise app vendors, and now with mobility and the API economy.

To compete and lead in today’s ecosystem environment, architecture teams and vendors must decouple non-business infrastructure services from the operating system, containers, and data center environments.  By offering administrative, management, security, identity, communication, collaboration, content, and infrastructure resource capabilities via Cloud service APIs, teams can rapidly compose best-of-breed solution stacks.  Mike Loukides (@mikeloukides)  is calling the API-first (or service-first) environment the distributed developer stack (DDS).  According to Mike,
These [solutions] rely on services that aren’t under the developer’s control, they run on servers that are spread across many data centers on all continents, and they run on a dizzying variety of platforms.
Matt Dixon (@mgd) clearly defines a similar goal state in his architecture services in the cloud post:

One basic design objective is that all functions will be exposed as secure API’s that could be consumed by web apps or mobile apps as needed.

Back in 2004-2005, Anne and I called the stack the ‘Network Application Platform’ (similar to the Cloud Application Platform moniker used today).   According to this newly popular computing paradigm, a cloud API model applies SOA principles (i.e. loose coupling, separation of concerns, service orientation) to infrastructure functions (e.g. security, resource allocation, identity) and delivers a consistent, abstract interface across boundaries (e.g. technology, topology, domains, ownership).   By consuming  infrastructure functions as cloud APIs, developers can build solutions that scale across hybrid cloud environments while enabling consistent application of policy-driven management and control, and automatic policy enforcement.   By tapping into a cloud API model, teams can readily access infrastructure functions as easy as network access services (e.g. DNS, smtp), and DevOps administrators can centrally define policies that are propagated outward across multiple cloud application environments.

Cloud API Promise

At WSO2, we are currently working with many teams building Identity and security APIs.    Identity APIs make identity management capabilities available across the application portfolio and solution stack.  The API can readily apply consistent identity based authorization and authentication decisions based on role based access control (RBAC) and attribute based access control (ABAC) policies.  Cloud security APIs centralize authentication, authorization,  administration, and auditing outside discrete, distributed application silos.

Policy-driven Management, Control, and Automatic Policy Enforcement

By centralizing policy management and control, application developers move away from hard-coding policy and rules within application silos. Subject matter experts (e.g. security architects, cloud administrators) can centrally define declarative policies that are provisioned across distributed policy enforcement points.

Policy-driven Management and Control

By centralizing policy administration, smartly centralizing policy decision points, and distributing policy-driven management, security, and control, cloud service interactions across domains can rely on consistent policy enforcement and compliance.

For example, a DevOps team member may author a policy stating when compute resources should spin up across zones, how traffic should be directed based on least-cost rules.  Security architects may define information sharing rules based on both identity attributes and resource attributes.

Cloud APIs separate policy decision points (PDP) from policy enforcement points (PEP), and apply the SOA principle of ‘separation of concerns’.    By separating PDPs from PEPs and and connecting the two via Cloud APIs, teams can more rapidly adapt policy in response to changing requirements ,rules, or regulations without modifying application endpoints.

Automatic Policy Enforcement

To migrate towards Cloud APIs, applications have to be re-wired to externalize policy decisions and infrastructure capabilities. Instead of calling a local component, application code invokes an external Cloud API.  Ideally, an abstraction layer is placed between the application business logic and infrastructure Cloud APIs, and a configurable interception point will automatically route the resource, entitlement, or identity request to one or many available Cloud APIs.

To aid automatic policy enforcement, implement the inversion of control (IoC) principle within application containers, and add abstraction layers that decouple the platform from diverse back-end Cloud API interfaces that may vary location and message formats.

Cloud API Layers and Ecosystem Opportunity

Consider developing vertical ecosystem platforms and business as a service offerings, where your team externalize both business capabilities and platform functions across business partners, suppliers, distributors, and customers.  A vertical ecosystem platform is the pinnacle of a connected business strategy.

Cloud APIs are layered, and development teams must carefully build distributed developer stacks by stacking APIs that consistently apply policy definitions (see Figure 1).  For example, consider stacking Container APIs, Function APIs, Control APIs, Foundation APIs, and System APIs that consistently apply identity, entitlement, and resource allocation policies.
Infrastructure Services Model Layers
Figure 1. Infrastructure Services Model Layers: Source: Gartner Infrastructure Services Model Template and Catalyst Presentations

Cloud API Frontier

Build cloud-aware applications that scale across hybrid clouds by incorporating cloud APIs instead of platform-specific, local APIs. To start a migration towards Cloud Apis,

1. Define a Cloud API portfolio across the following capability areas:

  • Communication Infrastructure
  • Collaboration Infrastructure
  • Content Infrastructure
  • Web Access Management [authentication, authorization, audit, single sign-on]
  • Identity, Attributes, and Entitlements
  • Policy Administration
  • Monitoring
  • Provisioning
  • Resource allocation (compute, network, storage)

2. Centralize policy administration and establish consistent policy definitions

3. Incorporate policy enforcement points that delegate policy decisions to external Cloud APIs.

4. Monitor cloud api usage, policy compliance, and application time to market



Gartner’s Infrastructure Services Model Template

Matt Dixon on Anne’s 2008 Catalyst Presentation detailing Infrastructure Services

Architecture Services in the Cloud

Nishant on Identity Services


One thought on “Infrastructure Cloud Services Model

Comments are closed.