Adopting the Infrastructure Cloud Services Model
Adopting the Infrastructure Cloud Services Model
Join the DZone community and get the full member experience.Join For Free
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.
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.
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 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
- 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
Published at DZone with permission of Chris Haddad , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.