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

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

3 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

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

5 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

6 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA This Could be an Interesting Perspective, or …

7 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

8 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

9 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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

10 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

11 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Three Observations Out Of Dozens So Far …

12 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA A “Simple” Scenario

13 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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 3 rd 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

14 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA When you do not know how to do something, the most likely answer is build a microservice. Student CourseAPI GW StudentCourse Integrat e

15 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Identifying Three Issues

16 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA SOA vs Microservices computing/features/microservices.jhtml

17 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA SOA vs Microservices 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.

18 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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 processes

19 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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 processes

20 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA The Three Observations

21 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Composition and Patterns

22 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Monolithic to Micro Cart Functions Java SQLite Recommendation Functions Node.js Redis Catalog Functions PDP MongoDB XXX MMM NNN Content Functions Ruby Amazon S3

23 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Point-to-Point Connections are Bad Doing this … Leads to this … …

24 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA The Hub is Active, Patterned and Reusable

25 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Enterprise Integration Patterns with WSO2 ESB

26 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA A New Theorem Ferguson’s 1 st 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

27 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Composition Models (and Diagrams) The diagrams are always “nodes” and “arcs.” Structure: node A 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 FlowStructureData Flow

28 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

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

30 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Inject application implementation into reusable SW containers Reusable infrastructure containers Reusable SW containers but with core technology and frameworks

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

32 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

33 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA We Used to Have SCA and WSDL MEPs

34 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.,

35 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Config in the Environment

36 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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:deploys Resource handles to the database, Memcached, and other backing servicesbacking 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.code modules are connectedSpring 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.

37 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

38 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Multitenant Application is Two Applications (APIs, Services), which a platform makes a lot easier. Data Metadata User Role Assemble Config Role

39 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development WSO2Con 2015 USA Summary and Discussion

40 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

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

42 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.

43 © Donald F. Ferguson, All rights reserved.Some Essential for Modern Solution Development 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.