1. Overview

2. Definition

3. History

4. Philosophy

5. Route-rule Implementation

6. Code sample

7. Defining a team worker's scope

8. Other interactions

9. References

Team workers (derived from team and, replicated workers) or Teamed services (also abbreviated : "Workers") are a software development paradigm in which every service in a service-oriented architecture (SOA) may play a variety of roles for each request it receives determined by a set of route-rules, it's average calculated latency and other team workers availability and latency.

The set of rules considers the worker's ability to complete the request autonomously (and within a defined response time) or complete some of the sub tasks the request flow requires.

From a technical point a view a Team worker is a combination of code originally designed as Microservices, linked as one computer program.

While the traditional SOA pattern considers each service as a provider or a consumer, a team worker can play both provider or consumer roles, and therefore can also serve as a provider for its own request, meaning a worker may select (or be instructed by an Orchestration tool or Service Mesh) whether to pass the request to another worker or handle the request itself.

The selection of the part played by a worker should not compromise data integrity, security and latency and should be transparent for the consumer that originally sent the request.

Overview

As the trend^[1][2] to "break down" Monolithic applications to services has grown in the early 2000's, the adoption of the Unix philosophy to Do One Thing and Do It Well lead to growth of the Microservices variant, and with many advantages of the Microservices approach, some new challenges^[3][4] were introduces, and mainly point to: over-complexity, latency, greater number of point of failures, and cumbersome testing and debug-ability, with many articles^[5] pointing to pros vs cons.

Hence, a suggested approach that may harness the advantages in both Monolithic and Microservices approach became a necessity.

The Team workers paradigm tries to comply with this necessity, by keeping many of the promises from both Microservices and Monolithic design:

A team worker, restricted to "act as a microservice" rules, would only serve "One purpose" in a similar manner to a Microservice, whereas it can ignore the fact that its built from "glued" Microservices and forward the request in classic Microservice manner.

In such case the single difference between a team worker and a microservice - would be the fact that the size of the worker's binary application would be much larger, as the worker will consist a great deal of "unused code" .

However, when directed by rules that allows the worker to act with multiple roles, it resolves or narrows down some of the challenges:

1. Latency - each call handled internally within the worker, is not sent through the network, and is effectively a native function call.
2. Number of network point of failures would be lower as well (as the total number of network requests is reduced).
3. Debug-ability on a developer machine in most cases can be done running a worker as a complete Monolith - which would set all code debug accessible (i.e. all microservices linked in a single executable) .
4. test-ability - business logic tests can utilize same monolith approach, other test coverage (load test, real prod environment mimic etc) would still require a distributed environment.
5. Over-complexity in most cases cannot benefit from a team worker approach, in some case, creating a complicated set of route-rules might as well create another level of complexity.
6. Reliability can also gain if a fail-over rule is set, so when a specific request from a worker to another fails or times out, assuming the worker contains the requested logic, it can try to resolve the request internally.

Definition

An application must satisfy the below terms to admit as a team worker:

1. It meets the definition of a network service.
2. It is build from at least two individual sets of code (hereby: subsets) which could be compiled into an independent service, linked together to one executable.
3. It may serve as the provider for at least one of the request it consumes, whereas one subset is the consumer and another is the provider.
4. It has either an internal algorithm, API or service hook, that instructs each request the worker is about to consume whether to be routed internally into another subset or externally to another worker or service.

History

The use of RPC (Remote procedure call) is dated to the early 1980's and alternating to Remote method invocation during the 1990's, the concept on which objects and classes are remotely served became common.

In some RPC models such as Microsoft DCOM specific method invocation were either machine level registered as local or remote^[6] or dynamically launched local or remote with a call parameter of a server name^[7], thus creating a dynamic environment on which an object can be defined as a local service or remote.

With the birth of microservices and their quick adoption^{[8] [9]} application domain often calls a small set of methods (e.g. CRUD, RESTful and other less general purpose methods), a similar ability to allocate the service provider relies on service discovery that forces the selection of a service provider using rules and patterns ^{[10] [11] [12]} that adds another communication layer between the consumer and provider services.

Many articles^{[13] [14]} cover the pros and cons of monolith vs microservices approaches, naming the microservices drawbacks mainly in two groups:

1. Maintenance overhead (development complexity, end to end test-ability, troubleshoot, monitoring, dependency management, high dependency on devops)
2. Performance overhead (communication, machines/containers and therefore RAM and CPU)

Since these drawbacks are not minor, a "Death for microservices" movement articles and blogs ^{[15] [16] [17]} started appearing, calling for a "more sane" solution suggesting a "more monolith" design, and while doing that often tell how a failing microservices solution was re-bounded either by topic to a "pack of few services" or a one monolith.

At January 2019 the idea that "combining the monolith and microservices" can lead to a "utilizing the best in two approached" gave birth to Team workers, first publicly discussed in Oracle hosted Golang meetup ^[18] .

Philosophy

The philosophy behind team workers can be summarized by:

• Software engineers often design language and architecture that matches real world patterns (such are the Natural language in Imperative programming, Neural circuit in Artificial neural network for Machine learning/Artificial intelligence).
• Programs, like humans solves simple and complex problems.
• A "Do One thing and Do It Well" philosophy for a human can sometimes solve complex issues in steps, but rarely modern human teams are combined of people that does very small repeated similar jobs, the versatility of a team member is not only a key for the member's own success, but sometimes is the key to the whole team's success.
• Each time a team member passes a task to another team member the need for passing the data and status of the task, can be time consuming, and error prone, and while strict responsibilities sometimes force that, an "overall responsibility" is sometimes missed.
• Therefore forwarding/passing a job or splitting it with another team member(s) should be done with consideration: an "Assembly line" many the times benefit from each worker tool or machine doing a single repeated job, while in a football team, any player with any position would be expected to do any duty (to a degree) in order to "win". similar concepts repeat in many other games^{[19] [20] [21]} , this does not however suggests that "all players are the same, and moreover some players have benefits/duties/privileges that other players do not, such as the Goalkeeper.
• Adopting from a human "team member" a team worker "service" should be able to "select" (or be instructed to) when to pass the task and when to try and handle it solely, according to his abilities, availability and the pros vs cons of passing the task to another team member .

Route-rule Implementation

Every interface between a consumer and a provider, should alternate a selection for either use the internal function built in the worker, or send the request to the provider.

A basic pseudo code sample that implements a route-rule based on the busy state of worker would look like this:

func Do(job Job) {

if isbusy(){

} else {

}

• Selwyn Richardson
• Selwyn River, New Zealand
• Selwyn School
• Selwyn Selwyn-Clarke
• Selwyn Snowfields
• Selwyn snowfields
• Selwyn's Rock
• Selwyn Walford Young
• Selwyn Z. Bowman
• Selydove
• Selyeb
• Selyf ap Cynan
• Selyf Sarffgadau
• Selys
• Selys longchamp
• Selys longchamps
• Selz
• Selz Abbey
• Selzach
• Selzach SO
• Selzach (Solothurn)
• Selzach, Switzerland
• Selzentry
• Selz (River)
• Selá