API’s and Micro Services 0.5
-
Upload
richard-hudson -
Category
Documents
-
view
83 -
download
0
Transcript of API’s and Micro Services 0.5
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