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 [email protected]

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

Contents


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.


Introduction


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.


This Could be an Interesting Perspective, or …


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.


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.


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


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.


Three Observations Out Of Dozens So Far …


A “Simple” Scenario


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


When you do not know how to do something, the most likely answer is build a microservice.

Student Course

API GW

Student Course

Integrate


Identifying Three Issues


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


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.


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 processes


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 processes


The Three Observations


Composition and Patterns


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


Point-to-Point Connections are Bad Doing this … Leads to this … …


The Hub is Active, Patterned and Reusable


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


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


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


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.


Application Dependency


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


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.


We Used to Have SCA and WSDL MEPs


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


Config in the Environment


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.


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.


Multitenant Application is Two Applications (APIs, Services), which a platform makes a lot easier.

Data

Metadata

User Role

Assemble Config Role


Summary and Discussion


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.


Lunch Yesterday


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.


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.