Date post: | 13-Jul-2015 |
Category: |
Technology |
Upload: | apigee |
View: | 3,510 times |
Download: | 1 times |
Bending the SpoonTransition from SOA to APIs for the App Economy
Apigee
@apigee
Brian Pagano
@brianpagano
David Andrzejek
@davidandrz
SOA adventures in API-land
SOA - does it mean what you think it means?
All the checkboxes
Transactions – working hand-in-hand
Making the world awesome - one API at a time
Overview
The “spoon” is the company’s SOA-based architecture
It made sense at the time. And it still makes sense for some functions
But rapidly evolving businesses have new requirements
Why are we talking about spoons?
Bend the spoon and hope it doesn’t break
Bend the world around the spoon
The Architect has two choices
Let’s make sure we’re all talking about the same thing
Let’s only talk about the core principles of SOA - not the cruft that vendors have added
Some product features have started to be thought of as necessary for SOA
SOA recap
SOA is Service Oriented Architecture
Services are good
Tapping into the deeper philosophy of breaking down problems into components
Components are good
SOA might include, but does not require
Heavyweight contracts
Service registries
Dynamic discovery
These are product “features”
* Not completely satisfied using SOA alone
Core SOA Functionality
Business Problem Core SOA Principle
Consistent look and feel for customers across lines of business
Reusable software components (services)
Cross selling between lines of business *Reusable services
Auditing and compliance Guaranteed asynchronous message delivery helps for non-repudiation
The ability to perform complicated, multi-step transactions
Message Bus + stateful services
Agility *Reusable services
The architect is being asked to deploy functionality to mobile devices
Worse, the business wants to deploy to multiple channels simultaneously
And timelines are getting crunched to accommodate partners, conferences, and events
Patterns have emerged* to try to solve these new requirements using existing SOA tools. They work up to a point.
The problem is that bolting on active listener functionality to services or forcing them to implement elaborate configuration frameworks or become temporal event handlers seems contrary to having coarse grained service that are experts for a specific problem.
*SOA Patterns by Arnon Rotem-Gal-Oz for some examples
What’s worse is that some folks have lost sight of the need to expose functionality not systems
Nobody wins through exposing complexity
These are requirements of today’s projects
We don’t have time to go into each of these today
But . . .
The architect should think deeply about the checkbox items when designing the path from point A to point B
Modern apps need more than forklifting existing systems* and their complexities
*This is known at the “forklift anti-pattern”.
Agile layer (changes are fast)
Highly consumable
Omnichannel
Lightweight
Highly scalable
What are APIs good at?
For example
Complex or stateful transactions:
Let the API layer handle exposure, transformation, security, caching, and scaling
Then pass the request to the SOA/integration layer
Moving forward means satisfying the checkboxes (agility, scalability, …) without creating disruption
This often means changing our thinking from exposing services to exposing functionality
Getting from Point A . . .
And moving from the minimum necessary to get something exposed (avoiding the forklift anti-pattern)
to
providing everything that will be sufficient to bring our businesses into the app economy
. . . to Point B
analytics to give us visibility into behavior on mobile devices
providing the modern app functionality which is often absent in our existing systems (location, notifications, ...)
. . . and beyond
To meet changing business demands:
Expose functionality not systems
Use APIs to leverage & extend existing SOA assets
Use APIs for analytics – end to end visibility into your business from the backend to mobile apps
Use APIs for innovation - modern app functionality
In Summary