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

© Donald F. Ferguson, 2015. All rights reserved.

Some Essentials for Modern Solution DevelopmentWSO2Con 2015 US

Dr. Donald F. [email protected]

2 © Donald F. Ferguson, 2015. All rights reserved.

Some Essential for Modern Solution DevelopmentWSO2Con 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.



ThreeObservationsOut OfDozensSo 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



IdentifyingThreeIssues



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. CodebaseOne codebase tracked in revision control,many deploys

II. DependenciesExplicitly declare and isolate dependencies

III. ConfigStore config in the environment

IV. Backing ServicesTreat backing services as attached resources

V. Build, release, runStrictly separate build and run stages

VI. ProcessesExecute the app as one or more stateless processes

VII. Port bindingExport services via port binding

VIII. ConcurrencyScale out via the process model

IX. DisposabilityMaximize robustness with fast startupand graceful shutdown

X. Dev/prod parityKeep development, staging, and productionas similar as possible

XI. LogsTreat logs as event streams

XII. Admin processesRun admin/management tasks as one-off processes



The 12 Factors – How You Implement “Isssues”

I. CodebaseOne codebase tracked in revision control,many deploys

II. DependenciesExplicitly declare and isolate dependencies

III. ConfigStore config in the environment

IV. Backing ServicesTreat backing services as attached resources

V. Build, release, runStrictly separate build and run stages

VI. ProcessesExecute the app as one or more stateless processes

VII. Port bindingExport services via port binding

VIII. ConcurrencyScale out via the process model

IX. DisposabilityMaximize robustness with fast startupand graceful shutdown

X. Dev/prod parityKeep development, staging, and productionas similar as possible

XI. LogsTreat logs as event streams

XII. Admin processesRun admin/management tasks as one-off processes



TheThreeObservations



CompositionandPatterns



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 BadDoing this … Leads to this … …



The Hub is Active, Patterned and Reusable



Enterprise Integration Patterns with WSO2 ESBhttps://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.



ApplicationDependency



Inject application

implementation into

reusable SW containers

Reusable

infrastructure

containers

Reusable SW

containers but with

core technology

and frameworkshttp://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 APIsit 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.,



ConfigintheEnvironment



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.

http://12factor.net/codebase

http://12factor.net/backing-services

http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html

http://spring.io/



Config Properties and Environment• The approach

– Works iff you only configure at deployment.– Breaks down if

– You are “starting” a new deployed instancethat 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

AssembleConfigRole



SummaryandDiscussion



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 acranky old guy thattime 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.

Date post:	18-Jan-2016
Category:	Documents
Upload:	christina-day
View:	216 times
Download:	0 times

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

Documents