Pith. sign in

REVIEW 4 major objections 4 minor 36 references

Empirical Analysis of Cloud-Edge Infrastructure Complexity: Practitioner Pain Points and Architectural Directions

T0 review · 4 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that infrastructure complexity—not execution performance—is the primary barrier to cloud-edge adoption, based on 101 interviews.

desk verdict Useful new interview dataset, but the paper overclaims statistical validation: the top-two pain-point gap is within sampling error and the demographic table does not add up. read the letter →

arxiv 2608.08400 v1 pith:EDZJ2FID submitted 2026-08-09 cs.DC

Pawissanutt Lertpongrujikorn , Hai Duc Nguyen , Mohsen Amini Salehi This is my paper · ORCID
classification cs.DC
keywords cloud-edgecontinuuminfrastructurecomplexitydeveloperexperiencedeploymentonboardingdifficultyObject-as-a-ServiceplatformengineeringWebAssembly
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that the main barrier to adopting cloud, edge, and IoT infrastructure is not execution performance but infrastructure complexity, and that this barrier can be measured. Analyzing 101 semi-structured interviews across 86 organizations, it reports that deployment complexity (38.6%) and onboarding difficulty (35.6%) dominate practitioner pain, while productivity (53.5%) and automation (44.6%) are the improvements practitioners most want. If these numbers reflect the wider practitioner population, then research and product investment should shift from raw runtime optimization toward control-plane abstractions, onboarding tooling, and developer experience. The paper maps the validated pain points to four architectural directions and argues each requires security, operational integration, and multi-tenant isolation before production use.

What carries the argument

The analytical engine is thematic coding of interview transcripts into eleven pain-point categories and thirteen expectation categories, followed by frequency and co-occurrence analysis; this produces the percentages and the 'cognitive overload' correlation. The root-cause mechanism named in the paper is fragmentation of abstraction planes: developers must manually compose separate compute, state, and orchestration services. The architectural machinery then consists of four responses: Object-as-a-Service (OaaS), which unifies compute, state, and workflow into a single declaratively governed deployment object; Internal Developer Platforms, which provide self-service abstraction layers; declarative AI/ML serving pipelines; and WebAssembly-based lightweight edge runtimes with microsecond cold starts. These directions are meant to reduce deployment fragmentation and shorten onboarding cycles.

What would settle it

A preregistered random-sample survey with a defined practitioner sampling frame would settle the claim: if deployment complexity and onboarding difficulty no longer dominate the pain ranking, or if performance expectations outrank productivity and automation, then the interview frequencies are a sample artifact rather than an industry-wide ordering. A complementary check is measuring time-to-first-deployment for teams using OaaS or an Internal Developer Platform versus manual service composition.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is an empirically grounded diagnosis: fragmented abstraction planes, not slow execution, are the primary obstacle to distributed-computing adoption. Across 101 interviews, the coded pain-point frequencies put deployment complexity at 38.6% and onboarding difficulty at 35.6%, while desired-outcome frequencies put productivity at 53.5% and automation at 44.6%, both above performance at 14.9%. The paper interprets the co-occurrence of complexity and onboarding pain as cognitive overload, where engineers have the tools but cannot orchestrate them within human limits. It concludes that declaratively governed, higher-level abstractions—unified object abstractions, internal developer platforms, declarative AI/ML serving pipelines, and WebAssembly edge runtimes—are the viable architectural responses.

Load-bearing premise

The load-bearing premise is that the 101 interviews are representative enough that the coded percentages measure true population prevalence, but the sample has no reported recruitment frame or response rate and skews toward technical and academic roles, so self-selection could inflate complexity-related pain.

Editorial extensions

If this is right

  • Systems research and product roadmaps should reprioritize control-plane abstractions and developer experience over data-plane micro-optimizations.
  • Object-as-a-Service and Internal Developer Platforms become the concrete vehicles for reducing deployment complexity, so their onboarding time-to-productivity can be measured against manual composition.
  • Declarative AI/ML serving pipelines and WebAssembly edge runtimes address the same pain points in GPU-bound and resource-constrained settings, with Wasm specifically removing cold-start unpredictability.
  • Security, strict multi-tenant isolation, and observability integration are prerequisites, not optional features, for any of the four directions to reach production.
  • Adoption will split: SMEs and startups will take unified abstractions directly, while enterprises will route novel abstractions through internal platforms with governance controls.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the sample skews toward technical roles and academia and no recruitment frame is reported, a randomized, preregistered survey of the same practitioner population would test whether the 38.6% and 35.6% frequencies reflect true prevalence; if they drop below other pain categories, the centrality claim weakens.
  • If the ordering holds, control-plane APIs and onboarding tooling become the main competitive battleground for cloud-edge platforms, so cloud providers may start competing on developer ergonomics rather than raw latency.
  • OaaS-style declarative NFRs could be extended into a cross-paradigm governance standard covering FaaS, edge, and ML serving, but that would require shared interfaces for cost, latency, and reliability constraints.
  • A direct testable extension is a time-to-first-deployment study comparing teams using OaaS or an Internal Developer Platform against teams manually composing services; the paper's causal story predicts a large reduction in onboarding time.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper reports a semi-structured interview study of 101 practitioners across 86 organizations, following NSF I-Corps customer-discovery methodology, and claims to quantitatively validate that deployment complexity (38.6%) and onboarding difficulty (35.6%) are the dominant operational bottlenecks in cloud-edge infrastructure, while productivity (53.5%) and automation (44.6%) are the most desired improvements. Based on these findings, the authors propose four architectural directions: Object-as-a-Service, Internal Developer Platforms, declarative AI/ML serving pipelines, and WebAssembly-based edge runtimes, and discuss adoption prerequisites such as security, observability integration, and multi-tenant isolation. The paper positions itself as empirical grounding for shifting research and product investment from raw performance optimization toward control-plane abstractions and developer experience.

Significance. If the empirical claims held as stated, the paper would provide useful evidence for rebalancing distributed-systems research priorities toward developer experience, onboarding, and declarative abstractions. The authors deserve credit for conducting a substantial interview corpus (101 interviews), for applying thematic coding to both pain points and expectations, and for mapping their findings to concrete architectural directions with relevant related work. The qualitative narrative is plausible and aligns with industry reports, but the paper's central quantitative claim is not supported by the statistics actually reported: there are no confidence intervals, significance tests, inter-rater reliability statistics, or correlation coefficients, and the demographic table is internally inconsistent. The contribution is therefore better described as an exploratory qualitative study with descriptive mention frequencies than as a quantitatively validated ranking of industry-wide bottlenecks.

major comments (4)
  1. [Table I / Section II-C] The role categories in Table I sum to 103 (29+24+19+17+6+3+3+2), not the stated N=101, so the denominator for every reported percentage is uncertain. Please correct the table or explicitly state how the 101 interviews map to the 103 role counts, and clarify whether some interviews were double-coded across role categories.
  2. [Section III-A and Abstract] The central claim that deployment complexity (38.6%) and onboarding difficulty (35.6%) are the dominant bottlenecks is presented without confidence intervals or significance tests. At N=101, the 3.0-point gap between these two top categories is far smaller than the standard error of the difference (~6.8 points for independent proportions), so the data do not establish that deployment complexity is more prevalent than onboarding. The paper should report exact binomial or multinomial confidence intervals, a pairwise test for the top categories (with multiple-comparison correction), and a statement about the precision of the ranking; otherwise the wording 'quantitatively validate' and 'primary barrier' must be weakened.
  3. [Section II-C / Section III-A] The sampling frame is described only as NSF I-Corps customer discovery, with no recruitment frame, response rate, selection criteria, or saturation rationale, and the visible role mix is skewed toward research and academia (17 of 101). Frequencies from a convenience sample measure mention rates in a self-selected group, not population prevalence. The paper should either provide the missing sampling details and justify representativeness, or explicitly reframe the findings as exploratory and sample-specific rather than industry-wide validated statistics.
  4. [Section III-A, paragraph on co-occurrence] The text states that 'Our correlation analysis revealed that complexity and onboarding challenges frequently appeared together,' but no correlation coefficient, test statistic, or method is reported. Since the subsequent 'cognitive overload' claim is built on this analysis, please either report the relevant coefficients with p-values and a description of how co-occurrence was coded, or remove the unsupported assertion.
minor comments (4)
  1. [Reference [9]] The arXiv identifier '220.0194' in reference [9] appears incomplete or malformed; please provide the full arXiv ID and verify the URL.
  2. [Figures 1-3] The bar charts in Figures 1-3 show percentages without error bars or sample size annotations; adding confidence intervals or at least noting the sample size per bar would improve interpretability.
  3. [Section IV-A] The OaaS architectural direction is presented with substantial reliance on the authors' own prior work ([15]-[18]); this is acceptable for a mapping of the authors' design space, but the text should explicitly flag that OaaS is the authors' proposal rather than an implication of the interview data.
  4. [General] The paper uses phrases such as 'quantitatively confirm' and 'data-supported' in Section III, which overstate what descriptive frequencies from a non-probability sample can establish; softening these phrases to 'indicate' or 'suggest' would align the language with the actual analysis.

Circularity Check

1 steps flagged · score 2.0 of 10

Empirical pain-point frequencies are independent counts, not derived from the OaaS proposals; the only circularity concern is that the OaaS architectural recommendation leans on the authors' own prior papers.

  1. self citation load bearing [Section IV-A, Unified Object Abstractions (OaaS), references [15]-[18]]
    "OaaS was initially formulated to abstract data-intensive cloud-native workloads [15]. Subsequent work enriched the model with workflow orchestration and execution guarantees for dispersed environments [16], including Oparaca-style encapsulation of orchestrator logic [16], and introduced formal NFR enforcement mechanisms [17]. Most recently, the EdgeWeaver framework extended OaaS to the edge-cloud continuum for IoT scenarios [18]."

    The paper's fourth architectural direction (OaaS) is the authors' own prior research program. The text supports OaaS's core properties—unified compute/state/orchestration, NFR enforcement, and edge extension—exclusively by citing the authors' earlier papers [15]-[18]. The current paper contributes no new measurement or independent evaluation of OaaS; the claim that OaaS 'directly targets' the empirically identified root cause therefore rests on a self-citation chain rather than on evidence produced in this manuscript. This is a real but narrow circularity concern: it affects the architectural recommendation, not the interview-frequency findings, which are independently tabulated from coded responses.

full rationale

The central empirical claim—that deployment complexity (38.6%) and onboarding difficulty (35.6%) are dominant pain points, with productivity and automation as top expectations—comes from direct coding of 101 interviews. These percentages are derived from the interview data itself, not from the OaaS architecture or any prior paper by the authors, so the empirical core is not circular. The architectural mapping in Section IV is a proposal, not a prediction; OaaS is one of four directions and its feasibility is supported by the authors' prior publications. That self-citation cluster is somewhat load-bearing for the OaaS recommendation, but it does not feed back into the interview-derived numbers, so it does not force the central result. The sample-representativeness concerns, the internal role-count inconsistency (Table I sums to 103, not 101), and the absence of confidence intervals are correctness and validity risks, not circularity, and they do not raise the circularity score.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The analysis has no mathematical parameters or fitted constants. The load-bearing assumptions are qualitative: self-reported pain points are trustworthy, the convenience-derived sample represents the population, and the coding scheme is valid. None of these assumptions is independently verified in the paper, and the paper provides no external benchmark against which the percentages can be checked.

assumptions (3)
  • domain assumption Interviewee self-reports accurately reflect actual practitioner pain points and priorities.
    The study treats each mention of a pain category as evidence of a bottleneck without independent verification or behavioral data. This assumption enters in Section III-A where frequencies are converted into claims about dominance.
  • domain assumption The sample of 101 interviews across 86 organizations is representative of the broader cloud-edge practitioner population.
    Section II-C reports demographics but no recruitment frame, response rate, or selection criteria. The heavy research and academia presence (17 of 101) suggests possible selection bias.
  • domain assumption The thematic coding categories are valid, mutually exclusive, and consistently applied.
    Section II-B lists eleven pain themes and thirteen expectation dimensions but provides no codebook, inter-rater reliability check, or saturation analysis.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Empirical Analysis of Cloud-Edge Infrastructure Complexity: Practitioner Pain Points and Architectural Directions." pith.science (2026). https://pith.science/paper/EDZJ2FID

@misc{pith2026260808400,
  author       = {Pith},
  title        = {Pith review of: Empirical Analysis of Cloud-Edge Infrastructure Complexity: Practitioner Pain Points and Architectural Directions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EDZJ2FID}},
  note         = {Machine review of arXiv:2608.08400}
}
read the original abstract

The proliferation of cloud, edge, and Internet of Things (IoT) computing has created unprecedented opportunities for distributed applications. However, this architectural shift introduces profound infrastructural complexity, acting as a significant barrier to developer productivity and innovation. In this paper, we present an empirical analysis based on 101 semi-structured interviews across 86 organizations to investigate the state of cloud-native development practices, pain points, and expectations. Our findings quantitatively validate that deployment complexity (38.6%) and onboarding difficulty (35.6%) are the dominant operational bottlenecks, while developers heavily prioritize productivity (53.5%) and automation (44.6%) over raw performance optimization. Based on these empirical insights, we examine four architectural directions that address the validated pain points: unified object abstractions (Object-as-a-Service), platform engineering via Internal Developer Platforms, declarative AI/ML serving pipelines, and lightweight edge runtimes based on WebAssembly. Furthermore, we detail the multi-stakeholder ecosystem required for adopting novel infrastructure paradigms, emphasizing that security, operational integration, and strict multi-tenant isolation are prerequisites for production readiness. Our results demonstrate that the primary barrier to distributed computing adoption is not execution performance but infrastructural complexity, and that declaratively governed, higher-level abstractions across multiple paradigms offer viable architectural paths toward alleviating it.

Figures

Figures reproduced from arXiv: 2608.08400 by the authors.

Figure 2
Figure 2. Frequency of pain points mentioned across 101 interviews. Deploy [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 1
Figure 1. Distribution of interview participants by role group (N=101 inter [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Frequency of expectations for improvement mentioned across 101 [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Comparison of FaaS and OaaS paradigms. In FaaS (top), developers [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

36 extracted references · 30 canonical work pages

  1. [1]

    Edge computing: Vision and challenges,

    W. Shi, J. Cao, Q. Zhang, Y . Li, and L. Xu, “Edge computing: Vision and challenges,” inIEEE Internet of Things Journal, vol. 3, no. 5, 2016, pp. 637–646

    work page 2016

  2. [2]

    A survey on iot-edge-cloud continuum systems: Status, challenges, use cases, and open issues,

    P. Gkonis, A. Giannopoulos, P. Trakadas, X. Masip-Bruin, and F. D’Andria, “A survey on iot-edge-cloud continuum systems: Status, challenges, use cases, and open issues,”Future Internet, vol. 15, no. 12, p. 383, 2023

    work page 2023

  3. [3]

    A survey on microservices architecture: Principles, patterns and migration challenges,

    V . Velepucha and P. Flores, “A survey on microservices architecture: Principles, patterns and migration challenges,”IEEE access, vol. 11, pp. 88 339–88 358, 2023

    work page 2023

  4. [4]

    Serverless computing: One step forward, two steps back,

    J. M. Hellerstein, J. Faleiro, J. E. Gonzalez, J. Schleier-Smith, V . Sreekanti, A. Tumanov, and C. Wu, “Serverless computing: One step forward, two steps back,”arXiv preprint arXiv:1812.03651, 2018

    arXiv 2018

  5. [5]

    2024 state of developer experience report,

    Harness, “2024 state of developer experience report,” https://www. harness.io/state-of-developer-experience, 2024, online; Accessed on 13 Mar. 2026

    work page 2024

  6. [6]

    Machine learning operations (MLOps): Overview, definition, and architecture,

    D. Kreuzberger, N. K ¨uhl, and S. Hirschl, “Machine learning operations (MLOps): Overview, definition, and architecture,”IEEE Access, vol. 11, pp. 31 866–31 879, 2023

    2023

  7. [7]

    Challenges in deploying machine learning: A survey of case studies,

    A. Paleyes, R.-G. Urma, and N. D. Lawrence, “Challenges in deploying machine learning: A survey of case studies,”ACM Computing Surveys, vol. 55, no. 6, pp. 1–29, 2022

    work page 2022

  8. [8]

    Cold start latency in serverless computing: A systematic review, taxonomy, and future directions,

    M. Golec, G. K. Walia, M. Kumar, F. Cuadrado, S. S. Gill, and S. Uhlig, “Cold start latency in serverless computing: A systematic review, taxonomy, and future directions,”ACM Computing Surveys, vol. 57, no. 3, pp. 1–36, 2024

    2024

Show all 36 references
  1. [9]

    SMSE: A Serverless Platform for Multimedia Cloud Systems,

    C. Denninnart and M. Amini Salehi, “SMSE: A Serverless Platform for Multimedia Cloud Systems,”arXiv preprint:220.0194, 2022

    2022

  2. [10]

    Blank,The Four Steps to the Epiphany: Successful Strategies for Products that Win

    S. Blank,The Four Steps to the Epiphany: Successful Strategies for Products that Win. John Wiley & Sons, 2020

    2020

  3. [11]

    Zero trust archi- tecture,

    S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust archi- tecture,”NIST special publication, vol. 800, no. 207, pp. 1–52, 2020

    2020

  4. [12]

    Efficiency in the serverless cloud paradigm: A survey on the reusing and approximation aspects,

    C. Denninnart, T. Chanikaphon, and M. Amini Salehi, “Efficiency in the serverless cloud paradigm: A survey on the reusing and approximation aspects,”Software: Practice and Experience, vol. 53, no. 10, pp. 1853– 1886, 2023

    2023

  5. [13]

    Harnessing the potential of function- reuse in multimedia cloud systems,

    C. Denninnart and M. A. Salehi, “Harnessing the potential of function- reuse in multimedia cloud systems,”IEEE Transactions on Parallel and Distributed Systems, vol. 33, no. 3, pp. 617–629, 2021

    2021

  6. [14]

    Continuous integration, delivery and deployment: A systematic review of approaches, tools, challenges and practices,

    M. L. Gupta, R. Puppala, V . V . Vadapalli, H. Gundu, and C. Karthikeyan, “Continuous integration, delivery and deployment: A systematic review of approaches, tools, challenges and practices,” inInternational Confer- ence on Recent Trends in AI Enabled Technologies. Springer, ...

    2024

  7. [15]

    Object as a service (OaaS): Enabling object abstraction in serverless clouds,

    P. Lertpongrujikorn and M. A. Salehi, “Object as a service (OaaS): Enabling object abstraction in serverless clouds,” in2023 IEEE 16th International Conference on Cloud Computing (CLOUD). IEEE, 2023, pp. 315–324

    2023

  8. [16]

    Object as a service: Simplifying cloud-native development through serverless object abstraction,

    ——, “Object as a service: Simplifying cloud-native development through serverless object abstraction,”IEEE Transactions on Computers, vol. 75, no. 2, pp. 423–434, 2026

    2026

  9. [17]

    Streamlining cloud-native application development and deployment with robust en- capsulation,

    P. Lertpongrujikorn, H. D. Nguyen, and M. A. Salehi, “Streamlining cloud-native application development and deployment with robust en- capsulation,” inProceedings of the ACM Symposium on Cloud Comput- ing, ser. SoCC ’24, 2024, pp. 535–541

    2024

  10. [18]

    Edgeweaver: Accelerating iot application development across edge- cloud continuum,

    P. Lertpongrujikorn, J. Kwon, H. D. Nguyen, and M. Amini Salehi, “Edgeweaver: Accelerating iot application development across edge- cloud continuum,” inProceedings of the 40th IEEE International Parallel and Distributed Processing Symposium, ser. IPDPS ’26, 2026

    2026

  11. [19]

    2023 state of platform engineering report,

    Puppet, “2023 state of platform engineering report,” https://www.puppet. com/resources/state-of-devops-report, 2023, online; Accessed on 13 Mar. 2026

    2023

  12. [20]

    DevEx: What actually drives productivity,

    M. Greiler, M.-A. Storey, and A. Noda, “DevEx: What actually drives productivity,”ACM Queue, vol. 21, no. 2, pp. 35–53, 2023

    2023

  13. [21]

    Platform engineering: Empowering de- velopers with internal developer platforms (idps),

    G. P. Rusum and K. K. Pappula, “Platform engineering: Empowering de- velopers with internal developer platforms (idps),”International Journal of AI, BigData, Computational and Management Studies, vol. 5, no. 1, pp. 89–101, 2024

    2024

  14. [22]

    Backstage: An open platform for building developer portals,

    Spotify, “Backstage: An open platform for building developer portals,” https://backstage.io, 2024, online; Accessed on 13 Mar. 2026

    2024

  15. [23]

    Cloud native 2024: Approaching a decade of code, cloud, and change,

    Cloud Native Computing Foundation, “Cloud native 2024: Approaching a decade of code, cloud, and change,” https://www.cncf.io/reports/ cncf-annual-survey-2024/, 2024, online; Accessed on 13 Mar. 2026

    2024

  16. [24]

    Spotserve: Serving generative large language models on preemptible instances,

    X. Miao, C. Shi, J. Duan, X. Xi, D. Lin, B. Cui, and Z. Jia, “Spotserve: Serving generative large language models on preemptible instances,” in Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume...

    2024

  17. [25]

    BentoML: Build, ship, and scale AI applications,

    BentoML, “BentoML: Build, ship, and scale AI applications,” https: //www.bentoml.com, online; Accessed on 13 Mar. 2026

    2026

  18. [26]

    KServe: Highly scalable and standards-based model inference platform on Kubernetes,

    KServe Authors, “KServe: Highly scalable and standards-based model inference platform on Kubernetes,” https://kserve.github.io/website/, on- line; Accessed on 13 Mar. 2026

    2026

  19. [27]

    Webassembly as a common layer for the cloud-edge continuum,

    J. M ´en´etrey, M. Pasin, P. Felber, and V . Schiavoni, “Webassembly as a common layer for the cloud-edge continuum,” inProceedings of the 2nd Workshop on Flexible Resource and Application Management on the Edge, 2022, pp. 3–8

    2022

  20. [28]

    WebAssembly and unikernels: A comparative study for serverless at the edge,

    A. Hall and U. Ramachandran, “WebAssembly and unikernels: A comparative study for serverless at the edge,” inProceedings of the 9th ACM/IEEE Symposium on Edge Computing (SEC). IEEE, 2024, pp. 1–13

    2024

  21. [29]

    The pains and gains of microservices: A systematic grey literature review,

    J. Soldani, D. A. Tamburri, and W.-J. Van Den Heuvel, “The pains and gains of microservices: A systematic grey literature review,”Journal of Systems and Software, vol. 146, pp. 215–232, 2018

    2018

  22. [30]

    Characterizing microservice dependency and performance: Alibaba trace analysis,

    S. Luo, H. Xu, C. Lu, K. Ye, G. Xu, L. Zhang, Y . Ding, J. He, and C. Xu, “Characterizing microservice dependency and performance: Alibaba trace analysis,” inProceedings of the ACM symposium on cloud computing, 2021, pp. 412–426

    2021

  23. [31]

    The state of serverless appli- cations: Collection, characterization, and community consensus,

    S. Eismann, J. Scheuner, E. Van Eyk, M. Schwinger, J. Grohmann, N. Herbst, C. L. Abad, and A. Iosup, “The state of serverless appli- cations: Collection, characterization, and community consensus,”IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 4152–4166, 2021

    2021

  24. [32]

    Cloud programming simplified: A berkeley view on serverless computing,

    E. Jonas, J. Schleier-Smith, V . Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V . Shankar, J. Carreira, K. Krauth, N. Yadwadkaret al., “Cloud programming simplified: A berkeley view on serverless computing,” arXiv preprint arXiv:1902.03383, 2019

    1902 arXiv

  25. [33]

    Orleans: cloud computing for everyone,

    S. Bykov, A. Geller, G. Kliot, J. R. Larus, R. Pandya, and J. Thelin, “Orleans: cloud computing for everyone,” inProceedings of the 2nd ACM Symposium on Cloud Computing, 2011, pp. 1–14

    2011

  26. [34]

    Dapr: The distributed application runtime,

    “Dapr: The distributed application runtime,” https://dapr.io, 2025, online; Accessed on 3 Mar. 2026

    2025

  27. [35]

    Extend cloud to edge with kubeedge,

    Y . Xiong, Y . Sun, L. Xing, and Y . Huang, “Extend cloud to edge with kubeedge,” in2018 IEEE/ACM Symposium On Edge Computing (SEC). IEEE, 2018, pp. 373–377

    2018

  28. [36]

    Osmotic computing: A new paradigm for edge/cloud integration,

    M. Villari, M. Fazio, S. Dustdar, O. Rana, and R. Ranjan, “Osmotic computing: A new paradigm for edge/cloud integration,” inIEEE Cloud Computing, vol. 3, no. 6, 2016, pp. 76–83

    2016

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.