Service Weaver: A Promising Direction for Cloud-Native Systems?

Jacoby Johnson

, Subash Kharel

, Alan Mannamplackal

, Amr S. Abdelfattah

and Tomas Cerny

Computer Science of Baylor University, Waco, Texas, U.S.A.

Systems and Industrial Engineering, University of Arizona, Tucson, Arizona, U.S.A.

Keywords:

Service Weaver, Cloud-Native Systems, Microservices, Modular Binary, Cloud Computing.

Abstract:

Cloud-Native and microservice architectures have taken over the development world by storm. While be-

ing incredibly scalable and resilient, microservice architectures also come at the cost of increased overhead

to build and maintain. Google’s Service Weaver aims to simplify the complexities associated with imple-

menting cloud-native systems by introducing the concept of a single modular binary composed of agent-like

components, thereby abstracting away the microservice architecture notion of individual services. While Ser-

vice Weaver presents a promising approach to streamline the development of cloud-native applications and

addresses nearly all signiﬁcant aspects of conventional cloud-native systems, there are existing tradeoffs af-

fecting the overall functionality of the system. Notably, Service Weaver’s straightforward implementation and

deployment of components alleviate the overhead of constructing a complex microservice architecture. How-

ever, it is important to acknowledge that certain features, including separate code bases, routing mechanisms,

resiliency, and security, are presently lacking in the framework.

1 INTRODUCTION

Cloud-native systems and the development of mi-

croservice architecture have taken center stage in the

realm of distributed systems software. While mi-

croservices undeniably enhance functionality, offer-

ing improved availability and scalability, they intro-

duce heightened system complexity and pose vari-

ous challenges (Abdelfattah and Cerny, 2023b; Cerny

et al., 2022). Beyond managing business logic, a

microservice architecture must address inter-service

communications, necessitating the implementation of

service registry, discovery, and routing mechanisms.

Additionally, the deployment process presents its

own set of challenges, requiring careful conﬁgura-

tion management for swift and reliable deployment

to uphold system scalability (Abdelfattah and Cerny,

2023b; Bushong et al., 2021).

The potential for simplifying the intricate pro-

cesses of creating, deploying, and maintaining mi-

croservices is indeed promising. In case of the com-

plexities involved in managing such challenges could

be abstracted for practitioners, the tasks associated

with creating, deploying, and maintaining microser-

vices would undergo a notable simpliﬁcation. This

abstraction could potentially streamline the develop-

ment workﬂow, enhance efﬁciency, and empower de-

velopers to focus more on core application logic, fos-

tering a more seamless and productive development

experience.

Service Weaver (Ghemawat et al., 2023; Google,

2023) emerges to serve in this direction as a program-

ming framework for writing and deploying cloud ap-

plications. It enables practitioners to write their pro-

gram in a modular binary and then that binary can

be deployed as a microservice through a lightweight

conﬁguration ﬁle. This offers developers ﬂexibility

for development and testing, whether it’s done locally

or in a cloud environment.

At ﬁrst glance it serves as a focal point of explo-

ration, prompting compelling questions about its ca-

pabilities and potential. At a high level, this could be

revolutionary for cloud-native systems; however, per-

fect solutions simply don’t exist and an in-depth look

at the beneﬁts and the drawbacks of implementing

a new technology must always be considered. This

paper aims to delve into the question of: ”Is Ser-

vice Weaver capable of covering cloud-native com-

ponents while maintaining the full functionality of a

microservice architecture?” Unraveling this question

will guide our investigation into the unique attributes

and functionalities of the Service Weaver in the con-

text of modern cloud-native architectures.

The rest of the paper is organized as follows,

Johnson, J., Kharel, S., Mannamplackal, A., Abdelfattah, A. and Cerny, T.

Service Weaver: A Promising Direction for Cloud-Native Systems?.

DOI: 10.5220/0012624500003711

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 14th International Conference on Cloud Computing and Services Science (CLOSER 2024), pages 167-175

ISBN: 978-989-758-701-6; ISSN: 2184-5042

167

Section 2 stated the research questions. A brief

background into existing cloud-native components is

shared in Section 3. The heart of this paper, in Sec-

tion 4, is dedicated to exploring Service Weaver ca-

pabilities and its potential application. In Section 5

the research questions were addressed, and in Section

6 the conclusion was drawn. While Service Weaver

is a new technology, the authors believe it to be po-

tentially impactful and could see it having a role in

shaping the future of cloud-native systems.

2 RESEARCH QUESTIONS

Service Weaver, with its modular binary approach,

proposes a solution to simplify the microservices

model of development. However, the efﬁciency of

Service Weaver in meeting the core requirements of

cloud-native systems, such as scalability, ﬂexibility,

and resilience, while dealing with the complexities

of traditional microservices architectures, remains an

open question. This question fuels this research to po-

sition the capabilities of Service Weaver within cloud-

native context, assessing its suitability for building ef-

fective and robust cloud-native systems.

: What Advantages Does Writing Your

Application as a Modular Binary Offer in

Comparison to Using Microservice Architecture?

The modular binary methodology involves consoli-

dating all components into a single executable ﬁle, a

concept facilitated by the Service Weaver. This ap-

proach raises questions about the potential beneﬁts in

terms of reduced complexity and the adaptability to

deploy modular components as microservices. This

question navigates the modular approach’s challenges

such as network latency, debugging, testing, and re-

source management which are often associated with

microservice architecture.

: Is the Service Weaver Capable of

Effectively Covering Cloud-Native Components?

Cloud-native components, known for enabling scal-

ability, ﬂexibility, and resilience in cloud comput-

ing environments, present a crucial consideration for

modern applications. This question revolves around

Service Weaver’s ability to streamline application

development, offering choices between a modular

monolith and microservice-based systems develop-

ment and deployment. It addresses the alignment of

Service Weaver with the essential features required

for cloud-native components, including separation of

concerns, scalability, resiliency management, and de-

ployment ﬂexibility behavior across diverse deploy-

ment environments.

3 BACKGROUND

Cloud-native and microservice architectures are cen-

tered around the creation of scalable, ﬂexible, and re-

silient applications. To achieve these attributes, var-

ious components are introduced to assist practition-

ers in their development endeavors. The stack en-

compasses infrastructure, provisioning, runtime, or-

chestration, management, application deﬁnition, and

observability layers (Abdelfattah and Cerny, 2023b;

Amazon, 2024).

Microservices, foundational to cloud-native appli-

cations, are designed as small, interdependent ser-

vices that break down functionalities into smaller, in-

dependent units to enhance agility and resource ef-

ﬁciency (Abdelfattah and Cerny, 2023b; Amazon,

2024). These microservices communicate with each

other through network protocols and message passing

to accomplish tasks. The scalability of cloud-native

systems underscores the signiﬁcance of the Service

Discovery component, which dynamically locates the

network locations of microservices, facilitating their

interaction in distributed environments. This ensures

seamless communication among services, adapting to

changes in their network locations or instances (Car-

nell, 2021). Additionally, the API Gateway compo-

nent functions as a critical component in managing in-

coming requests to microservices, serving as an entry

point for clients. It routes requests, handles load bal-

ancing, and may implement security measures such

as authentication and rate limiting (Carnell, 2021).

Research leverages the API Gateway component to

address recurring communication challenges with the

client side (Abdelfattah. and Cerny., 2023).

On the other hand, various dependencies are

present in microservices architecture components,

ranging from explicit inter-service calls to implicit

data model sharing between microservices (Abdelfat-

tah and Cerny, 2023a). As the system evolves, man-

aging and scaling these dependencies becomes com-

plex, leading to the emergence of multiple bad prac-

tices (i.e., anti-patterns) (Cerny et al., 2023) in mi-

croservice implementation. Consequently, effectively

managing dependencies poses challenges in maintain-

ing the quality and health of the architecture.

CLOSER 2024 - 14th International Conference on Cloud Computing and Services Science

168

4 COMPARING MODULAR AND

MICROSERVICE

ARCHITECTURES

In this section, we delve into a comparative discussion

of Modular Architecture and Microservice Architec-

ture, two prevalent paradigms in the realm of software

design. Each approach presents unique advantages

and challenges, inﬂuencing how practitioners struc-

ture and organize their applications.

4.1 Modular Architecture

Modular architecture emphasizes strong encapsula-

tion and well-deﬁned interfaces. This approach hides

implementation details within components, leading to

low coupling between different parts. It allows differ-

ent teams to work independently on separate compo-

nents, which then come together in a single deploy-

ment unit. This fosters parallel development while

maintaining overall system coherence.

Modular architecture’s advantage lies in its bal-

ance between monolithic and microservice architec-

tures. It provides the isolation and independence of

microservices while maintaining the simplicity and

ease of development found in monolithic systems.

This approach reduces the overhead for developers, as

the system is more straightforward to understand and

maintain, and it avoids the network complexity often

associated with microservices. Modular architecture

can be particularly beneﬁcial for small to medium-

sized teams or applications where full-scale microser-

vices might be overkill (Media, 2017). Additionally,

this architecture fosters the Improved Maintainabil-

ity. With clear boundaries and well-deﬁned responsi-

bilities among modules, it simpliﬁes bug ﬁxing and

adding new features. This leads to a better under-

standing of the codebase and reduces time and costs

for maintenance tasks (AppMaster, 2023).

4.2 Microservice Architecture

Microservice architecture, while offering scalabil-

ity and ﬂexibility, introduces signiﬁcant operational

complexity. It allows teams to work and scale inde-

pendently, as each microservice can be managed and

scaled as a separate entity.

The primary advantage of microservice architec-

ture is its ability to scale components independently

and its resilience. Each service can be deployed,

scaled, and updated without impacting other services,

making the system more robust against failures. This

architecture is ideal for large, complex applications

where different services require different technologies

and scalability needs. It facilitates continuous deliv-

ery and deployment, allowing businesses to respond

rapidly to market changes or customer demands (Me-

dia, 2017).

Additional advantages of this architecture include

Enhanced Team Productivity and Specialization, al-

lowing focused teams to develop and maintain spe-

ciﬁc services. This develops ownership and exper-

tise. Agility in Deployments is enhanced, as ser-

vices evolve and deploy independently, speeding up

releases and reducing coordination risks (Atlassian,

2024).

4.3 Clariﬁcation Example

Illustrating the architectural structures of both mod-

ular and microservices frameworks, consider an ex-

ample of an online retail application. This applica-

tion encompasses the following functionalities: in-

ventory management, order processing, customer ac-

count management, payment processing, shipping co-

ordination, and search processing. Together, these

functionalities seamlessly orchestrate the entire shop-

ping experience, spanning from product selection to

order fulﬁllment.

In a modular architecture, as depicted in Fig-

ure 1, these functionalities are developed as distinct

modules but within a single application. This means

that while inventory management, order processing,

and other services are separate in terms of their code

and functions, they coexist within the same applica-

tion boundary and share common resources like a cen-

tral database.

Figure 1: Modular Architecture of a Retail Application.

On the other hand, in a microservice architec-

ture, as illustrated in Figure 2, each of these function-

alities is treated as an independent microservice while

the lines between them symbolize network communi-

cation, often using REST APIs. Each microservice

Service Weaver: A Promising Direction for Cloud-Native Systems?

169

is compiled and deployed separately and has its dedi-

cated storage and resources. They communicate with

each other over a network, often using REST APIs.

Figure 2: Microservice Architecture of a Retail Applica-

tion.

While both architectures strive for modularity, the

representation of the decentralized nature of microser-

vice architecture contrasts with the centralized, inter-

connected structure of modular architecture. How-

ever, the separation in microservice architecture en-

hances scalability and reduces complexity in manag-

ing individual components (Carnell, 2021), however,

it challenges the management of the holistic view of

the system, while it distributes functionalities across

independently deployable units.

4.4 Frameworks for Modular

Architecture

Despite the recent surge in discussions surround-

ing module architecture, as revealed by a systematic

grey literature review (Su and Li, 2024), the results

highlight the rising popularity of modular monoliths,

which offer a fusion of monolithic and microservices

beneﬁts. The review encompassed 64 studies, with a

signiﬁcant increase observed in 2023. Alongside Ser-

vice Weaver, two other frameworks listed by the au-

thors for building modular monolith architecture are

Spring Modulith and Light-hybrid-4j.

The Spring Modulith (Spring, 2024) framework

introduces an experimental approach for develop-

ing modular monolith applications within the Spring

framework. It organizes source code based on the

module concept, providing conventions and APIs

for declaring and validating logical modules within

Spring Boot applications. Key features include ap-

plication modules representing units of functional-

ity, module encapsulation, and restricted type visibil-

ity between modules. Additionally, it includes ad-

vanced features such as enhanced package arrange-

ments, ﬂexible module selection for integration tests,

automatic developer documentation generation, run-

time observability at the module level, and Passage of

Time Events implementation.

The light-hybrid-4j (NetworkNT, 2021) frame-

work, built upon the light-4j framework, is tailored

for modular monolithic architectures and serverless

deployments within the Light platform. It offers ﬂex-

ibility and cost savings in production by enabling

modular deployment. The framework involves creat-

ing a server with integrated third-party dependencies

and building multiple services with shared or speciﬁc

dependencies. These services are compiled into in-

dependent jar ﬁles containing business handlers and

loaded into a designated folder on the host server dur-

ing startup. Trafﬁc is routed to the appropriate han-

dler in each service for incoming requests. Develop-

ers follow the principle of building services into jar

ﬁles, deploying them to the same Docker container

volume, and loading them into the same JVM. Ser-

vices communicate through interfaces to conceal im-

plementation details, and if necessary, services under

heavy loads can be separated into individual contain-

ers for scalable deployment.

While still in development, Service Weaver (Ghe-

mawat et al., 2023) boasts superior capabilities com-

pared to conventional modular frameworks. It is in-

troudced to offer high performance, with co-located

components communicating through direct method

calls and remote components utilizing efﬁcient cus-

tom serialization and RPC protocols. Additionally,

Service Weaver requires minimal conﬁguration and

easily deploys to the cloud without extensive setup. It

also provides libraries for logging, metrics, and trac-

ing, seamlessly integrated into the deployed cloud en-

vironment.

5 EXAMINING SERVICE

WEAVER THROUGH THE

LENS OF CLOUD-NATIVE

PERSPECTIVES

Service Weaver packages core application logic in a

modular binary structure for deployment, contrasting

with the multiple codebases and deployments com-

mon in microservice architecture. When evaluating

a new technology or framework, it is customary to

compare it to the prevailing standard practices. In

the context of examining the advantages and draw-

backs of Service Weaver, it proves advantageous to

scrutinize each component and assess its functionality

against the conventional implementation in a cloud-

native system, adhering to established best practices,

as outlined in the 12 factors (Wiggins, 2017).

CLOSER 2024 - 14th International Conference on Cloud Computing and Services Science

170

The subsequent subsections iterate through the

cloud-native components, exploring the offerings of

Service Weaver in fulﬁlling each of them as summa-

rized in Table 1.

Table 1: Service Weaver Components.

Cloud-native Component Integrated Dev. Res.

∗

(C1) Services ✓

(C2) Inter-Service Communication ✓

(C3) Conﬁguration Management ✓

(C4) Deployment ✓

(C5) Resiliency ✓

(C6) Security ✓

(C7) Storage ✓

(C8) Logging ✓

(C9) Tracing ✓

(C10) Metric Tracking ✓

Dev. Res.

∗

: Developer Responsibility.

(C1) Services. Service Weaver’s main abstraction

that functions in the place of a service is that of a com-

ponent. A component is essentially a method imple-

mented by Service Weaver that acts as a stand-alone

software agent, handling its business logic and com-

municating with other components. Although poly-

glot support stands as a signiﬁcant advantage for mi-

croservices and cloud-native systems, it’s worth not-

ing that Service Weaver currently only supports the

GO programming language for implementation.

Moreover, the idea remains the same as a ser-

vice, a component will have a narrow scope and

will be stateless in its functionality. The difference

is that all Service Weaver applications’ components

are intended to be stored together in a single binary,

whereas with microservices, services are not pack-

aged within a single binary or else the system would

be classiﬁed as a monolith.

By using a single binary with components, the

code base could be more manageable for a single in-

dividual/group; especially if much of the boilerplate

code has been abstracted away using Service Weaver.

A problem that could arise with this single binary

scheme is if an application grows to the point of need-

ing to be managed by multiple teams. With a cloud-

native system, each service has its code base and can

be managed by a separate team without ever needing

to cross paths with other services, teams, and their

code bases. This tradeoff between centrally managed

components and individually managed services needs

to be considered when selecting an application’s ar-

chitecture (Ghemawat et al., 2023).

(C2) Inter-Service Communication. When com-

pared to inter-service communications between

Cloud-native services, inter-component communica-

tions using Service Weaver are much easier to digest

and could lead to performance increases; however,

they might lack some functionality. The way com-

ponents communicate with each other using Service

Weaver is as simple as calling a method. Since com-

ponents are in the same binary, one component need

only call another’s method that has been deﬁned us-

ing an interface. Message passing happens locally

for co-located components, otherwise, remote proce-

dure calls are made for separate deployments. The

abstraction of implementing remote procedure calls

simpliﬁes inter-component communication for devel-

opers, expediting the setup process and potentially en-

hancing performance, especially for local calls, where

RPCs can incur signiﬁcant overhead costs.

Digging into method calls being used for inter-

component communication, it should also be noted

that this abstraction would also abstract away the im-

plementation details of service discovery and API

gateway services. Service Weaver manages how it

implements remote procedure calls and this includes

knowing the deployed location of the components and

load balancing the method calls appropriately. This

means that instead of incurring all the heavy over-

head of using something like Eureka to manage ser-

vice discovery and then spinning up an API gateway

service, a developer can simply call a component’s

method and not have to worry about the semantics of

how things get accomplished. This could greatly re-

duce development time and complexity.

While this abstraction has many beneﬁts, it also

restricts some functionality of a system that is im-

plementing Service Weaver. To begin with, it looks

like speciﬁc implementations of message passing,

like priority queues, have yet to be implemented,

though it does look like Service Weaver incorporates

speciﬁc port listeners. Service Weaver documenta-

tion (Google Open Source, 2023) does not mention

support for pre or post ﬁlters on messages, or manip-

ulation of message headers, common features in API

gateways for microservice architecture. One could ar-

gue that the input/output structure of the method be-

ing called could just be changed to accommodate for

this; however, there could be bloat associated with the

message passing in this way. Inter-component com-

munications require balancing developer ease with

control over functionality, inﬂuencing the choice be-

tween Service Weaver and traditional Cloud-native

architecture.

(C3) Conﬁguration Management. In a Cloud-native

system, there are usually many conﬁguration ﬁles;

typically, at least one per service, and sometimes this

number can be exceeded if different environments are

being used for each service. These conﬁg ﬁles are

usually housed in some centrally available repo that

is stored separately from the source code of the ser-

Service Weaver: A Promising Direction for Cloud-Native Systems?

171

vices. Conﬁguration management can get cumber-

some quickly and for this reason, Service Weaver

aims to reduce conﬁguration code as possible.

Service Weaver boasts a minimal conﬁguration

setup, as the libraries handle much of the components’

conﬁgurations automatically. This is yet another way

in which Service Weaver aims to make life easier for

the developer. There doesn’t need to be a central repo

housing conﬁguration ﬁles in this case, since every-

thing is created and deployed with a single binary and

there is also plenty of added functionality to the min-

imal conﬁg ﬁles, like the ability to declare ports and

environmental variables.

(C4) Deployment. For many development teams,

one of the most challenging aspects of managing a

project is the deployment and maintenance phases.

Often there are dedicated teams solely responsible for

this task called the DevOps team. A typical deploy-

ment for a Cloud-native system would be to package

services together in containers using something like

Docker, orchestrate those containers using tools like

Kubernetes, and then ﬁnally deploy the services to

some cloud source like Google Cloud, AWS, Azure,

etc. All these actions take time, money, and a speci-

ﬁed skill set.

With Service Weaver, component groupings are

speciﬁed in the minimal conﬁguration ﬁle, and then a

simple call can be made from the command line to de-

ploy all the components. At the time of writing, Ser-

vice Weaver can deploy locally, deploy to a generic

Kubernetes destination, or deploy to Google Kuber-

netes Engine (GKE) just by varying the command line

prompt. This offers huge beneﬁts in reducing the time

and complexity of deploying an application. The fact

that only one line must be written to transition from

local development and testing to pushing an applica-

tion to a Cloud is very impressive.

There is also the optionality to group components

together while deploying. For instance, if one wanted

to have component A and B running on a singles ma-

chine and have component C running on a separate

machine, they once again can just add a few lines into

the minimal conﬁguration ﬁle to achieve this. This

gives the developers/DevOps teams greater ﬂexibility

in choosing which components to group locally for an

increase in performance.

While the ease of deployment is readily discussed

within the Service Weaver documentation (Google,

2023), ﬁner details about deployment implementa-

tions are necessarily available. Further experimen-

tation should be conducted to understand if things

like health checks and custom scripts can be imple-

mented during the deployment of a Service Weaver

implemented application. With this being consid-

ered, it is discussed that the Kubernetes deployer is

easily integrated with common Continuous Integra-

tion/Continuous Deployment (CI/CD) pipelines like

Github Actions, ArgoCD, and Jenkins, so probably

much of the missing functionality could be imple-

mented there.

(C5) Resiliency. While microservices typically em-

ploy resiliency patterns like circuit breakers and fall-

backs to enhance fault tolerance in client calls, Ser-

vice Weaver diverges in its approach (Amazon, 2024).

As a modular monolith, Service Weaver doesn’t en-

gage in traditional client calls to other services but

rather makes remote method calls, which may exhibit

partial failures, participant failure, or result in errors.

The documentation lacks speciﬁc details on method-

ologies or libraries for handling such errors, empha-

sizing that it is the responsibility of developers to de-

tect and react to these issues (Ghemawat et al., 2023;

Google, 2023).

Consequently, developers are required to proac-

tively address potential challenges such as timeouts

or fallbacks in their code to ensure the system’s re-

siliency. Despite this shift of responsibility to devel-

opers, it’s noteworthy that the likelihood of latency

and failures in method calls is considerably lower

compared to service calls between microservices. The

reduced likelihood of latency and failures in method

calls in Service Weaver is due to its encapsulation

of components within a singular binary. This en-

ables shared memory space, promoting faster local

method calls with minimized latency. The frame-

work’s emphasis on remote method calls adds con-

trol and predictability, diminishing the probability of

failures. In contrast to microservices, where network-

based inter-service communication may introduce la-

tency and points of failure, Service Weaver’s strategy

optimizes communication within the same binary, re-

sulting in a more reliable system with fewer failures.

Moreover, Service Weaver emphasizes the sim-

plicity of conducting end-to-end tests, as applica-

tions are composed as single binaries in a uniﬁed

programming language, making end-to-end tests akin

to straightforward unit tests. This enables auto-

mated fault tolerance testing, such as chaos test-

ing (Basiri et al., 2016) and model checking (Lam-

port, 1994). This stands in contrast to the challenges

posed by testability in distributed microservice archi-

tecture components (Abdelfattah et al., 2023b).

(C6) Security. The absence of information in the doc-

umentation, articles, or blogs about the security fea-

tures of Service Weaver was disappointing. However,

one aspect that instills conﬁdence is the potential lack

of necessity for gateway services or gatekeeper ser-

vices due to its modular monolith architecture. I con-

CLOSER 2024 - 14th International Conference on Cloud Computing and Services Science

172

jecture that the security mechanism might be imple-

mented at the method level, particularly concerning

remote method calls, to ensure the integrity and conﬁ-

dentiality of data exchanged between components as

well as the consistency of role access control across

components (Abdelfattah et al., 2023a).

(C7) Storage. In a blog (Shiju Varghese, 2022),

Shiju Varghese mentioned that Weaver diverges

from frameworks like Encore, a distributed applica-

tion framework in Go that natively supports SQL

databases for storage by using PostgreSQL database

(Shiju Varghese, 2022). By refraining from mandat-

ing native support, Service Weaver allows users the

ﬂexibility to choose their preferred database, align-

ing with the characteristic ﬂexibility of microservices.

The storage functionality in Service Weaver addition-

ally facilitates the seamless integration of storage-

related preferences directly from conﬁguration ﬁles,

aligning with the microservices principle of separat-

ing conﬁguration concerns from business logic.

(C8) Logging. Service Weaver employs the

weaver.Logger API to centralize logs originating from

all components within the Service Weaver applica-

tion. It offers the capability to seamlessly integrate

logs with any cloud platform to which the application

is deployed. This achievement signiﬁcantly enhances

developers’ ﬂexibility and improves the application’s

overall portability. Building upon this, the recogni-

tion of Service Weaver as a modular monolith further

simpliﬁes the process, eliminating the need for addi-

tional layers like log forwarding to platforms such as

Logstash for log aggregation and tracing. This is a

noteworthy advantage for Service Weaver, streamlin-

ing the logging process and contributing to its overall

efﬁciency.

(C9) Tracing. Service Weaver seamlessly incorpo-

rates OpenTelemetry for tracing, providing a stan-

dardized method to collect and export traces effort-

lessly. Any trace generated within Service Weaver

is automatically exported to the deployment environ-

ment, simplifying the developer’s workﬂow. The plat-

form boasts the capability to trace HTTP requests ev-

ery second. Once tracing is activated, the system can

autonomously trace both the HTTP request and the

ensuing component method calls. (Ghemawat et al.,

2023; Google, 2023).

In contrast, in the microservices paradigm, devel-

opers have the ﬂexibility to select from a range of

tracing libraries such as Zipkin, Jaeger, and Open-

Telemetry, tailoring their choice to the speciﬁc needs

of the application. Unlike Service Weaver, automatic

trace export is not built-in, posing challenges like con-

text propagation and aggregation for developers.

(C10) Metric Tracking. Service Weaver comes

equipped with a built-in API catering to metrics like

counters, gauges, and histograms. Its integration with

deployment environments allows for the automatic

export of metrics, ensuring a seamless connection

with various platforms. In contrast, microservices

offer a range of metrics options such as Prometheus

and Grafana, providing developers with ﬂexibility to

choose tools that align with their service require-

ments. However, a notable distinction is that, unlike

Service Weaver, microservices entail additional man-

ual setup for metric services, making Service Weaver

a more automatic and streamlined option (Ghemawat

et al., 2023; Google, 2023).

6 DISCUSSION AND RESEARCH

QUESTIONS ANSWERS

This section addresses the research questions posed

in this paper, providing insights into the capabilities

of Service Weaver and its preparedness for the devel-

opment of a cloud-native system.

: What Advantages Does Writing Your

Application as a Modular Binary Offer in

Comparison to Using Microservices?

Service Weaver’s modular binary approach, as

opposed to traditional microservices architectures,

brings forth a distinctive set of advantages. The

framework’s main abstraction, the component, oper-

ates like a stand-alone software agent, encapsulat-

ing business logic and communication functionalities.

Unlike microservices, where services are dispersed

and independently managed, Service Weaver compo-

nents are stored together in a single binary, promoting

enhanced code manageability, especially with signiﬁ-

cant abstraction of boilerplate code.

Inter-component communications in Service

Weaver leverage method calls, simplifying the pro-

cess and potentially enhancing performance. With

components residing in the same binary, communi-

cation involves calling another component’s method,

eliminating the need for extensive service discovery

and API gateway services. While this simplicity

is beneﬁcial, it may limit certain functionalities

typically found in microservices architectures. For

Conﬁguration management in Service Weaver is

streamlined, requiring minimal centralized reposito-

ries for conﬁguration ﬁles. The framework’s libraries

handle components’ conﬁgurations automatically,

reducing developer burdens and enhancing overall

simplicity. Deployment and CI/CD in Service

Weaver are streamlined, emphasizing a single binary

Service Weaver: A Promising Direction for Cloud-Native Systems?

173

deployment. The framework minimizes conﬁg-

uration complexities, providing a straightforward

deployment experience for developers.

Moreover, Resiliency in Service Weaver differs

from microservices, relying on remote method calls

that may exhibit partial failures. While microser-

vices commonly implement resiliency patterns, Ser-

vice Weaver shifts the responsibility to developers,

but with a lower likelihood of latency and failures in

method calls. Regarding Security features in Service

Weaver, while not extensively documented, suggest a

potential lack of necessity for gateway services due

to its modular monolith architecture. Security mecha-

nisms may be implemented at the method level, war-

ranting further investigation.

Addtionally, Storage in Service Weaver offers

ﬂexibility by not imposing native support, allow-

ing developers to choose their preferred databases.

Storage-related preferences are seamlessly integrated

from conﬁguration ﬁles, aligning with microservices’

ﬂexibility. Logging, metric tracking, and tracing in

Service Weaver are streamlined with built-in APIs

and automatic exports to various platforms, contrast-

ing with microservices where additional manual setup

is often required.

: Is the Service Weaver Capable of

Effectively Covering Cloud-Native Components?

Service Weaver demonstrates commendable align-

ment with various cloud-native principles, encap-

sulating its functionalities in modular components

stored together in a single binary. This approach en-

hances code manageability, although potential chal-

lenges may arise in the context of larger teams

managing extensive applications. The framework

streamlines conﬁguration management by automat-

ically handling component conﬁgurations, eliminat-

ing the need for extensive centralized repositories.

Its deployment and CI/CD processes, featuring a

single-binary deployment and integration with Ku-

bernetes, signiﬁcantly reduce deployment complex-

ities. The framework’s unique approach to inter-

component communication simpliﬁes the process

through method calls, potentially leading to enhanced

performance. Service Weaver supports logging, met-

ric tracking, and tracing, showcasing its commitment

to streamlined observability.

It is crucial to highlight, that Service Weaver’s ap-

proach may involve certain compromises. Offers less

in the way of resilience and security solutions, and

needs further examination. These trade-offs under-

score the importance of balancing developmental ease

with the need for ﬂexibility and control in complex

systems. On the other hand, the modular monolith

architecture suggests potential security implementa-

tions at the method level.

Moreover, the absence of support for polyglot sys-

tems represents a notable disadvantage when Service

Weaver is compared with microservice architecture.

Microservice architecture, in contrast, offers the ﬂex-

ibility to employ heterogeneous languages and tech-

nologies within the same system.

Furthermore, considering the pivotal role of mi-

gration in this context, it’s crucial to note that Service

Weaver currently lacks a mechanism for migrating

a microservices-based system to a Service Weaver-

based system, whether through automated or semi-

automated approaches. This limitation positions Ser-

vice Weaver as a more suitable choice for systems that

have not yet been implemented.

In summary, our examination of Service Weaver

reveals its comprehensive support for diverse cloud-

native features and components, such as modular

services, inter-module communication, conﬁguration

management, CI/CD, ﬂexible storage options, as

well as logging, tracking, and tracing functionalities.

While the framework adopts an approach of assign-

ing resiliency and security responsibilities to develop-

ers, it exhibits an effective capability to handle cloud-

native components. Nevertheless, it is worth noting

that in its early release, the framework imposes lim-

itations on the implementation of polyglot systems,

while it only supports GO programming language.

7 CONCLUSION

Service Weaver proposes a shift towards simpliﬁca-

tion and integration, aligning well with cloud-native

principles like scalability and ﬂexibility. The com-

mon theme when comparing the functionality of Ser-

vice Weaver to that of a Cloud-native microservice

system is that Service Weaver aims to make develop-

ment and deployment as simple and seamless as pos-

sible for the development teams. Service Weaver uses

many abstractions with their components and their

communications to achieve this and they also imple-

ment many desired plugins like logging, tracing, and

metric tracking out of the box.

While there are compelling reasons for a devel-

opment team to contemplate the adoption of Service

Weaver, the ease of use it offers is accompanied by a

few constraints. Currently, Service Weaver is exclu-

sively implemented in GO, thus forfeiting the advan-

tage of microservice architecture that accommodates

polyglot systems. Additionally, the extensive use of

abstractions in Service Weaver implies a trade-off in

terms of total control over the system. Furthermore,

CLOSER 2024 - 14th International Conference on Cloud Computing and Services Science

174

as a relatively new project, there are certain function-

alities that are yet to be developed, reﬂecting the on-

going maturation of the software. Notably, Service

Weaver has not presented robust solutions for sup-

porting system resiliency and security at this stage.

In the next research phase, we will implement a

prototype GO application using the Service Weaver

framework to assess development limitations in real-

world scenarios.

ACKNOWLEDGEMENTS

This material is based upon work supported by

the National Science Foundation under Grant No.

2409933.

REFERENCES

Abdelfattah., A. and Cerny., T. (2023). Filling the gaps in

microservice frontend communication: Case for new

frontend patterns. In Proceedings of the 13th Inter-

national Conference on Cloud Computing and Ser-

vices Science - CLOSER, pages 184–193. INSTICC,

SciTePress.

Abdelfattah, A., Schiewe, M., Curtis, J., Cerny, T., and

Song, E. (2023a). Towards security-aware microser-

vices: On extracting endpoint data access operations

to determine access rights. In 13th International Con-

ference on Cloud Computing and Services Science

(CLOSER 2023).

Abdelfattah, A. S. and Cerny, T. (2023a). The microser-

vice dependency matrix. In European Conference on

Service-Oriented and Cloud Computing, pages 276–

288. Springer.

Abdelfattah, A. S. and Cerny, T. (2023b). Roadmap to rea-

soning in microservice systems: A rapid review. Ap-

plied Sciences, 13(3):1838.

Abdelfattah, A. S., Cerny, T., Salazar, J. Y., Lehman, A.,

Hunter, J., Bickham, A., and Taibi, D. (2023b). End-

to-end test coverage metrics in microservice systems:

An automated approach. In European Conference on

Service-Oriented and Cloud Computing, pages 35–51.

Springer.

Amazon (2024). What is cloud native? cloud native appli-

cations explained. https://aws.amazon.com/what-is/

cloud-native/. Accessed: 2024-02-01.

AppMaster (2023). Why use a modular architecture in

software design? https://appmaster.io/blog/why-

useamodulararchitectureinsoftwaredesign. Accessed:

2024-02-01.

Atlassian (2024). 5 advantages of microservices [+ disad-

vantages]. https://www.atlassian.com/microservices/

cloud-computing/advantages-of-microservices. Ac-

cessed: 2024-02-01.

Basiri, A., Behnam, N., De Rooij, R., Hochstein, L.,

Kosewski, L., Reynolds, J., and Rosenthal, C. (2016).

Chaos engineering. IEEE Software, 33(3):35–41.

Bushong, V., Abdelfattah, A. S., Maruf, A. A., Das, D.,

Lehman, A., Jaroszewski, E., Coffey, M., Cerny, T.,

Frajtak, K., Tisnovsky, P., et al. (2021). On microser-

vice analysis and architecture evolution: A systematic

mapping study. Applied Sciences, 11(17):7856.

Carnell, J. (2021). Spring microservices in action, sec-

ond edition. In Spring Microservices in Action, Sec-

ond Edition. Manning Publications. Reference from:

Spring Microservices in Action, Second Edition.

Cerny, T., Abdelfattah, A. S., Al Maruf, A., Janes, A., and

Taibi, D. (2023). Catalog and detection techniques of

microservice anti-patterns and bad smells: A tertiary

study. Journal of Systems and Software, 206:111829.

Cerny, T., Abdelfattah, A. S., Bushong, V., Al Maruf, A.,

and Taibi, D. (2022). Microservice architecture re-

construction and visualization techniques: A review.

In 2022 IEEE International Conference on Service-

Oriented System Engineering (SOSE), pages 39–48.

IEEE.

Ghemawat, S., Grandl, R., Petrovic, S., Whittaker, M., Pa-

tel, P., Posva, I., and Vahdat, A. (2023). Towards mod-

ern development of cloud applications. In Proceed-

ings of the 19th Workshop on Hot Topics in Operating

Systems, pages 110–117.

Google (2023). Service weaver documentation. https:

//serviceweaver.dev. Accessed: 2024-02-01.

Google Open Source (2023). Introducing service weaver

framework for writing distributed applications. Ref-

erence from: Introducing Service Weaver Framework

for Writing Distributed Applications.

Lamport, L. (1994). The temporal logic of actions. ACM

Transactions on Programming Languages and Sys-

tems (TOPLAS), 16(3):872–923.

Media, O. (2017). Modules vs. microservices. https://www.

oreilly.com/radar/modules-vs-microservices/. Ac-

cessed: 2023-12-14.

NetworkNT (2021). Light hybrid 4j. https://www.

networknt.com/getting-started/light-hybrid-4j. Ac-

cessed: 2024-02-01.

Shiju Varghese (2022). Persisting data in service weaver ap-

plications. Reference from: Persisting Data in Service

Weaver Applications.

Spring (2024). Spring modulith. https://spring.io/projects/

spring-modulith. Accessed: 2024-02-01.

Su, R. and Li, X. (2024). Modular monolith: Is this

the trend in software architecture? arXiv preprint

arXiv:2401.11867.

Wiggins, A. (2017). The twelve-factor app. (Accessed on

10/02/2021).

Service Weaver: A Promising Direction for Cloud-Native Systems?

175