1. APIS AND MICROSERVICES
What the *&%$ are they?
An introductory presentation by Richard Hudson

2. 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

3. SETTING THE SCENE
Why the need for agility, innovation and service delivery

4. 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

5. 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

6. WHAT ARE MICROSERVICES?
One approach for business agility

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. WHAT ARE APIS?

14. 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

15. What are resources?
• Domain entities that need to be shared externally

16. 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

17. 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

18. How are resources accessed?
C
R
U
D
HTTP POST /users/{UserID}/favourites + payload
HTTP 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

19. What does an API request look like?
Request
GET /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
State
transfer
Representation
Resource
Method
Add
favourites
link

20. 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

21. 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)

22. 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

23. 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

24. API Gateway Pattern
- Ronen Nachmias, Playtech

25. SUMMARY

26. 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

27. Final comment
• Are microservices actually small?
• Not really.
• Small enough, but no smaller.

28. REFERENCES

29. 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

30. BACKUP

31. Digital Transformation

32. 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.”

33. 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

34. Monolith vs microservice patterns
- James Lewis & Martin Fowler