For a long time APIs have largely been an exercise at the edge of complexity. They provide an engaging interface to attract developers, perhaps an underlying platform to monitor their consumption, and a means for those interested in whatever drives our backend to manage that success. That type interaction demands a certain type of interaction. But what happens in a backend world of microservices? Do we really have the same API needs and flexibility concerns at the mesh that we do at the edge and how might we best address these two worlds going forward? I will present the case for edge, the case for the mesh and try to bridge whatever space we have between them: chasm or ditch.
3. 3
New API tier – Foundation for systems of engagementPaceof
change
SYSTEMS OF RECORD
Days
Number of
Interactions
Years
Number of
Transactions &
Integrations
ESB / Integration Tooling
HRCRM Financials Inventory Supply Chain
Intelligent API Platform
Security Persistence Scalability Analytics Developer Mgmt.
Partner AppsCollaboration Apps Customer Apps Omni Channel
SYSTEMS OF ENGAGEMENT
Employee Engagement
4. 4
Digital value chain is the engine of transformation
User Experience Developer API Platform API Team
Legacy
Backend
Microservices
• Standard Aware APIs
• Access Type specific onboarding flow
• Monetization, protection, Analytics and
more
• Quick Onboarding: Auto-approval :
• Learn fast: Smartdocs Business APIs
• Usage Analytics Reporting
• User controlled access
to apps via consent
• Multi-Channel Access
Consumption Exposure
6. 6
API Consumers API Providers
API Product
Manager
Create solutions
using APIs
Create APIs
Build and run the
systems than run APIs
API
APIs
as Products
Developer Developer
7. 7
Transfer ownership of
something from one account
to another.
Go find the account.
Is it the right type of account?
Is it the right type of thing?
Can I transfer the thing?
Is either account in arrears?
What US state is each account
in?
Is either account promotional?
… and so on.
Developers should care
about this:
Not this:
9. 9
Changing Landscape
More law, less justice
-- Marcus Tullius Cicero
Microservices DevOps
Cloud Service
Brokers
Governance
10. 10
Governance: with small ‘g’ in stead
Governance
• Rigid control at every level
• Don’t trust your developers
• Security over speed
• Plan to be in place for years and
years
• Here we develop in COBAL!
governance
• Patterns over control
• Flexibility over rigidid structure
• Speed over security
• Given the penchant for speed we
can reinvent when needed
• Contracts between services matter
but not the language people
develop in
11. 11
What are microservices
An official definition of microservices:
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a
collection of loosely coupled services, which implement business capabilities. The microservice architecture enables
the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its
technology stack.
My pragmatic and working definition for cloud based microservices
An approach to software development where small, isolated, and independently deployable services are woven
together to build rich applications that feel stateful and monolithic. Microservices own their data and only allow other to
access that data (read or write) via a well known contract: an API
And what it isn’t:
A design decision for using k8s
12. 12
Microservices design pattern
● Services own their
contract
● Services own their data
model
● Services own their
deployment description
node
Data
@rest
java
Data
@rest
golang
Data
@rest
Microservice 1 Microservice 3Microservice 2
13. 13
Clouds and Brokers
Clouds
• Nebulous definition of hardware
•Software at the world,
remember?
• Private and public
• Converging technologies
• Separated
Brokers
• Act as a liaison between clouds
• Different cloud services rely on
different brokers
• Brokered services can be defined
and consumed between clouds
14. 14
Devops
Evolving on it’s own…
From automation in lieu of
documentation
To
Deliver responsibility for at least
deployment pieces of ops.
16. 16
Different needs for Edge and Mesh
Edge
• Mashups
• Security facades
• Transformations and mediations
• Client requested formats
• APIs as products
Mesh
• Focus on analytics
• Simple security enforcement
• Canary bird rollouts
• No need for client requested
formats
• No need for complex mediation
23. 23
Digital value chain is the engine of transformation
User Experience Developer API Platform API Team
Legacy
Backend
Microservices
• Standard Aware APIs
• Access Type specific onboarding flow
• Monetization, protection, Analytics and
more
• Quick Onboarding: Auto-approval :
• Learn fast: Smartdocs Business APIs
• Usage Analytics Reporting
• User controlled access
to apps via consent
• Multi-Channel Access
Consumption Exposure