Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)

1 Introduction

This blogpost extends the blogpost “Architecting application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2014/12/architecting-application-architecture.html to “cloud-friendly application architecture”. You may jump to chapter 8 to see a demo of it.

This cloud-friendly application architecture opens the way to synergy between #BPM, #SOA, #cloud, #microservices, #IoT, #digital and #security.

2 Clarification of some terminology

2.1 Process

Many articles about microservices mentioned “process”. I believe they mean “computing process” (e.g. an instance of JVM) which should not be confused with “business process”.

2.2 Orchestration

Another confusing term is “orchestration”. In some articles, it means “container orchestration layer” which allows one to specify how the micro-services are handled in fault tolerant and in scaling up and scaling down (see http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture ).

See also http://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices slide 70 “Orchestration for Applications”

O’Reilly book “Migrating to Cloud-Native Application Architectures” http://pivotal.io/platform-as-a-service/migrating-to-cloud-native-application-architectures-ebook says “The ESB becomes the owner of all routing, transformation, policy, security, and other decisions governing the interaction between services. We call this orchestration, analogous to the conductor who determines the course of the music performed by an orchestra during its performance. ESBs and orchestration make for very simple and pleasing architecture diagrams, but their simplicity is deceiving. Often hiding within the ESB is a tangled web of complexity.” I think, this is a wrong analogy. The conductor delivers only one symphony at a time. ESB delivers many symphonies at the same time. Not surprising that it such “centralised orchestration” is difficult.

In other articles, it means one of two BPMN ways to compose business processes – orchestration as a strong coordination and choreography as weak coordination. This orchestration is a domain bounded because it is carried out in the scope of a particular business process.

3  Commenting some posts about microservices

From http://intellyx.com/2015/03/11/microservices-avoiding-dumb-pipes/ “Rather, we simply have a new way of thinking about “smart” pipes – microservice integration that is architected following web scale, cloud-centric principles.”

Good point although I think being “cloud-friendly” is better than “cloud-centric” as the hybrid environment is very attractive right now.

From http://www.computerweekly.com/feature/Microservices-How-to-prepare-next-generation-cloud-applications “Each microservice is an independent, autonomous process with no dependency on other microservices. It does not even know or acknowledge the existence of other microservices.

Microservices communicate with each other through language and platform-agnostic application programming interfaces (APIs). These APIs are typically exposed as Rest endpoints or can be invoked via lightweight messaging protocols such as RabbitMQ. They are loosely coupled with each other avoiding synchronous and blocking-calls whenever possible.”

The first of these two paragraphs says that each microservice is “independent” from other microservices and the second paragraph says “microservices communicate with each other” thus there is some dependency.

Certainly, microservices are interdependent by design and operationally-independent. It seems that microservices may refer to each other indirectly via a “naming service” (some kind of URI to URL mapper or like in CORBA). Therefore, a microservice may employ other microservices to complete its work. In extreme, a microservice may be an assembly of microservices. Article http://microxchg.io/2015/slides/02_01_DomainServiceAggregators.pdf provides an example of data aggregation with a business domain.

From http://www.ben-morris.com/how-big-is-a-microservice/ ‘Perhaps “micro” is a misleading prefix here. These are not necessarily “small” as in “little”.’

Yes, size in LOC does not matter. There is only one limit – SRP. Interesting, that no limitations on “size” of this single responsibility. Thus a microservice with a greater and single responsibility may be assembled from microservices with lesser and single responsibilities.

From https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/ “In the comments, it was suggested that granularity was irrelevant as multiple granular microservices could be composed to form a coarser-grained microservice that would provide a more appropriate level of abstraction. My response was that while this is theoretically true, aggregating service calls in that manner risks issues due to network latency.”

In addition for my comments to that blogpost, I would like to add that designing microservices as distributed autonomous components (each with own computing process) is forcing to consider (up-front and not as refactoring) a proper error-recovery which is much more difficult than the error-handling when components are in the same computing process.

From http://avirosenthal.blogspot.co.il/2015/04/micro-services-new-soa-style.html “How could a [Business] Capacity will be related to a Fine Grained entity such as Micro Service?”

In general, a business capability is a cohesive set of processes (or cluster of processes in accordance with http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ). Those processes are implemented as assemblies of microservices. Some of those microservices are unique for a particular process and for a particular cluster; others are shared between clusters.

From https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/ “Microservices and their granularity are ideal for the development and maintenance of the service. But that does push complexity more towards the app itself. A complexity that those apps cannot manage as they are often executed on platform with constrained resources (battery, network, CPU). Combining services in a higher level logic to serve the purpose of apps or business processes proves to be faster to develop and easier to maintain.”

Yes, assembling of microservices is the way to reduce complexity.

From http://martinfowler.com/articles/microservices.html “In short, the microservice architectural style is an approach to developing a single application as a suite of small services.”

If application as a unit of deployment (even decomposed into a few tiers) is no more the physical boundary then boundaries becomes logical and they are coming from the business – business functions, business services and business capabilities. Note they are actually just different viewpoints – see “Common understanding of #bizarch (business architecture) and #BPM” http://improving-bpm-systems.blogspot.ch/2015/01/common-understanding-of-bizarch.html . Less IT applications and more business-process-centric solutions.

From http://nealford.com/memeagora/2015/03/30/architecture_is_abstract_until_operationalized.html “Continuous Delivery and the DevOps movement illustrated the pitfalls of ignoring the effort required to implement an architecture and keep it current. There is nothing wrong with modeling architecture and capturing those efforts, but the implementation is only the first step. Architecture is abstract until operationalized. In other words, you can’t really judge the long-term viability of any architecture until you’ve not only implemented it but also upgraded it. And perhaps even enabled it to withstand unusual occurrences.”

Correct, but slightly simplified observations – actually, 3 (three) major upgrades are necessary to demonstrate that architecture is good. Rationale: it is recommend leaving a solution team before the 3th major upgrade of this solution.

From http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems “Integration suites offer a complete stack that not only gives ESB capabilities but also more business-specific tools such as BPM (business process management), business activity monitoring, master data management, and a repository.”

Sorry, but ESB is not the centre of the universe if the business position is taken http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-software-architects-from.html .

4 Forces

4.1 Containers enables the free movement of microservices

As microservices are not confined any more by the physical boundaries of application, they can freely move among on-premises environments, private and public clouds, intellectual “things” and even mobile devices. See “We’re finally headed towards autonomous, self-migrating containers for cloud-application automation” http://research.gigaom.com/2014/12/are-we-moving-to-autonomous-self-migrating-containers-for-cloud-application-automation-i-think-so/

As microservices become place-independent, it is necessary to have a good “naming service” (as we had in CORBA) to allow mapping of microservice’s URI to new URL. Such “naming services” is also known as discovery services.

The most popular container is www.docker.com. From http://www.infoq.com/articles/microservices-revolution “Docker’s appeal is twofold: it’s fast and it’s portable” and “Docker containers can start, and stop, in hundreds of milliseconds.” 

4.2 Microservices vs API

At present, there is no synergy between microservices and API as illustrated by the following quotes:

• From http://sdtimes.com/digging-into-microservices/ “The fundamental difference between microservices and APIs is that microservices are used to build applications, whereas APIs are used to integrate applications...” 
• From http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/features/microservices.jhtml “In MSA (microservice architecture), integration is the problem, not the solution”. 
• http://apievangelist.com/2015/04/10/on-apis-and-microservices/

Considering that “IT application” as a physical boundary is disappearing with microservices and integration between “IT applications” often follows the span of business processes ( http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html ) then microservices and API must “fuse”.

From http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ “Part of the problem with API management and micro-services or with the mediation / message broker middleware technologies is that these can impose a software layer that is burdensome on the micro-services architecture... Let us say an approach to implementing micro-services would be to put them into a traditional API Management service as offered by a number of vendors. There would indeed be an overhead introduced because the API Layers impose a stiff penalty of authentication, authorization, then load balancing before a message can be delivered. What is needed is a lightweight version of API Management for some trusted services behind a firewall that are low risk and high performance.”

And from http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ “Micro-services however should still be implemented in an API Management framework and ESB’s, Message Brokers and other SOA architectural components still make sense in this micro-services world especially when augmented with a container composition tool. In fact these components should be used to make micro-services transparent and reusable.”

Agree about simplification of API management which should not repeat mistakes of ESB being over complicated. 

4.3 Potentials of microservices

Are microservices going to replace apps and potentially be executable in Things linked to Internet of Things ? From http://www.computerweekly.com/feature/Microservices-How-to-prepare-next-generation-cloud-applications “The evolution of the internet of things and machine-to-machine communication demands new ways of structuring the application modules. Each module should be responsible for one task participating in the larger workflow.” Also, http://iot.sys-con.com/node/3289475?utm_content=buffer97b76&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer .

Microservices and mobile apps from http://www.feedhenry.com/microservices-for-mobile/

Microservices and digital from https://www.linkedin.com/pulse/microservices-role-digital-business-architect-mike-clark and from http://forms2.tibco.com/rs/tibcoinfra/images/WP-microservices%20part1-web.pdf

Potentially better resilience from http://www.slideshare.net/ufried/patterns-of-resilience ?

Are microservices the next big thing from https://genehughson.wordpress.com/2015/04/09/are-microservices-the-next-big-thing/ . 

4.4 Concerns about microservices

From http://research.gigaom.com/2014/12/are-we-moving-to-autonomous-self-migrating-containers-for-cloud-application-automation-i-think-so/ “Using containers is not a new procedure: They certainly predate Docker. However, auto-provisioning and auto-migration are concepts that were often pushed but very remained elusive in practice.”

How does eventual consistency relate to SLA? Is eventual consistency applicable to all sectors?

Performance in https://genehughson.wordpress.com/2015/02/06/wait-did-i-just-say-knuth-was-wrong/

Misuse of technology from http://blog.christianposta.com/microservices/youre-not-going-to-do-microservices/

Challenges from https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/

A long list from http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html “Significant Operations Overhead” “Substantial DevOps Skills Required” “Implicit Interfaces”, “Duplication Of Effort”, “Distributed System Complexity”, “Asynchronicity Is Difficult!”, “Testability Challenges”.

From http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside/ ‘However, “there is a price to pay for microservices,” cautions Thomas. “You are increasing the complexity of the application system by having a lot more moving parts and a lot more interdependencies.”’

Various system-design related concerns from http://particular.net/blog/microservices-future-or-empty-hype .

A longer list on slide 34 from http://www.slideshare.net/myfear/eisele-architecting-largeenterpriseprojects-46546852 .

A collection of scaring factors from http://www.infoq.com/research/adopting-microservice-architecture?utm_source=infoqresearch&utm_campaign=rr-content .

And a few future problems from http://www.thoughtworks.com/talks/software-development-21st-century-xconf-europe-2014 .

5 Characteristics of cloud-scale applications

From http://devops.com/blogs/containers-designed-antiquated-application-architecture/ “Cloud-scale applications by nature are stateless with any application state being managed by cache or database services. The compute unit of measure is the process not the CPU, which enables greater scalability. .... They scale across network architectures easily allowing businesses to run in private data centers and leverage cloud for excess capacity when needed.”

From http://thenewstack.io/best-practices-for-developing-cloud-native-applications-and-microservice-architectures “Be micro”, “Be explicit”, “Be stateless”, “Be temporal”.

From http://12factor.net/backing-services “Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.” and “Treat backing services as attached resources”.

From http://www.infoq.com/articles/microservices-revolution “The point is that in the modern stateless application architecture, state is actually everywhere--and this state needs to be managed.”

A huge list from http://cloudramblings.me/2015/03/20/microservices-martin-fowler-netscape-componentized-composable-platforms-and-soa-service-oriented-architecture/ .

Slide 68 from http://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices .

6 Becoming cloud-friendly

6.1 State management

Potential techniques for the state management:

1. one persistency service (or backing service) for the state of the whole solution (even distributed solution) 
2. predefined state which is created by embedding state into an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) 
3. idempotency 

6.2 Performance

Potential techniques for performance improvement (primarily the network latency):

1. easy moving an individual containerized copy of the microservice between nodes (thus moving a microservice close to its consumer upto his/her mobile device) 
2. on-demand creating an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) 
3. creating an individual containerized copy of the microservice for a particular consumer to diminish the security overhead (but the run-time knowledge about the context is mandatory) 

6.3 Lightweight security

1. predefined state which is created by embedding security keys into an individual containerized copy of the microservice (but the run-time knowledge about the context is mandatory) thus achieving self-containment of PEPs 
2. one-off execution (i.e. self-destruction) 

See also the blogpost “Enrich RBAC and ABAC with ProBAC” http://improving-bpm-systems.blogspot.ch/2015/01/enrich-rbac-and-abac-with-probac.html which explains how the run-time knowledge about the context can be provided to achieve “embedded” security.

7 Cloud-friendly architecture

Let us look at the post “Architecting application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2014/12/architecting-application-architecture.html and extend the described in it architecture to being cloud-friendly. In that blogpost, I introduced Autonomous Component (AC) with a note that at present, it is not possible to claim that ACs are microservices or services.

This architecture implements business solutions (instead of IT applications because the boundaries of IT applications are not relevant any more) as a coordinated collection of autonomous components. Each AC is a unit of functionality (as SRP) which can be executed in its own computing process (thus a unit of deployment which can be deployed in a separate host somewhere). An AC may be an assembly of several ACs. In general, ACs are structurally interdependent, behaviorally (or operationally) independent and contractually dependent.

Below, several typical ACs are described from the “being cloud-friendly” viewpoint through the following characteristics:

• state: “stateless”, “stateful” 
• idempotency: “yes”, “no” 
• instantiation: “availability-based”, “on-demand” (or “lazy loading”), “individual” 
• place: “place-dependent”, “place-independent”, “multiple-place-independent” 
• security: RBAC, ABAC, ProBAC, “embedded” 

Resource-access (RA) AC to carry out basic operations over data or documents which are stored in a single repository.

• Cloud-friendly: stateful, place-dependent for updates, place-independent for reads, idempotent, availability-based-instantiation. 
• Security techniques: RBAC, ABAC and ProBAC. 
• Contracting ACs: No use of other ACs. 
• Examples: access to a database, access to a document management repository. 
• Note: Usually have an internal database. 

Resource-assembly-access (RAA) AC to carry out basic operations over a compound business entity (which comprises several resources).

• Cloud-friendly: stateless, multiple-place-independent, idempotent, on-demand-instantiation. 
• Security techniques: RBAC, ABAC, ProBAC and embedded. 
• Contracting ACs: Use of some ACs, primarily, resource-access ACs. 
• Example: virtual data layer, MDM. 

Persistence backing (PB) AC to keep a state or configuration.

• Cloud-friendly: stateful, place-dependent, idempotent, availability-based-instantiation. 
• Security techniques: ProBAC. 
• Contracting ACs: No use of other ACs. 
• Example: Database persistence layer. 

Utility (U) AC to transform or analyse data/documents.

• Cloud-friendly: stateless, multiple-place-independent, individual-instantiation 
• Security techniques: RBAC, ABAC, ProBAC and embedded. 
• Contracting ACs: No use of other ACs. 
• Note: May have its own configuration database. 
• Example: Word-to-PDF converter. 

DSL-manager (DM) AC to manage DSL scripts.

• Cloud-friendly: stateful, multiple-place-independent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Use its own configuration persistence backing AC. 
• Example: A business rules engine, process execution languages. 

DSL-processor (DP) AC to execute scripts in the DSL.

• Cloud-friendly: stateless, multiple-place-independent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Stateful DSL-processor has its own state persistence backing AC. 
• Note: Business rules are considered be immutable thus its DSL-processes is stateless.

DSL-script (DS) AC to execute a particular DSL algorithm with some parameters.

• Cloud-friendly: stateless or stateful, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: Use DSL-processor AC. 
• Example: A particular rule for a particular business rules engine. 

Resource role-based mini-portal (RRBMP) AC to select data/documents and initiate an operation on them as a user-facing AC.

• Cloud-friendly: stateless, multiple-place-independent, availability-based-instantiation 
• Security techniques: RBAC. 
• Contracting ACs: Use of some resource-access ACs and short-running ACs. 
• Example: Web-client or Fat-client for a document management system. 
• Note: Operation are usually short-running human and short-running automated ones. 

Functional role-based portal (FRBP) AC to select a function and execute it with some data/documents as a user-facing AC. It provides two types of operations: 1) static list of functions what this role may do and 2) dynamic list of activities what this role has to do. A function is a set of activities.

• Cloud-friendly: stateless, multiple-place-independent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Use some various ACs. 
• Example: Intranet with some workflows. 
• Note: There are two types of operations: 1An operation may be short-running human, short-running automated and long-running one. The latter is a coordination of short-running ones and other long-running ones. 

Human operation (HO) AC to interact with a human.

• Cloud-friendly: stateless or stateful, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: May use some resource-access, resource-assembly-access and utility ACs. 
• Example: Interactive form. 
• Note: The state is kept in a solution-state persistence backing service. 
• Note: Human operation AC may be short-running and long-running. 

Automated operation (AO) AC to transform some resources and/or solution-state data.

• Cloud-friendly: stateless, idempotent, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: May use some resource-access, resource-assembly-access, utility and other ACs. 
• Example: PublishDocument 
• Note: May be implemented as a robot (scripts and their processor). 
• Note: Automated operation AC may be short-running and long-running. 

Implicit coordination operation (ICO) AC to coordinate several human and automated operations AC.

• Cloud-friendly: stateful, place-dependent, individual-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Human and automated operations ACs. 
• Example: A composite service. 
• Note: Implicit coordination operation AC may be short-running and long-running. 

Explicit coordination operation (ECO) AC to coordinate several human and automated operations AC.

• Cloud-friendly: stateful, idempotent, multiple-place-independent, individual-instantiation. 
• Security techniques: RBAC, embedded. 
• Contracting ACs: Human and automated operations ACs. 
• Example: An assembly of other ACs. 
• Note: Used human and automated operations ACs may be unique for this coordination operation AC. 
• Note: It is implemented in a DSL; its DSL-processor AC has its own state persistence backing AC which acts as solution-state persistence backing AC. 
• Note: Explicit coordination operation AC is mainly long-running. 

Legacy pseudo (LP) AC to access functionality of a legacy system.

• Cloud-friendly: stateful, place-dependent, availability-based-instantiation. 
• Security techniques: RBAC. 
• Contracting ACs: Unknown. 
• Example: ERP. 

8 Demo

The cloud-friendly application architecture is demonstrated on video below to show how various ACs implement a typical process-centric solution (this video is inspired by http://improving-bpm-systems.blogspot.ch/2014/12/bpm-for-soaesbapi-and-cloud-paas-and.html ). Obvious, presented scenario may handle several process-centric solutions and several copies of the same solution (a copy per user) simultaneously.

The scenario has the following stages:

a) The functional-role-based-portal AC offers to a user some functions to initiate (as a static list). Each of functions is an explicit-coordination-operation AC which comprises several human-operation ACs and automated-operation ACs. Human-operations ACs are to be executed by users and they are dynamically listed for each users.

b) All explicit-coordination-operation ACs are implemented as DSL-script. The DSL-manager AC provides a list of functions which are offered for users. The DSL-processor AC provides a list of activities which have to be executed by some users.

c) A user executes a function which is implemented as a DSL-script; the DSL-manager AC instantiates an individual copy of this explicit-coordination-operation AC via the DSL-processor AC. (Covered by markers 1-3.)

d) The first of two operations within this explicit-coordination-operation AC is the automated-operation AC which uses several other ACs; the explicit-coordination-operation AC instantiates an individual copy of this automated-operation AC and individual copies of two of ACs used by it (“Utility” and “Resource assembly access”). Then the automated-operation AC is executed (Covered by markers 4-6.)

e) The second of two operations within this explicit-coordination-operation AC is the human-operation AC; the explicit-coordination-operation AC instantiates an individual copy of this human-operation AC and an individual copy of the other AC used by it. (Covered by marker 7).

f) The human operation AC must be completed by a user and it informs the explicit-coordination-operation AC. (Covered by markers 8 and 9).

g) The explicit-coordination-operation AC terminates.

and its static view

9 Conclusion

The cloud-friendly application architecture follows the business domain boundaries, processes, entities, documents, roles and rules.

The cloud-friendly application architecture reduces complexity by adding a structure among ACs:

• long-running functions (actually, business processes) 
• short-running operations (actually activities or routines) 
• assembly of resources (actually, business entities or business objects) 
• resource (actually data and documents) 

The cloud-friendly application architecture reinforces the information security by dynamics security for resources and embedded security for ACs

In the cloud-friendly application architecture the majority of ACs are cloud-friendly thus solutions based on this architecture are scalable.

The cloud-friendly application architecture covers majority of cross-cutting concerns : event handling, error recovery, persistence (state management), concurrency, security, interactions, distributed transactions, logging, monitoring and testing.

Thanks,
AS