Downloaded 161 times
Uploaded byChris Haddad
SOA and API Convergence Strategy and Tactics
The document by Chris Haddad discusses the convergence of SOA (Service-Oriented Architecture) and APIs (Application Programming Interfaces), providing strategies for effective adoption and implementation. It highlights the importance of cross-functional collaboration, gradual implementation, and pragmatic design principles to enhance service reusability and governance. Additionally, it outlines approaches for API management and the distinction between services and APIs in their lifecycle and governance.
More Related Content
Similar to SOA and API Convergence Strategy and Tactics
SOA and API Convergence Strategy and Tactics
- 1. VP Platform Evangelism ChrisHaddad SOA and API Convergence 21 May 2014
- 2. 2 About the Presenter ๏Chris Haddad ๏ VP Platform Evangelism ๏ F500/G2000 Advisor, Cloudy DevOps for Dev guy ๏ Learn more about me ๏ Follow me ๏ @cobiacomm on Twitter ๏ Blog: http://blog.cobia.net/cobiacomm ๏ Profle: http://www.linkedin.com/in/cobiacomm/ ๏ On Google+ too
- 3. Invention comes inmany forms and at many scales. The most radical and transformative of inventions are often those that empower others to unleash their creativity – to pursue their dreams. Jeff Bezos
- 5. Tired of BigSOA? ๏ Set up a cross-functional SOA Working Group ๏ Develop a SOA Adoption Plan ๏ Define Target Service Portfolio ๏ Develop a Business Case ๏ Plan and Fund Development of SOA Infrastructure ๏ Establish New Roles ๏ Plan Training and Mentoring for Staff ๏ Develop Corporate Policies, Guidelines, and Best Practices ๏ Institute SOA Governance Processes ๏ Establish New Incentives that Reward Good Behavior ๏ Identify Candidate Projects ๏ Establish Priorities ๏ Reassess Your Software Development LifeCycle (SDLC)5
- 6. Start Small ๏ ImplementSOA principles on a project-by-project basis ๏ Focus on run-time environment concerns instead of design- time concerns. ๏ Successful IT-driven Small SOA teams promote consumer adoption stories, track service subscribers, and publicize usage growth. 6
- 7. Pragmatic SOA ๏ Shareand reuse assets ๏ simplify best practice adoption by mentoring teams and delivering automated governance ๏ balance enterprise governance with project autonomy ๏ Consolidate redundant functionality into fewer moving parts ๏ offer accelerator packs (i.e. infrastructure, tooling, frameworks, and API/service building blocks) ๏ Conform projects to common standards and best practices ๏ Don’t force common (yet complicated) standards ๏ mindful of skill gaps and adoption hurdles 7
- 9.
- 10.
- 11.
- 12. 12 API Strategy ๏ Embracethe Managed API ๏ Make APIs Easy for Developers to Access ๏ Employ API Lifecycle Governance ๏ Monitor API Use ๏ Establish a Monetization Model
- 13. Pragmatic API Design ๏Make data and services maximally accessible ๏ Low barrier to entry ๏ Extend reach towards the largest possible audience ๏ Make API/service consumable by the largest number of user agents ๏ Make data and services evolvable ๏ Extend the system at runtime ๏ Alter resources without impacting clients, Direct client behavior dynamically ๏ Make systems scalable, reliable, and high performing ๏ Simple, Cacheable, Atomic 13
- 15.
- 16. Make Service andAPI Capabilities Accessible
- 17. Start collecting andanalyzing subscribers and usage
- 18. SOA & RESTReconciliation ๏ When to create services ๏ Create a service when sharing a business capability ๏ When to create APIs ๏ Sharing a service outside a domain of control ๏ Targeting the widest possible reach and consumption ๏ Offering the service across native web infrastructure ๏ Maximizing asymmetric evolution between service clients, interface, and implementation. 18
- 19.
- 20. SOA & RESTReconciliation ๏ How to approach service and API governance ๏ How services and APIs impact application governance 20
- 21. 21 ๏ Service dealswith implementation ๏ API deals with subscription (consumer) ๏ Two very distinct life cycles ! ๏ You don’t need the service to create the API... Services and APIs
- 22. 22 Accelerate Your ITBusiness Strategy with WSO2 Services
- 23. References ๏ SOA andAPI Convergence Strategy and Tactics ๏ Promoting service reuse within your enterprise and maximizing SOA success ๏ REST Easy: API Design, Evolution, and Connection ๏ WSO2 and API Management A Technical Evaluation Guide 23
- 24.
Editor's Notes
- #5 SOA business perspective and API Economy echo SOA can be a strategy to align IT assets with business capabilities, business resources, and business processes. SOA’s strong focus on sharing and re-use can optimize IT asset utilization. Most intriguingly, SOA was promised to re-invent business-to-business interactions, enable better partner relationships, and support process networks. External services were seen as a mechanism to extend an enterprise’s economic reach by reducing interaction costs, incorporating external business capabilities, enabling business specialization, and creating higher-value solutions that extend business processes across a partner network. The current API economy buzz co-opts the SOA business value proposition, injects lessons learns, and rides popular industry trends (i.e. REST, Internet of Everything, mobile, Cloud services). The Only Sustainable Edge, John Hagel III & John Seely Brown, 2005 http://www.johnseelybrown.com/readingTOSE.pdf
- #7 A Small SOA approach implements SOA principles on a project-by-project basis. This approach incurs less risk, but produces a smaller return. Typically there’s limited coordination across projects, and Small SOA doesn’t require as much cultural, arm-twisting, or political unrest. Using a Small SOA process, the organization can slowly build a portfolio of services, but with limited coordination, the services are less likely to be reusable or shared across multiple consumers. Small SOA initiatives often focus on run-time environment concerns instead of design-time concerns. Popular run-time environment concerns include enabling flexible communication styles, interaction patterns, and mediation mechanisms that facilitate integration and promote loose coupling. Example communication styles include synchronous, asynchronous, one-way, and request response messaging. Commonly supported interaction patterns include peer-to-peer, brokered delivery, hub-and-spoke, publish/subscribe, and orchestrated workflow, which are used to bridge the gap between consumer-provider availability, reliability, and topology. Mediation mechanisms reduce the need to provide symmetric messaging platforms where both consumer and provider communicate using the same protocol, message format, and communication style. Mediation mechanisms also encapsulate implementation details related to location, versioning, and identity domain.
- #13 http://api-management.com/ A managed API is: Actively advertised and subscribe-able Available with an associated, published service-level agreement (SLA) Secured, authenticated, authorized and protected Monitored and monetized with analytics Managed APIs increase adoption by establishing operational visibility and creating a trusted provider-consumer relationship. API management systems automate quality of service (QoS) enforcement, secure and protect the API, monitor usage, and manage access keys. Key management provides a unique key ID for each API subscription. The key supports tracking, reporting, and taking corrective action. If a subscriber overloads the server, the key can be revoked, or the enterprise can charge additional subscription fees for the higher usage rate. It’s not enough for APIs to be readily available. When publishing an API for consumption, governance keeps the environment from devolving into chaos by managing people, policies and processes. API management systems enforce operational controls on essential development lifecycle functions, API versions, and runtime technologies. For example, a team may desire to enforce a specific message payload or interaction pattern. If an API maps back to a mobile phone, a team might want to encourage a simple JSON format and minimize the number of interactions. By contrast, efficient machine-to-machine interaction may require larger transferring larger datasets via XML payloads. Knowing the consumer fosters creating the optimal API interface. Effective API monitoring compliments governance. The best API ecosystems and platforms include measurement tools, metrics, and activity repositories that report back on usage, ecosystem traffic, and referral traffic. Requests and response metrics are germane to understanding how the API works, identifying emerging request trends, and evaluating responsive delivery. Failing to measure and analyze API usage on a daily or weekly basis will inhibit creation of a reliable API and vibrant API community. Access is often a significant API adoption barrier, so provide a self-service, resource-rich environment. Use WSO2 API Manager to expose an “API store.” The API Store application will establish your own API marketplace and promote APIs. Application developers easily find, explore, subscribe, and evaluate APIs within a marketplace experience similar to the Apple AppStore or Google Marketplace. The venue lets developers register as a potential API consumer, obtain API access credentials, and match project requirements to API capabilities. Well-organized support channels and API documentation enable developers to “try before they buy.” A structured API exploration environment rapidly reduces the time and effort required to evaluate and integrate API resources.
- #15 While services should exhibit managed API characteristics, most service endpoints are deployed on platforms that don’t deliver management characteristics. By applying the API façade pattern, teams can layer network addressable endpoints, monitor usage, enforce usage limits, shape traffic, and authorize consumers.
- #17 For Apps, APIs, Mobile, Data, and any digital asset Manages subscriptions and notifications Engages with Social Networks Provides asset governance and access control
- #18 The “Speed Layer” Use the data while it is relevant Geographic and Time based queries Can you handle a million events a second?
- #19 Create a service when sharing business capability or business data across network or run-time application boundaries. A service should implement a reasonably autonomous business task and not be designed as a fine-grained component with interdependencies on other components. Developers and business analysts are more likely to understand the purpose of the service when the service exposes a discrete task within a business process. Designing services for business task granularity reduces the complexity of the service interactions and simplifies application maintenance. Examples of business tasks that are compatible with a service-oriented approach include “submit order,” “retrieve customer record,” and “pay bill.” Create a RESTful API when sharing a service outside a domain of control (i.e. business unit, organization), targeting the widest possible reach and consumption, offering the service across native web infrastructure, or interested in maximizing asymmetric evolution between service clients, interface, and implementation.
- #20 Separating external contract and external protocols from internal representation positively impacts the ability to evolve the service implementation over time. When a clean separation of interface from implementation exists, a developer can modify the implementation without impacting the calling applications that use the service. However, decoupling consumer and provider from a shared application platform, and decoupling interface from implementation raises additional concerns. For example, difficulties arise when attempting to seamlessly flowing operational semantics (i.e. identity, service levels, authorization) across dissimilar platforms and a distributed environment. Teams rely on middleware infrastructure to bridge the semantics across all participating parties and components. Because separating interface from implementation introduces complexity and extra development effort, many teams tightly bind interface to implementation. By following architectural best practices and introducing API facades or proxy endpoints (with development automation), teams increase solution maintainability and adaptability. When development teams publish API facades in front of existing services, they explicitly separate service interface from service implementation. API endpoints are lightweight proxies enforcing security, monitoring usage, and shaping traffic. The proxy enables a clear separation of concern between consumer interface contract and back-end service implementation.