APIS AND MICROSERVICES

What the *&%$ are they?

An introductory presentation by Richard Hudson

Contents

• Setting the scene

• Why all the talk about APIs and microservices … and business agility?

• What are microservices?

• Cohesive, decoupled services …. and a whole business culture

• What are API’s?

• The public face of a microservice ….. and a whole industry

• Summary

• It’s about business agility and competiveness at scale

SETTING THE SCENEWhy the need for agility, innovation and service delivery

The 3rd platform

Driven by evolution of:

• Cloud platforms and marketplaces

• Prevalence of mobile technology

• Social business

• Analytics and customer insights

A platform for rapid innovation

A platform for rapid scale

Digital Transformation

• Forcing a change to the way businesses operate

• How they engage with customers via multiple channels

• The speed at which they deliver products and services

• How they innovate and remain competitive

• The reliability of their operations for 24/7 operation

• Their overall resiliency and longevity

WHAT ARE MICROSERVICES?

One approach for business agility

Microservice summary

“A way to organize teams that mimic the

structure of an organization for greater

autonomy and reduced cross-team

synchronization for the purposes of

scalability, faster solution delivery, and

ability to manage complexity at the expense

of known tradeoffs.” - Christian Posta, redhat

Microservice pattern

“Microservices refer to developing

functionality as a collection of

small services, each running in its

own process and accessed via a

lightweight interface, such as an

HTTP RESTFul API” - Martin Fowler

“Monolithic application has single code base with multiple modules. Modules are divided as either for business features or technical features. It has single build system which build entire application and/or dependency. It also has single executable or deployable binary.”

Contrast with the monolith pattern

Characteristics of a microservice

• Componentization via services

• Organized around business capabilities

• Products not projects

• Smart endpoints and dumb pipes

• Decentralized governance and small, cross-functional teams

• Decentralized data management

• Mature CI/CD practices

• Infrastructure automation and self-service access

• Design for failure

• Evolutionary design

- Based on James Lewis & Martin Fowler

Microservices in action

- Sam Newman and 3scale

Multiple tier architecture

Client Tier

Delivery Tier or

Backend-for-Frontend (BFF)

Perimeter services –

routing, authentication, etc.

Aggregation/federation tier

Services tier

Microservice characteristics

• PROS

• A service has a fixed focus and is relatively easy to understand

• Service can be deployed independently

• Easier to scale development teams

• No commitment to long term technology stack

• CONS

• Additional complexity of a distributed system

• Harder to test

• Data consistency (CAP theory)

• Latency and connection failures

• Operational complexity- James Lewis & Martin Fowler

Aren’t microservices just SoA?

• Maybe…

• More of a subset of SoA

• More specific

• Decentralised governance

• Lighter weight

• BUT…

• Micro services represent a cultural change

Microservices

SoA

WHAT ARE APIS?

API?

• Application Programming Interface (API)

• The means by which one application accesses the resources of another

• Defines information that is externally accessible

• Abstracts the implementation

• It’s a contract defined via endpoints, schema and version

• Its machine readable

• It’s a product with all the developer tools and trimmings

• It’s a commodity – a source of business revenue

What are resources?

• Domain entities that need to be shared externally

How are resources accessed?

• Depends on the approach taken

• For Internet applications they should be “of the web”

• REST style API is a common approach

• Resource representations• XML, JSON

• Http typically used as the protocol on which RESTful APIs

are based• Natural fit for Internet networks and resource manipulation

Resource endpoints

Snippets from Pure Digital Internet radio service

/users/{UserID}/favourites Add content item to user favourites

/users/{UserID}/favourites/{ID} Delete a user favourite

/users/{UserID}/favourites/{ID} Update a favourite

User favourites service

/users/{UserID}/favourites Get all user favourites

/users/{UserID}/favourites/{ID} Get a user favourite

/content/Items Get all content

items/content/Items/{ContentType} Get content items by type

/content/Items/{ContentType}/{ContentID} Get a content item

Internet radio catalogue service

How are resources accessed?

C

R

U

D

HTTP POST /users/{UserID}/favourites + payloadHTTP 201 status code + location

HTTP GET/users/{UserID}/favourites/{ID}HTTP 200 status code + payload

HTTP PUT /users/{UserID}/favourites/{ID}HTTP 200 status code

HTTP DELETE /users/{UserID}/favourites/{ID}HTTP 200 status code

What does an API request look like?

RequestGET /users/{userID}/favourites Http/1.1

accept: application/vnd.imgtec.com.favourites+xml

authorization: …..

Response

HTTP/1.1 200 OK

Content-type : application/vnd.imgtec.com.favourites+xml

<Favourites>

<Link rel=“add” href=“…” type=“…”

<Favourite>

<Labels />

<ContentID />

<Name />

</Favourite>

</Favourites>

REST style HTTP Request/Response

Statetransfer

Representation

Resource

Method

Add favouriteslink

APIs need to be secured

• Resources are not available to just anyone

• Employ Identity and access management patterns

• Identity – certificates, PSKs, username, biometrics

• oAuth2 based solutions for authentication and authorisation

• OpenID, UMA

• Federated security

• LDAP

• Channel encryption

• Typically secured using TLS

APIs need to scale

Y-Axis-Scaling

functional decomposition

X-Axis-Scaling

Horizontal duplication

Z-Axis-Scaling

Data partitioning

- Chris Richardson (micrservice.io), Lori MacVittie (F5)

But there’s always more

• Everyone is constantly looking to do more and more with less

• Same goes for APIs• Multiple channels to market with different requirements for same API

• Applications, 3rd party services, Partners, PaaS market place, developers

• Multiple “consumers” from different domains • Identity, authentication, authorization

• Service subscription plans • Usage contracts, feature access, throttling

• Understanding consumer experience and usage• Metrics and analytics

• Developer ecosystems to enable API evaluation and traction

• Management of API’s becomes problematic

An industry to enable API agility

• API gateways• Control run-time access to APIs

• Decouple public access to backend servers

• Authorisation, throttling, routing, caching

• But some solutions are more sophisticated offering transformation and aggregation capabilities

• This can be dangerous

• Developer portals and ecosystems• Self service on boarding of developers

• Documentation, registration, API keys

• API analytics

API Gateway Pattern

- Ronen Nachmias, Playtech

SUMMARY

It’s largely about scale and agility

• You need a culture and organisation to back the concepts

• If you can’t do monoliths then you won’t be able to do microservices

• You need domain knowledge to model the service decomposition and your APIs

• You need to work out latency, chatty APIs and service orchestration

• Those who do it well will thrive in the face of competition

Final comment

• Are microservices actually small?

• Not really.

• Small enough, but no smaller.

REFERENCES

References

• Martin Fowler

• Sam Newman

• Chris Richardson

• IDC

• Alistair Cockburn

• Achieving Enterprise Agility with Microservices and API

Management, Manfred Bortenschlager, 3Scale.

• Lorri MacVittie, F5

• Christian Posta, redhat

• Daniel Bryant, OpenCredo

• Ted Schadler

BACKUP

Digital Transformation

Monolithic pattern

“Monolithic application has single code

base with multiple modules. Modules are

divided as either for business features or

technical features. It has single build

system which build entire application

and/or dependency. It also has single

executable or deployable binary.”

Monolithic pattern• Typically 3 or 4 components

• (UI, Business Logic, Database & Integration)

• Run in a single process

• PROS• Simple to develop & deploy

• CONS• Increased complexity for developers

• Longer change cycles• Small changes requires complete retest and deployment

• Less agile as components can’t be released independently

• Long term commitment to a technology stack

• Harder to scale• Harder to scale development teams

• Continuous deployment gets difficult

• Can’t scale only the components you need to

• Need to replicate the whole application

• Difficult to keep modular structure

• Less well suited to reuse in hybrid service applications

Monolith vs microservice patterns

- James Lewis & Martin Fowler