Microservices under the
microscope
QCon – São Paulo
#APIFirst
@rdmeyersf #API @axway
March 24, 2015
1
“To Improve Is to
Change; To Be Perfect Is
to Change Often”
Sir Winston Churchill
© 2015 Axway
|
Confidential
2
Digital Business Changes Everything
3
Digital Business has no Border
• Architecting for
Mobile isn’t enough
• Omni-channel
experiences require
a new approach
• Digital products are
King
4
Digital Business has no Speed Limit
5
BMW i Remote App
•
•
•
•
•
•
Status of car
Charging status
Doors, windows…
Inspection due
Range
Route to car /
to public
transportation
6
Single Customer Experience
7
Netflix has shown the way…
Reactions Adrian Cockcroft received.
“You guys are
crazy! Can’t
believe it”
“What Netflix is doing
won’t work”
-2009
-2010
“It only works for
Unicorns like Netflix”
-2011
“We’d like to do
that, but can’t”
-2012
8
Enterprise IT Adoption Cycle
http://blog.gardeviance.org/2012/07/adoption-cycles.html - Simon Wardley
9
A mandate for change!
10
Digital Business in API Terminology
A Simple, Stateless Message
• {“API”:“First”}
• {“API”:”Microservices”}
• {“Microservices”:“Change”}
11
Digital Business in API Terminology
A Simple, Stateless Message
• {“API”:“First”}
• {“API”:”Microservices”}
• {“Microservices”:“Change”}
12
APIs Must be Useful
"The value of a well-designed
object is when it has such a rich
set of affordances that the people
who use it can do things with it
that the designer never
imagined.”
Donald Norman
13
What is API First?
• Involved in most new projects
–
–
–
–
–
–
B2B
Mobile
Cloud
IoT
Social
Big Data
• Lead with APIs by default
14
What is API First?
The API
is the
Contract
The API
is the
Product
API
First!
15
Making API First Work
16
Digital Business in API Terminology
A Simple, Stateless Message
• {“API”:“First”}
• {“API”:”Microservices”}
• {“Microservices”:“Change”}
17
Introducing Microservices
“…the microservice architectural style.. ..is an
approach to developing a single application as a suite
of small services, each running in its own process and
communicating with lightweight mechanisms, often an
HTTP resource API. …”
Martin Fowler
http://martinfowler.com/articles/microservices.html
18
API First vs SOA
APIs
…And the
product
“This is
what I
need…”
API Management
The API is
the
contract
SOA/ESB
“Here is
what I
have to
offer…”
WSDL is
the
Contract
Backend
App is the
Product
19
From SOA to API First
20
Digital Business in API Terminology
A Simple, Stateless Message
• {“API”:“First”}
• {“API”:”Microservices”}
• {“Microservices”:“Change”}
21
Public APIs:
Better Customer
Experience
The API is
the
contract
…And the
product
“This is
what I
need…”
API Management
Microservices Focus on Change
SOA:
Better Apps +
Integration
“Here is
what I
have to
offer…”
WSDL is
the
Contract
Backend
App is the
Product
Microservices:
Improved Developer
Experience
22
Legacy Enterprise Applications
Web
Client
Data
Storage
Backend Server
Mobile
Client
Other
Other
Clients
Clients
23
The Backend Was Still Monolithic
• Tightly coupled
• Monolithic scaling
Backend Server
24
SOA brought separation, but little
empowerment
• Course grained, reusable, more scalable services
• Coupled through orchestration
• Still common servers, DBs, data
Service
Service
Service
Service
Backend Server
25
Microservices brings developers
• Why SOA?
• Why Microservices?
– Break the monolith
– Integrate legacy apps
– Scale & Reuse
– A platform for the business
– Agility
– Not tied to servers, tools, DBs
Service
Service
Service
Service
Backend
Server
26
Build it, Run it, Own it
• SOA Services are seen as projects
– The team moves on when the scope of that project is
delivered
• Microservices and their APIs must be managed as
products
– Product team owns their service from conception to
retirement
27
Public APIs: True Loose Coupling
“Smart endpoints, dumb pipes”
• Simple and stateless (RESTful)
– Little coupling to a process (unlike Web services)
•
Designed outside-in based on how it’s consumed (product)
• Bullet proof
– Built-in error handling/checking
• Designed from the outside in (product)
– Very slowly changing, insulate from underlying change
• Self described
– Standard web API documentation (e.g. Swagger)
– Easy to use repository (search, etc.)
– Self testing during learning process
• All reuse configured not coded
– Security, identity, composition, policy/SLA, auditing, analytics
28
Microservices (Private APIs): Agility
• Platform agnostic
– Support servers, tools, languages, DBMSs of choice
• Constant change (daily)
–
–
–
–
–
Bounded code/products (microservices and APIs)
Bounded, independent teams owning “products”
Dev Ops approach from development to operations
Lightweight communication across containers
Automated testing, deployment
• Self service (versus governance)
– Self service, delegated ownership
– Governance processes tailored for self service
– Delegated control over “configurable” attributes
29
Design Security Assuming it’s Public
• Threat protection (e.g. OWASP top 10)
• Identity management (AAA, Oauth 2.0, Mediation)
– Don’t assume internal or private access
• Auditability, compliance
The Real Firewall
Microservices
Service
Service
Service
Service
Backend
Server
30
Trust, Visibility
Policies/SLAs
The Real Firewall
Microservices
Service
Service
Service
Service
Backend
Server
31
Key Takeaways
•
•
•
•
{“API”:“First”}
{“API”:”Microservices”}
{“Microservices”:“Change”}
Getting Started
– Security
– Public APIs
– Microservices
32
Q&A
© 2015 Axway
|
Confidential
33
Obrigado!
Microservices under the
microscope
QCon – São Paulo
#APIFirst
@rdmeyersf #API @axway
March 24, 2015
34