Service Semantics and Flow Architectures
In his blog “Five Facets of Flow Strategy”, James Urquhart identifies potential hurdles to overcome for the latest Computing Paradigm: Asynchronous, event-driven “serverless” computing. Briefly, they are scale (in terms of number/types of events & services), agility, quality, optimization and security. His broader statement is on Flow Architectures that he believes will become mainstream in the coming decade as distribute systems get deployed across the Cloud-Edge Continuum.
Some of those hurdles, I believe, can be addressed by better representations and understanding of compute artifacts and their interactions in Flow Architectures. Through this publication, I want to introduce Service Semantics, broadly as a topic covering mechanisms for capturing, representing and discovery of Events and other compute artifacts, enabling frameworks and tools to facilitate better understanding and operations of distributed/federated systems.
Serverless Computing and Models
Several models and architectures have been proposed and adopted for Serverless Computing or by cloud service providers (AWS, Azure, GCP, etc.) and platforms (OpenWhisk, Serverless.com, Fission, Fn, Kubeless, etc. (Ref. here for comprehensive list). They are centered around the notion of human- or machine-generated Events, trigger Functions or Services to perform some computing that eventually can generate zero or more Events to handled downstream.
AWS introduce Serverless Application Model (SAM) which models the artifacts centered around AWS Lambda. While it is open source, it is targeted to deploying into AWS ecosystem (Please comment below if you know of any support for, say, Azure using SAM). Different “serverless” providers and platforms offer different formats, structure and API specs (Syntax) for Events, Functions, etc. While that Syntax provides sufficient understanding for a developer to build Functions/Services, they sorely lack on broader meaning or relevance of the Event in a distributed system. For example, (1) What kind of Events does an entity generate, and, (2) which services are tapping into that Event and performing actions? Such information / view is essential for managing distributed systems. These need to be published in a format and platform so that they are discoverable and acted upon. Similar discoverability and addressability requirements are also essential for the Functions and Services in a serverless setup. To emphasize, the unstated or missed information is the details of the “network” that links these events and services not the individual functions or event formats.
While CloudEvents (CNCF project) targets the representation of Events, the emphasis is on transport formats (at least for now) across providers and platforms with potential future possibilities for capturing and modeling semantics. At a high-level, there is a need to express the intent/understanding or semantics of these Events and other compute artifacts, and how they weave through Services and interact with other Events or Services in a distributed system.
What is Service Semantics?
Semantics is the study of meanings. Here we are interested broadly on Services and their meaning in the sense of what they offer and what they do for target audience. As with linguistics and logic where semantics helps in understanding and automation, I expect, models and representation of Service Semantics will facilitate better understanding of the services by both humans and machines, and eventually lead to better automation. Service Semantics not only covers individual services — where the interface or API documentation (Syntax) provide some insights on the service offering, but also combination of services to form distributed systems. This is acutely needed for the Event-driven “Serverless” Computing paradigm
Service Semantics broadly refers to the capture, representation, modeling and use of computing services and their associated artifacts (Events, Functions, etc.)
Before we delve into what is a good framework, model or protocol for capturing services semantics that enables addressability and discovery (will be addressing in subsequent blogs here), let’s assume we have formal models for describing the events, functions across providers and platforms with specific semantics to understand what the events are and what the functions/services do. This can address some of the hurdles for Flow Architectures by James Urquhart.
Scale
The scale James’ refers to as an hurdle is “the growing number of services, functions, applications, queues and other infrastructure that are interconnected in flow architectures.” Even within a distributed system, there will be multiple flows that come together, separate out and connect in different ways to run the complex engine. James compares this to Internet with HTTP linking a web of interconnect content that spans the globe. Events and other compute artifacts will go across organization boundaries, they are likely to be dynamically discovered and connected. Similar to the way anyone can point their ElasticSearch setup to one or more sources and pull, index and use content, published and discoverable events and services can be integrated (with appropriate credentials and access) to combine and build systems. This can include solutions not necessarily envisaged by the creators of individual events, functions or other compute artifacts.
A common framework that not only exposes the syntax (format) but also the semantics (what is offered and how to interpret and use) enables these diverse distributed compute artifacts to be described, accessed and used. With this description of the components, and hence, the distributed system, one can build tools for efficient operations of the system. in addition, this common language would provide the mechanism to track and optimize over usage, time and other metrics/dimensions. Note that such a solution should be agnostic to providers and platforms. Else, we are likely to complain about lock in for perpetuity.
Agility
James highlights “systemic agility — i.e how these technologies enable the market to adapt software to economic opportunities and realities much faster (especially when combined with compute service utilities [aka cloud] and highly iterative software lifecycles [such as Agile and DevOps practices])” Based on the economic or performance options available, one should be able to quickly modify or reconfigure the solution to effectively use such opportunity. This needs a clear understanding of the components of the machinery that makes things happen — something Service Semantics can expose.
In a typical IoT use case, certain data is collected at the sensors, collated at a edge node or gateway with some processing of the data, published to the cloud for further analytics and insights that trigger actions back at the edge node or the IoT device. Data in some form moves from the IoT (Edge) device to the cloud and back. Computing on this data is selectively done at each of these points. Currently, the compute is cloud heavy and slowly frameworks are moving towards the edge. A good description of the distributed system that is understandable by human and machines will enable opportunistic placement and execution of computing at any appropriate node in the Cloud-Edge Continuum. This agility can be achieved with clear definition and understanding of events, functions, services as well as the capabilities of the providers and platforms available.
With clear expression of Service Semantics, Similar points can be identified for other hurdles identified by James. Computing paradigms have gone through cycles from centralized system to moving to edge (micro computers), back to central hosting & cloud and currently with the ability to run anywhere in the Cloud-Edge Continuum. Each of these paradigms or frameworks have enabled us to not only build new technologies and provide automation and tools to solve more complex problems. At each iteration we have been able to identify the computing state, meter and monitor them to facilitate performance and efficiency. If the Events, Functions, Services and other compute artifacts are the words in this evolving and future Computing Language, their connections and selections provide the meaning for Distributed Systems — that can be understood by human and machines via Service Semantics.
Let me know your thoughts and comments as we learn together to understand the computing world around us. Please comment below or on twitter (@msrik)
