QCon Beijing. Web APIs are the new de facto approach to architecture integration for all innovative digital business applications across cloud, mobile, B2B, Big Data or Internet of Things (IoT) technologies. For many of these projects, enterprise architecture and service delivery is adapting from an "inside-out" model towards a microservices and API First approach, which offers greater flexibility and agility around core IT services. In this session we investigate the promise of microservices, and consider how they will work in real enterprises with existing applications, complex SOA environments and strict organizational or governance structures.

1. © 2015 Axway | Confidential 1
Microservices under the
microscope
QCon Beijing
Ross Garrett
rgarrett@axway.com
@gssor
April 25th, 2015

2. © 2015 Axway | Confidential 2© 2015 Axway | Confidential 2
“To Improve Is to Change;
To Be Perfect Is to
Change Often”
Sir Winston Churchill
提高就是要改变,而要达到完美
就要不断改变。
温斯顿·丘吉尔

3. © 2015 Axway | Confidential 3
We’ve already been forced to change…

4. © 2015 Axway | Confidential 4
Digital Business has no Border
• Architecting for
Mobile isn’t enough
• Omni-channel
experiences require
a new approach
• Digital products are
King

5. © 2015 Axway | Confidential 5
Expectations for IT have changed
• In the past enterprise architecture was designed for
known use cases and integrations
– The consumer cloud & mobile application model has
changed the way business users view IT products and
processes
• Today’s enterprise must architect for the unknown
– Enterprise IT systems are no longer an island and
must build their capacity to integrate with the outside
world

6. © 2015 Axway | Confidential 6

7. © 2015 Axway | Confidential 7
Netflix has shown the way…
Reactions Adrian Cockcroft received.
“You guys are
crazy! Can’t
believe it”
-2009
“What NeBlix is doing
won’t work”
-2010
“We’d like to do
that, but can’t”
-2012
“It only works for
Unicorns like NeBlix”
-2011

8. © 2015 Axway | Confidential 8
A mandate for change!

9. © 2015 Axway | Confidential 9
Enterprise IT Adoption Cycle
hKp://blog.gardeviance.org/2012/07/adopQon-cycles.html - Simon Wardley

10. © 2015 Axway | Confidential 10
Conway’s Law
"Any organization that designs a system
(defined more broadly here than just
information systems) will inevitably
produce a design whose structure is a
copy of the organization's
communication structure."

11. © 2015 Axway | Confidential 11
What do Enterprise Applications look
like?
Backend Server Data
Storage
Web
Client
Other
Clients
Mobile
Client
Other
Clients

12. © 2015 Axway | Confidential 12
The backend relied on monolithic
applications
• All functionality in a single
process
• Scale by adding servers
Backend Server

13. © 2015 Axway | Confidential 13
SOA introduced separation
• Separable elements of functionality become services
• Scale & reuse services as needed
Backend Server
Service Service
Service Service

14. © 2015 Axway | Confidential 14
Are these services 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

15. © 2015 Axway | Confidential 15
Are these services useful?
Are these services able to serve
today’s application needs?
And tomorrow’s?

16. © 2015 Axway | Confidential 16
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

17. © 2015 Axway | Confidential 17
Why Microservices?
Backend
Server
Service Service
Service Service
• A platform for the business
• Agility
• Not tied to technology

18. © 2015 Axway | Confidential 18
Loosely Coupled
It’s not loosely
coupled, if mulQple
services need to be
updated at the
same Qme

19. © 2015 Axway | Confidential 19
Functionally Bounded
You should not
require too much
informaQon about
surrounding
services

20. © 2015 Axway | Confidential 20
Sounds familiar?

21. © 2015 Axway | Confidential 21
Are these services useful?
How small is microservice?
We want to avoid dumb services
that are just CRUD wrappers

22. © 2015 Axway | Confidential 22
SOA vs Microservices
SOA
• Team focused on
services
• Services deployed in a
shared bus
• Machine readable
service registry
• Centralized
orchestration
• Centralized data
storage
Microservices
• Teams aligned with
business
• Services deployed at the
edge
• Developer readable
catalogue
• Orchestration within each
app
• Data storage replicated
across atomic instances

23. © 2015 Axway | Confidential 23
Build it, Run it, Own it
• SOA Services were 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

24. © 2015 Axway | Confidential 24© 2015 Axway | Confidential 24
Examining the components
of a microservices
architecture

25. © 2015 Axway | Confidential 25
Defining Services

26. © 2015 Axway | Confidential 26
Defining Services
• Build services for business functions not known
integration problems
• Implement a process to build and deploy each
service independently
• Existing services can be maintained, while new or
partial services are launched
– No impact to production until traffic routing is updated

27. © 2015 Axway | Confidential 27
Decentralize Everything

28. © 2015 Axway | Confidential 28
Decentralize Everything
• Developers can build services on any platform, with
any tools
• Limit or remove centralized resources
– Databases
– Message Queues
– Enterprise Service Buses

29. © 2015 Axway | Confidential 29
High Trust, Low Friction

30. © 2015 Axway | Confidential 30
High Trust, Low Friction
• Developers dislike rebel against strict governance
processes
• Services should be managed and owned by product
teams
– Lifecycle management
• Functional decomposition based on the business
– Services should not represent technology or architectural
constraints, but rather business requirements

31. © 2015 Axway | Confidential 31
Lightweight Integration Patterns

32. © 2015 Axway | Confidential 32
Lightweight Integration Patterns
• Services should be stateless
• Hide backend implementation complexity
• Document your services and their APIs
– Swagger, RAML, Blueprint

33. © 2015 Axway | Confidential 33
Think Differently About API Design

34. © 2015 Axway | Confidential 34
Think Differently About API Design
• Bring the Web to enterprise integration
• Traditional RPC-style APIs can depend on a high
degree of context for surrounding services
• Design a RESTful representation of your service
– This API should look at application needs (outside-in)
• Hypermedia-Style APIs promote loose-coupling
• Use HTTP linking to self-document service capabilities

35. © 2015 Axway | Confidential 35
Design security with public access in
mind

36. © 2015 Axway | Confidential 36
Design security with public access in
mind
• Access to services must be managed
– Don’t assume internal or private access
• Define or inherit granular identity and policy rules
• Leverage and adhere to security standards
– OAuth 2.0
– API Keys

37. © 2015 Axway | Confidential 37© 2015 Axway | Confidential 37
Architecting for
Continuous Change

38. © 2015 Axway | Confidential 38
Holistic approach to digital

39. © 2015 Axway | Confidential 39
The Microservices End Game

40. © 2015 Axway | Confidential 40
The Microservices End Game
• New versions of services are deployed frequently
– Ideally automatically
• Move away from general purpose orchestration
– Apps orchestrate the services they need in the
environment they prefer
• Most architectures will have hundreds of services
– But remember useful design

41. © 2015 Axway | Confidential 41
Thank You!
Ross Garrett
rgarrett@axway.com
@gssor