WSO2Con USA 2015: Keynote - Some Essentials for Modern Solution Development

© Donald F. Ferguson, 2015. All rights reserved.
Some Essentials for Modern Solution
Development
WSO2Con 2015 US
Dr. Donald F. Ferguson
Donald.F.Ferguson@gmail.com

2 © Donald F. Ferguson, 2015. All rights reserved.Some Essential for Modern Solution Development
WSO2Con 2015 USA
Contents

WSO2Con 2015 USA
Contents
•  Introduction
–  Experience.
–  SOA and Microservices.
–  Presentation motivation.
•  Five (out of dozens) of observations.
–  A “simple” scenario.
–  SOA “versus” microservices.
–  The three (out of a dozen so far) observations.
–  Composition and patterns.
–  Application – application dependencies.
–  Configuration properties in the environment.
•  Summary, discussions and next steps.

WSO2Con 2015 USA
Introduction

WSO2Con 2015 USA
Experience and Motivation
•  History of enabling distributed applications, e.g.
–  Message Driven Processing, Event Driven Architecture
–  CORBA, J2EE
–  WS-*, JSR 106, WS-ResourceFramework, WS-Transfer, …
–  Eclipse perspectives, Service Component Architecture, Service Data Objects
–  Internet Service Bus, Boomi, Integration Platform as a Service
•  Three Columbia masters level courses exploring more modern technology
–  Modern Internet Application Development, e.g. AngularJS, Amazon SNS, MongoDB.
–  Modern Internet Service Oriented Application Development, e.g. REST, Redis, iPaaS.
–  Developing Applications with Microservices and APIs, e.g. Microservices, Google Pub/Sub,
Amazon Simple Workflow.
•  Common concepts emerge, get adopted, disappear and reemerge.
–  Technology will evolve and improve, but …
–  We need to ensure that new technology retains some core concepts.

WSO2Con 2015 USA
This Could be an Interesting Perspective, or …

WSO2Con 2015 USA
SOA
•  DEFINITION Service-oriented architecture (SOA) is an architectural style for build-ing systems based
on interactions of loosely coupled, coarse-grained, and autonomous components called services.
Each service exposes processes and behavior through contracts, which are composed of messages
at discoverable addresses called endpoints. A service’s behavior is governed by policies that are
external to the service itself. The contracts and messages are used by external components called
service consumers.
•  Some observations – SOA is a reaction to distributed OO and RPC.
–  Coarse Grained and Messages
–  OO tends to lots of small classes/objects and fine-grain API calls (e.g. person.getIq()).
–  SOA tends to person.getState().
–  Loosely coupled
–  Assume API calls “go remote” but may have local optimization.
–  Interfaces (Contracts) are not strongly typed, enabling independent evolution.
–  Endpoints
–  OO assumes “Java calling Java, perhaps over RMI.”
–  SOA separate Contract from Binding (WS-Interop, REST, message queues, etc).
–  Discoverable
–  OO assumes a classpath, findByClassName() and perhaps factory patterns.
–  SOA assumes you can go to a web callable repository and ask for SOA endpoints based on Contracts/Messages.
–  Web Services are a set of standards for SOA that enable interoperability.

WSO2Con 2015 USA
SOA
•  Various developer tools generate helper classes, allowing the programmer to focus on
application logic and not details of formatting XML messages for SOAP.
•  Services often go into containers that automate implementation of policies, e.g.
transactions, security, reliable messaging.

WSO2Con 2015 USA
Micro-services Characteristics
•  Componentization via Services
•  Organized around Business Capabilities
•  Products not Projects
•  Smart endpoints and dumb pipes
•  Decentralized Governance
•  Decentralized Data Management
•  Infrastructure Automation
•  Design for failure
•  Evolutionary Design

WSO2Con 2015 USA
What has changed?
•  We have
–  Heard similar terms
–  Loose coupling
–  Service discovery
–  Asynchronous messaging
–  Polyglot programming and persistence
–  Flexible scaling
–  etc.
–  Over and over again
–  Modular programming
–  CORBA, J2EE
–  Web services
–  …
•  What has changed? Why are we “right” now?
–  “This time we really mean it. If you cannot take a joke, you should not be in software.”
–  There are some significant innovations, tempered by some lost capabilities.
–  The tide comes in one wave at a time, but let’s not lose what we have learned.

WSO2Con 2015 USA
Three
Observations
Out Of
Dozens
So Far …

WSO2Con 2015 USA
A
“Simple”
Scenario

WSO2Con 2015 USA
A Simple Scenario
Student Info Microservice
•  Manages Student Resource
•  With a little bit of course
info “inside” student resource
Course Info Microservice
•  Manages Course Resource
•  With a little bit of student
info “inside” student resource
•  3rd parties provide the micro-service à Cannot examine or modify code.
•  Combine to provide a single microservice
–  Managing two resources: Student, Course
–  Existing apps will continue to use the existing microservices.
–  Referential integrity, e.g. deleting a student removes student from course.
Student Course

WSO2Con 2015 USA
When you do not know how to do something,
the most likely answer is build a microservice.
Student Course
API GW
Student Course
Integrat
e

WSO2Con 2015 USA
Identifying
Three
Issues

WSO2Con 2015 USA
SOA vs Microservices http://www.pwc.com/us/en/technology-forecast/2014/cloud-
computing/features/microservices.jhtml

WSO2Con 2015 USA
SOA vs Microservices http://www.pwc.com/us/en/technology-forecast/2014/cloud-
computing/features/microservices.jhtml
•  Not true.
•  Dangerous was to think.
•  Not a clear difference.
•  Concepts appears in both
•  Important distinction.
•  But focuses on how.
•  Not sure what this means

WSO2Con 2015 USA
The 12 Factors – How You Implement
I. Codebase
One codebase tracked in revision control,
many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing Services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup
and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production
as similar as possible
XI. LogsTreat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off process

WSO2Con 2015 USA
The 12 Factors – How You Implement “Isssues”
I. Codebase
One codebase tracked in revision control,
many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing Services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup
and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production
as similar as possible
XI. LogsTreat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off process

WSO2Con 2015 USA
The
Three
Observations

WSO2Con 2015 USA
Composition
and
Patterns

WSO2Con 2015 USA
Monolithic to Micro
Cart Functions
•  Java
•  SQLite
Recommendation Functions
•  Node.js
•  Redis
Catalog Functions
•  PDP
•  MongoDB XXX XXX
•  MMM
•  NNN
Content Functions
•  Ruby
•  Amazon S3

WSO2Con 2015 USA
Point-to-Point Connections are Bad
Doing this … Leads to this … …

WSO2Con 2015 USA
The Hub is Active, Patterned and Reusable

WSO2Con 2015 USA
Enterprise Integration Patterns with WSO2 ESB
https://docs.wso2.com/display/IntegrationPatterns/Enterprise+Integration+Patterns+with+WSO2+ESB

WSO2Con 2015 USA
A New Theorem
Ferguson’s 1st Theorem on Microservices and REST
•  {Compoentization via Services, Smart endpoint and dumb pipes} +
•  {Layered System} =
•  Enterprise Service Bus
Microservice Characteristics
•  Componentization via Services
•  Organized around Business Capabilities
•  Products not Projects
•  Smart endpoints and dumb pipes
•  Decentralized Governance
•  Decentralized Data Management
•  Infrastructure Automation
•  Design for failure
•  Evolutionary Design
REST Tenents
•  Client/server
•  Stateless
•  Caching
•  Uniform Interface
•  Layered System
•  Code on Demand

WSO2Con 2015 USA
Composition Models (and Diagrams)
•  The diagrams are always “nodes” and “arcs.”
•  Structure: node A <x> node B, where x is Requires/depends/calls/synchronizes
with/…
•  Control:
–  Execute A and then execute B, where A and B are tasks.
–  There is a shared set of “data objects” the tasks manipulate.
•  Data flow: Do A to the message/document/… and then do B to A’s output
Control Flow Structure Data Flow

WSO2Con 2015 USA
Summary
•  Dumb fast messaging versus powerful ESB
–  Is appealing.
–  But repeats the fallacies of “quick point-to-point” connections.
•  Microservice composition is not antithetical to ESB (and middleware)
–  Microservices focus on how you build basic components to achieve benefits.
–  The approach should not exclude the benefits of
–  Middleware and tools.
–  For common composition models and patterns.
–  That can improve robustness, reuse, agility, …
•  We see
–  The emergence of “callable” middleware, e.g. Amazon SWF, Google pub/sub.
–  But we cannot lose the benefits of active code in the middleware.

WSO2Con 2015 USA
Application
Dependency

WSO2Con 2015 USA
Inject application
implementation into
reusable SW containers
Reusable
infrastructure
containers
Reusable SW
containers but with
core technology
and frameworks
http://martinfowler.com/articles/microservices.html

WSO2Con 2015 USA

WSO2Con 2015 USA
OK, sounds good, but …
•  Maybe
•  My team and I
•  Did not write
•  Have source
•  For all the microservices.
•  I can probably figure out
•  What API the microservice exports,
e.g.
Browsable web UI.
•  What libraries it uses, e.g. pom.xml.
•  But have no idea what REST APIs
it calls into other microservices.
•  Making assembly of “binary” difficult.

WSO2Con 2015 USA
We Used to Have SCA and WSDL MEPs

WSO2Con 2015 USA
Summary
•  Dependency management is a crucial element of microservices and 12 Factor
Apps
–  Document dependencies (pom.xml, runtime specific metadafiles, …).
–  Treat backing resources as attached services.
–  etc.
•  But it is the nature of REST API assembly that
–  What “API/resources” a microservice manages.
–  And (especially) what REST resources it requires for application completeness.
–  Are very, very unclear.
–  Making many composition scenarios across teams difficult.,

WSO2Con 2015 USA
Config
in
the
Environment

WSO2Con 2015 USA
III. Configuration
•  An app’s config is everything that is likely to vary between deploys
(staging, production, developer environments, etc).
This includes:
•  Resource handles to the database, Memcached, and other backing services
•  Credentials to external services such as Amazon S3 or Twitter
•  Per-deploy values such as the canonical hostname for the deploy
•  Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which
requires strict separation of config from code. Config varies substantially across deploys, code
does not.
•  Note that this definition of “config” does not include internal application config, such as config/
routes.rb in Rails, or how code modules are connected in Spring. This type of config does not vary
between deploys, and so is best done in the code.
•  The twelve-factor app stores config in environment variables (often shortened to env
vars or env). Env vars are easy to change between deploys without changing any code; unlike config
files, there is little chance of them being checked into the code repo accidentally; and unlike custom
config files, or other config mechanisms such as Java System Properties, they are a language- and
OS-agnostic standard.

WSO2Con 2015 USA
Config Properties and Environment
•  The approach
–  Works iff you only configure at deployment.
–  Breaks down if
–  You are “starting” a new deployed instance
that needs to be different.
–  You need to modify a “running” instance.
•  What would you do such a crazy thing?
“SaaS” provided via
–  Instance per tenant.
–  Truly multitenant codebase.
•  Configuration must be an API, and support
configuring
–  Resource model/schema.
–  Some forms of application logic.

WSO2Con 2015 USA
Multitenant Application is Two Applications (APIs, Services),
which a platform makes a lot easier.
Data
Metadata
User Role
Assemble
Config
Role

WSO2Con 2015 USA
Summary
and
Discussion

WSO2Con 2015 USA
Summary and Discussion –
An interesting Perspective, but …
“Those who fail to learn from
history are doomed to
repeat it”.
George Santayana
Or maybe I am just a
cranky old guy that
time has passed by.

WSO2Con 2015 USA
Lunch Yesterday

WSO2Con 2015 USA
Looked a lot like this, with less smiling …
These kids do
not know
anything
about DB.
You should
see what they
do.
That’s
nothing. You
should see
how they do
SOA.

WSO2Con 2015 USA
Summary and Discussion
•  We can realize tremendous value from
–  REST.
–  Microservices.
–  12 Factor Applications.
–  Minimalistic infrastructure.
–  Dynamic dependency resolution.
–  Web callable middleware APIs.
•  But, we risk losing benefits that emerged in middleware and standards when we
started assmebling and composing solutions.
–  Interface and dependency metadata.
–  Optimized composition and integration engines and tools.
–  Automated enablement of capabilities via functional containers.
•  We should work to realize the benefits of both. The most crucial next steps is
ensuring awareness and adoption of design patterns.

WSO2Con USA 2015: Keynote - Some Essentials for Modern Solution Development

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a WSO2Con USA 2015: Keynote - Some Essentials for Modern Solution Development

Semelhante a WSO2Con USA 2015: Keynote - Some Essentials for Modern Solution Development (20)

Mais de WSO2

Mais de WSO2 (20)

Último

Último (20)

WSO2Con USA 2015: Keynote - Some Essentials for Modern Solution Development