1. © Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Dr. Donald F. Ferguson Donald.F.Ferguson@gmail.com

2. 2 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Contents

3. 3 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Contents Questions and discussion –Synchronous update and orchestration motivation. –“Should I use ZooKeeper/Kubernetes?” –Z-scaling versus database sharding. –Schema changes violating referential integrity. –“Isn’t writing state change to logs a security exposure?” –“How big should a microservice be?” –Z-Scaling versus DB shards. –Schema update and data model corruption. 12 Factor Application –Overview and perspective. –Implications for projects. Orchestration/Workflow/Message Queues –Concepts illustrated with BPMN. –State machine approach and Amazon Simple Workflow Service. –Project #2. Introduction to Web application security.

4. 4 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Questions and Discussion

5. 5 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Synchronous Integration

6. 6 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Synchronous Integration State based workflow will go here.

7. 7 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes, Mesos, ZooKeeper, … Logical scalable and HA single image. Control and management functions.

8. 8 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes and Docker Deploy and manage to Master Master transparently deploys to Minions

9. 9 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes

10. 10 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes, Mesos, ZooKeeper, … The technologies emerged to support –A large infrastructure of simple, commodity hardware enabling containers. – Running a very large number of dynamic microservices –Number of types of microservices. –Number of clones of a microservice type. –Microservice type deploy, and instance start, stop, restart, move, … The technologies are –Extremely relevant to microservices and APIs –Continuous development: Develop  unit test->QA  Deployment. –Scalable, available deployment and delivery. –But, using in class projects is difficult because they “require” scalable infrastructure. –I am explaining concepts and trying to figure out how to give hands-on experience. The technology is related to API Management/GWs, but –Kubernetes et al. primary focus on HW and container layer and are application semantics unaware. –While API Management and API GW operate as infrastructure extensions at the application and API layer.

11. 11 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Student Submitted Question “Sysadmins, programmers and others access ‘logs’ for problem resolution, debugging, etc. These roles should not have access to sensitive business and customer information. Isn’t logging resource state changes a security exposure?” A very good question. –Logging sensitive data to admin/programmer accessible files/logs would be a very serious security exposure. –Shared, unsecured logs with sensitive data WILL cause data theft. –Many government and industry regulations explicitly preclude sharing sensitive data in things like logs. –I used “log” and “feed” as metaphors or analogies. I do not use the terms in a literal manner. –Almost all commercial data processing systems record and save business data state changes, e.g. –Backup and recovery. –Regulatory and legal compliance requires knowing what the data “used to be.” –Business intelligence and analytics often focuses on the evolution of data. –These “logs” are not /etc/syslog. The “logs” are themselves mission critical, sensitive business information. The information is a logical extension of the “current” state of the resource, is itself a resource and is protected like any other resource. –Propagating the “log” to an observing system is also very common. –Disaster recovery and backup. –Continuous load of a business data warehouse. –Legal and business compliance “write only” system.

12. 12 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction An Example and Implications An insurance company resolving a complaint about a car insurance rate needs to know –Basic scenario –What color the car is now? –What color was the car when the rate was set? Cars change color. –Moreover, when did I come to know that the car changed color? The customer may have forgotten to tell me at the time. –Some systems maintain resource history in two-dimensional time. –…/don/car/actualState/t: What color was the car at time t? –…/don/car/beliefState/t: What color did I think the car was at time t? –And the system sends state change events as secure, business data to other services. –Feed data warehouse to enable reports, e.g. “Common car colors in Illinois in 1972.” –Business intelligence/analytics systems, e.g. “Look for trends in car color evolution to potentially identify new rate plans.” –Operations, e.g. “Notify agent to contact customer to discuss rate change due to color change. Implications –The state history and emitted business events are themselves “resources” that must be secure. The current value is just a special case. –The “unanticipated composition enablement pattern” recommends the practice for all micro-services. The service “configure” SPI should enable turning on/off, selecting resource types, etc.

13. 13 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Transaction Log Shipping/Data Warehouse Loading Data replication is extremely common –Scalability, multi-site, availability. –Read only “data warehouse” to keep complex query partitioned from interactive workloads. How do you replicate? –Historically, replication occurred through –Backups, extract-transform-load, batch jobs. –Increasing “event/message” based. –Increasingly occurring through “data state change” events for –Updating multiple, unanticipated systems. –More current data.

14. 14 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Summary Resource managers “logging” and “propagating” state changes is common –Many business scenarios. –Many technology realizations, e.g. –Triggers  messages. –Transaction commit/redo log shipping and replay. –Extract-Transform-Load. –Inherent part of core data model for application requirements. –The information is another type of core, secure data and protected. The resource state change pattern to enable unanticipated information –Exposes the state changes as part of the resource data model. –Secured the same way the current state is. –Pattern for enabling replication and synchronization, similar to existing approaches, but aligned with REST, microservices, etc.

15. 15 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Another Question “How big should a microservice be? Should student info and course info really be different microservices? etc.” Well, we are not the 1 st people to ask this question. Some answers are –“Small enough and no smaller.” –“Created by no more than a handful of people.” The next obvious question is, “How many people is a handful?” –Follow the single responsibility principle (https://en.wikipedia.org/wiki/Single_responsibility_principle).https://en.wikipedia.org/wiki/Single_responsibility_principle –Avoid splitting microservices if it causes data sharing, which is not the same thing as “data linking.” The web is all about linked data. My advice: Assume you have to manage resource types X and Y. –If someone is likely to want your X but someone else’s Y  2 microservices. –If there are several logical scenarios that cause X to change Y and vice versa  1 microservice. –The ideal SW development size is 7 people, +/- 3. If the microservice requires more than 12 developers, even if logically one “business service,” split for development agility. –Use common sense. Be able to explain your decision.

16. 16 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Event Models: Push versus Pull There are two approaches to “notification.” 1.Pull: –The supplier records and stores notifications. –The consumer calls and requests notifications that match conditions, e.g. –Resource types –Time intervals 2.Push: –The consumer sends a subscribe message with a filter to the supplier. The message contains a callback URL. –For any change that matches the filter, the supplier calls all subscribed consumers. There are microservices (middleware) that will adapt between –Pull consumers and Push suppliers. –Pull suppliers and Push consumers. I recommended: 1) Pull supplier. 2) Push consumer. 3) Microservice that adapts, including formats.

17. 17 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction 12 Factor Application http://12factor.net/

18. 18 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Overview and Motivation Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices.

19. 19 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction The 12 Factors 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. 20 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction I. Codebase

21. 21 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction II. Dependencies Concept “A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declaration manifest. Furthermore, it uses a dependency isolation tool during execution to ensure that no implicit dependencies “leak in” from the surrounding system. The full and explicit dependency specification is applied uniformly to both production and development. For example, Gem Bundler for Ruby offers the Gemfile manifest format for dependency declaration and bundle execfor dependency isolation. In Python there are two separate tools for these steps – Pip is used for declaration and Virtualenvfor isolation. Even C has Autoconf for dependency declaration, and static linking can provide dependency isolation. No matter what the toolchain, dependency declaration and isolation must always be used together – only one or the other is not sufficient to satisfy twelve-factor.Gem BundlerPipVirtualenvAutoconf One benefit of explicit dependency declaration is that it simplifies setup for developers new to the app. The new developer can check out the app’s codebase onto their development machine, requiring only the language runtime and dependency manager installed as prerequisites. They will be able to set up everything needed to run the app’s code with a deterministicbuild command. For example, the build command for Ruby/Bundler is bundle install, while for Clojure/Leiningen it islein deps.Leiningen Twelve-factor apps also do not rely on the implicit existence of any system tools. Examples include shelling out to ImageMagick or curl. While these tools may exist on many or even most systems, there is no guarantee that they will exist on all systems where the app may run in the future, or whether the version found on a future system will be compatible with the app. If the app needs to shell out to a system tool, that tool should be vendored into the app.” Observations –This does not solve the problem of documenting service dependencies. –Docker packaging increasingly solves some of the system dependency issues.

22. 22 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction 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.

23. 23 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction IV. Treat backing services as attached resources A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached).MySQLCouchDBRabbitMQBeanstalkdPostfixMemcached Backing services like the database are traditionally managed by the same systems administrators as the app’s runtime deploy. In addition to these locally-managed services, the app may also have services provided and managed by third parties. Examples include SMTP services (such as Postmark), metrics-gathering services (such as New Relic or Loggly), binary asset services (such as Amazon S3), and even API-accessible consumer services (such as Twitter, Google Maps, orLast.fm).PostmarkNew RelicLogglyAmazon S3TwitterGoogle MapsLast.fm The code for a twelve-factor app makes no distinction between local and third party services. To the app, both are attached resources, accessed via a URL or other locator/credentials stored in the config. A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code. Likewise, a local SMTP server could be swapped with a third-party SMTP service (such as Postmark) without code changes. In both cases, only the resource handle in the config needs to change.configdeployAmazon RDS

24. 24 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction IV. Backing Services Ideally –Backing services, even local backing services, export a Web callable/REST API. –If the backing service does not have a REST API, build an encapsulating (adaptor) microservice. –Clearly segregate data access services from business services.

25. 25 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction V. Build, Release, Run A codebase is transformed into a (non-development) deploy through three stages:codebase –The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors dependencies and compiles binaries and assets.dependencies –The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.config –The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’sprocesses against a selected release.processes The twelve-factor app uses strict separation between the build, release, and run stages. For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. Every release should always have a unique release ID, such as a timestamp of the release (such as 2011-04-06-20:32:17) or an incrementing number (such as v100). Releases are an append-only ledger and a release cannot be mutated once it is created. Any change must create a new release.

26. 26 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction V. Build, Release, Run

27. 27 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction VI. Process The app is executed in the execution environment as one or more processes. In the simplest case, the code is a stand-alone script, the execution environment is a developer’s local laptop with an installed language runtime, and the process is launched via the command line (for example, python my_script.py). On the other end of the spectrum, a production deploy of a sophisticated app may use many process types, instantiated into zero or more running processes.process types, instantiated into zero or more running processes Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a statefulbacking service, typically a database.share-nothingbacking service The memory space or filesystem of the process can be used as a brief, single-transaction cache. The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request or job. Even when running only one process, a restart (triggered by code deploy, config change, or the execution environment relocating the process to a different physical location) will usually wipe out all local (e.g., memory and filesystem) state. Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such asMemcached or Redis.“sticky sessions”MemcachedRedis

28. 28 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction VII. Port Binding Export services via port binding Web apps are sometimes executed inside a webserver container. For example, PHP apps might run as a module insideApache HTTPD, or Java apps might run inside Tomcat.Apache HTTPDTomcat The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. In a local development environment, the developer visits a service URL like http://localhost:5000/ to access the service exported by their app. In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes. This is typically implemented by using dependency declaration to add a webserver library to the app, such as Tornado for Python, Thin for Ruby, or Jetty for Java and other JVM-based languages. This happens entirely in user space, that is, within the app’s code. The contract with the execution environment is binding to a port to serve requests.dependency declarationTornadoThinJetty

29. 29 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction VIII. Concurrency Scale out via the process model

30. 30 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction IX. Disposability Maximize robustness with fast startup and graceful shutdown The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.processescodeconfig Processes should strive to minimize startup time. Ideally, a process takes a few seconds from the time the launch command is executed until the process is up and ready to receive requests or jobs. Processes shut down gracefully when they receive a SIGTERM signal from the process manager. For a web process, graceful shutdown is achieved by ceasing to listen on the service port (thereby refusing any new requests), allowing any current requests to finish, and then exiting. SIGTERM Processes should also be robust against sudden death, …

31. 31 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction X. Dev/prod parity Keep development, staging, and production as similar as possible Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas:deploy –The time gap: A developer may work on code that takes days, weeks, or even months to go into production. –The personnel gap: Developers write code, ops engineers deploy it. –The tools gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux. The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small. Looking at the three gaps described above:continuous deployment –Make the time gap small: a developer may write code and have it deployed hours or even just minutes later. –Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production. –Make the tools gap small: keep development and production as similar as possible.

32. 32 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction X. Dev/prod parity Backing services, such as the app’s database, queueing system, or cache, is one area where dev/prod parity is important. Many languages offer libraries which simplify access to the backing service, including adapters to different types of services. Some examples are in the table below.Backing services Developers sometimes find great appeal in using a lightweight backing service in their local environments, while a more serious and robust backing service will be used in production. The twelve-factor developer resists the urge to use different backing services between development and production, even when adapters theoretically abstract away any differences in backing services. Differences between backing services mean that tiny incompatibilities crop up, causing code that worked and passed tests in development or staging to fail in production. Adaptor Fallacy

33. 33 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction XI. Logs Treat logs as event streams Logs –Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format. –Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. Logs in their raw form are typically a text format with one event per line (though backtraces from exceptions may span multiple lines). Logs have no fixed beginning or end, but flow continuously as long as the app is operating.stream –A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. –In staging or production deploys, each process’ stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. Comments –This applies to debug, trace, problem deternination, … logs. –My view is that business events have a pub/sub implementation and are part of app model.

34. 34 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction XII. Admin processes Run admin/management tasks as one-off processes Application administration –The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as:process formation –Running database migrations (e.g. manage.py migrate in Django, rake db:migrate in Rails). –Running a console (also known as a REPL shell) to run arbitrary code or inspect the app’s models against the live database. Most languages provide a REPL by running the interpreter without any arguments (e.g. python or perl) or in some cases have a separate command (e.g. irb for Ruby, rails console for Rails).REPL –Running one-time scripts committed into the app’s repo (e.g. php scripts/fix_bad_records.php). –One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.long-running processesreleasecodebaseconfig Comments –Traditionally application management occurred through special side mechanisms, e.g. WMI, MBeans, SMTP, CMIP, … –12 Factor apps have admin as an intrinisc part of the application. –But, there will still be separate “management” solutions for end-to-end, multi-app management,

35. 35 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Orchestration Workflow

36. 36 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction BPMN BPMN 2.0 is an international standard for business process modeling. The BPMN specification describes how the elements of a process diagram have to look like (notation), how these can be combined with each other (meta model / syntax), what a diagram means (semantics) and how diagrams can be transferred from one tool to another (XML interchange format). Process models describe sequences of business activities from start to finish, e.g. Order-to-Cash, Account Open

37. 37 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction BPMN and Activiti Some terms –BPMN 2.0 is a standard for defining/documenting workflows/orchestrations. –Activiti (and many others) are implementations of the standard –Runtime engine that can interpret and execute a BPMN process –A WYSIWYG editor –With prebuilt, configurable shapes palette that extend base BPMN shapes. Huh? BPMN has the concepts of a “Task,” which is one “step” in a process. But in a process model, this is just “prose” like “Order a Pizza” Implementations come with “common” types of tasks, e.g. Make an SQL call on a database. Call a REST API Put a document on a worklist etc. –A composition canvass for assembling shapes into processes. –Debugger, monitoring, reporting, versioning, etc. This is –The same concept as enterprise integration patterns and Boomi –But, –The clipart is different –And the graph mostly represents “control flow,” not data flow.

38. 38 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Simple BPMN Diagram

39. 39 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction And You can Define Processes

40. 40 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction How do you Implement? Notify a person/role. Have them do something. Have the use an app that calls the engine to tell you they are done. Send an email. POST a document etc. Decision table Call Drools etc. Insert into a DB Call a web service Run a Java app. etc. Run some JavaScript or Java or … Right at this point in the workflow/process And manipulate the data/documents/control.

41. 41 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction AWS Simple Workflow

42. 42 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon Simple Workflow

43. 43 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Application Structure Role of the Activities Worker: The activities worker performs the various tasks that the workflow must accomplish. It consists of: –The activities implementation, which includes of a set of activity methods that perform particular tasks for the workflow. –An activity worker, which uses HTTP long poll requests to poll Amazon SWF for activity tasks. When a task is available, Amazon SWF responds to the request by sending the information required to perform the task. The activity worker then calls the appropriate activity method, and returns the results to Amazon SWF. Role of the Workflow Worker: The workflow worker orchestrates the execution of the various activities, manages data flow, and handles failed activities. It consists of: –The workflow implementation, which includes the activity orchestration logic, handles failed activities, and so on. –An activities client, which serves as a proxy for the activities worker and enables the workflow worker to schedule activities to be executed asynchronously. –A workflow worker object, which uses HTTP long poll requests to poll Amazon SWF for decision tasks. If there are tasks on the workflow task list, Amazon SWF responds to the request by returning the information that is required to perform the task. The framework then executes the workflow to perform the task and returns the results to Amazon SWF.