+ All Categories
Home > Technology > Transition from SOA to APIs for the App Economy - Bending the Spoon

Transition from SOA to APIs for the App Economy - Bending the Spoon

Date post: 13-Jul-2015
Category:
Upload: apigee
View: 3,510 times
Download: 1 times
Share this document with a friend
Popular Tags:
52
Bending the Spoon Transition from SOA to APIs for the App Economy Apigee @apigee Brian Pagano @brianpagano David Andrzejek @davidandrz
Transcript

Bending the SpoonTransition from SOA to APIs for the App Economy

Apigee

@apigee

Brian Pagano

@brianpagano

David Andrzejek

@davidandrz

groups.google.com/group/api-craft

youtube.com/apigee

slideshare.net/apigee

@brianpaganoBrian Pagano

@davidandrzDavid Andrzejek

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

SOA Adventures in API-Land

A man is sitting at a table, staring at a spoon

He seems to be doing nothing, but his forehead starts to sweat

The man is trying to bend the spoon

You can’t bend a spoon using only your mind

Two problems . . .

Bending the spoon manually weakens the structure and mangles the spoon

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 talk about bending the world

SOA: Advanced Patterns

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

So far, so good

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

Should we try to bend the spoon?

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

Nobody benefits from mangled spoons*

* Except maybe spoon manufacturers

All The Checkboxes

Agility

Security

Performance

Data

Mobile visibility

Modern application functionality

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

You may have some of the necessary pieces . . .

but that is not sufficient

Modern apps need more than forklifting existing systems* and their complexities

*This is known at the “forklift anti-pattern”.

It’s time to move the world around the spoon

Let’s look at using APIs to extend SOA into this new world

Transactions:Working Hand In Hand

Decoupling producers and consumers

Complex transactions

What is SOA good at?

Agile layer (changes are fast)

Highly consumable

Omnichannel

Lightweight

Highly scalable

What are APIs good at?

Sometimes APIs and SOA work beautifully together

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

Making the World AwesomeOne API at a Time

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

Security

Big Data vs. Fast Data

Performance

Mobile and Modern App Functionality

Future deep dives

Questions

groups.google.com/group/api-craft

THANK YOUQuestions and ideas to:

@brianpagano

@davidandrz

groups.google.com/group/api-craft


Recommended