- Digital twins are virtual models that mirror physical entities, enhancing their capabilities by providing a behavior modeling, prediction, and optimization platform. They have been successfully implemented in various fields, such as IoT, smart factories, healthcare, and urban development.
- The concept of digital twins is not limited to physical objects. It’s already prevalent in software domains, where digital representations exist for software entities at various levels of granularity, from broad systems like virtual machines to granular entity objects.
- The Service Twin Pattern is an innovative concept that applies the principles of digital twins to microservices. It creates a 1:1 mapping between a microservice and its cloud-based twin, enhancing the service’s behavior with additional functionalities.
- The Service Twin Pattern can revolutionize cloud services by making them more application-oriented and developer-friendly. By making the service a first-class entity in the cloud runtime, it aligns operational concerns to the service boundary, simplifying the use of cloud services.
- The Service Twin Pattern has the potential to redefine how developers interact with cloud services. As it continues to evolve, it could pave the way for a new era of cloud services consumption, where services are the primary unit of functionality.
A digital twin (DT) is a virtual representation of a physical object, process, or system that mirrors its real-world counterpart in real-time, allowing for simulations, analysis, and optimization to improve performance and gain valuable insights.
What if the key to making the cloud application-oriented and developer-friendly was already here, hidden in the concept of digital twins? The digital twin concept is revolutionizing various fields, from the Internet of Things (IoT) and smart factories to healthcare, urban development, and the automotive industry. The power of enhancing a physical entity with a digital replica for functions such as behavior modeling, prediction, and optimization has opened new avenues of exploration and innovation.
This article explores using the DT concept as a new way to make cloud services more developer-friendly. This new model aligns the development, deployment, and now runtime aspects of a microservice into a single, cohesive unit, bridging the gap between developers and the cloud and paving the way for a new era of cloud services.
The transformative power of digital twins in the physical world
A DT, in essence, is a high-fidelity virtual model designed to mirror an aspect of a physical entity accurately. Let’s imagine a piece of complex machinery in a factory. This machine is equipped with numerous sensors, each collecting data related to critical areas of functionality from temperature to mechanical stress, speed, and more. This vast array of data is then transmitted to the machine’s digital counterpart. With this rich set of data, the DT becomes more than just a static replica. It evolves into a dynamic model that can simulate the machinery’s operation under various conditions, study performance issues, and even suggest potential improvements.
The ultimate goal of these simulations and studies is to generate valuable insights that can be applied to the original physical entity, enhancing its performance and longevity. The resulting architecture is a dual Cyber-Physical System with a constant flow of data that brings unique insights into the physical realm from the digital realm.
[Click on the image to view full-size]
A digital representation of a physical object
DTs have made significant headway in various industries. They are implemented in domains such as manufacturing, aerospace, healthcare, urban planning, and intelligent cars, to name a few. In manufacturing, DTs help model behavior, predict outcomes, and optimize processes. In healthcare, DTs of human organs can assist doctors in understanding a patient’s unique physiology, enabling personalized treatment plans. In urban planning, DTs of entire cities allow planners to simulate and analyze the impact of different development strategies. But does the realm of DTs extend only to physical objects? Interestingly, the concept of DTs is also prevalent in the realm of digital objects under different names. The following sections will delve into these questions.
Extending digital twins to the digital realm
The notion of a digital representation for a software entity is already prevalent in various software frameworks. Here, we can draw parallels between DTs and concepts varying in granularity from a broader system like a virtual machine to something as granular as a specific entity object. Let’s delve into examples that range across this spectrum.
Consider a virtual server equipped with a monitoring agent that establishes a 1:1 connection between the server and its remote representation. This agent not only streams metrics from the server to a central repository for analysis but also enables the execution of commands and facilitates server debugging when needed. The presence of this agent provides operations teams with valuable insights into the health and load of their servers. Armed with this information, they can effectively plan server maintenance activities, such as patching, upgrades, and scaling operations based on load. Essentially, this allows the operations team to model entire data centers composed of servers and continuously track their load, health, and retirement. This use case is primarily about the operation and maintenance of host machines.
Drilling down a level from the server to a specific process, we encounter another manifestation of the DT concept. Let’s visualize a large-scale distributed application running on Java. Monitoring services like Datadog, Dynatrace, and others operate by installing an agent into the Java virtual machine (JVM) and gathering detailed insights about its workings. These insights are then sent to a central server on the cloud, enabling each application’s performance to be modeled, understood, and optimized.
Yet other examples echo the essence of DT at the process level. A Service Mesh such as Istio employs the sidecar architecture, for example, to monitor and control a distributed system’s networking aspects. The Service Mesh architecture can model the interactions of all services in a way similar to how a smart city models the movement of cars on its streets.
Moving further down within a process, we encounter examples of DTs that help model and manage different aspects of applications. The Virtual Actor pattern, for instance, allows the use of an actor ID to represent the actor object while managing its activation, deactivation, placement, lifecycle, and more. The line gets blurry here, but other examples include an Object-Relational Mapping system such as Hibernate that allows objects to represent data in a state store or an entity workflow pattern that allows tracking and controlling the state transitions of an entity through a remote representation in the workflow engine.
[Click on the image to view full-size]
Digital twin concept applied to digital objects
All these examples show a common pattern – a 1:1 mapping with a piece of software, represented remotely by another software, focusing on one particular aspect of the software, such as lifecycle, health, state, networking, etc. A generalized version of this pattern applied to Microservices would be a new architectural concept – the Service Twin Pattern. Let’s look into that next.
Introducing a new architectural concept: the Service Twin Pattern
New requirements and software abstractions continually inspire the development of new innovative patterns and paradigms. So is the case with the Service Twin Pattern. But why coin a new term instead of leveraging the established, such as DT or Sidecar patterns? Patterns help to quickly communicate an idea and highlight certain aspects of a solution. The DT pattern emphasizes creating a digital counterpart for a non-digital entity, forming a Cyber-Physical System. Here, the presence of a non-digital object is key, hence the pattern’s name. And typically, the twin doesn’t play a direct role in the functioning of the physical counterpart but enriches its lifecycle, offering indirect optimization benefits. The Sidecar pattern, on the other hand, popularized by Kubernetes’ Pods concept and projects such as Dapr, extends an application’s capabilities at deployment time. These added capabilities are co-located with the main application, sharing the same deployment target and lifecycle.
While inspired by these two patterns, the Services Twin Pattern is at a service granularity. It doesn’t have a physical counterpart – nor is it limited to the sidecar architecture, hence the need for a new name that communicates its essence. Microservice has emerged as today’s universal unit of a digital object. The boundaries of a microservice delineate team ownership, lifecycle, scaling policies, deployment location, and many other attributes. As such, a microservice represents the ideal cohesive unit of digital functionality that can be remotely represented with a twin as a unit of operational control structure and consuming remote development capabilities. Herein lies the core of the Service Twin Pattern. This pattern creates a remote twin of a service, typically on cloud infrastructure, that uniquely represents the real service. By forming a 1:1 mapping between a service and its twin, this pattern can enhance the service’s behavior with additional functionalities without imposing any limits on the nature of these enhancements.
Fundamental to this unique mapping between the service and its remote twin representation is establishing a secure communication channel for data exchange. Similarly to the DT pattern with physical objects, the complexity of this data exchange can vary depending on the use case. In simpler instances like monitoring, the data flow could be unidirectional, emitting only metrics and logs from the service to its twin. The next level of complexity would be when the service twin controls and manages certain aspects of the service, as is the case with a Service Mesh controlling the networking policies. Some service twins can go beyond acting as a control structure and manage the configuration and secrets of a service. For example, HashiCorp Cloud Platform Vault has the concept of an application with associated secrets that get passed and any updates pushed to the real application at runtime.
In other cases, the data flow could be bidirectional; such is the case with Ably, who are providing real-time messaging capabilities. In Ably, there is no concept of message brokers but applications with queues, tokens, metrics, notifications, etc. In more advanced remote twins such as Diagrid Cloud Runtime APIs, the data flow can follow various patterns. The twin can provide many complementary capabilities such as offloading state management, workflows, connectors, etc., creating a dynamic dual-cyber system. Today, the application concept is present primarily in compute-centric cloud services such as AWS AppRunner, Google CloudRun, Azure Container Apps, Railway, Convex, and Vercel, to name a few. But having a top-level application concept would allow developers to bind their applications to their twin at runtime and combine them with additional capabilities as described in the cloud-bound architecture post.
[Click on the image to view full-size]
Service Twin Pattern on a cloud infrastructure
Consider this scenario: you have a service, and you create a corresponding service twin in a cloud environment. With the unique mapping and a secure communication channel established between the service and its twin (via an agent, sidecar, SDK, simple URL mappings, CLI-based configuration, etc.), the two can communicate effectively. Through its twin, the service can be configured to retrieve only its secrets defined in the cloud environment. The twin can assist in performing service discovery, configuration propagation, and connecting to 3rd party endpoints.
Furthermore, the service could offload state management to a key-value store in the cloud that is scoped to its twin only. It could even maintain state in an externally managed, persistent workflow engine dedicated to the service’s state transitioning logic. Security boundaries aligned with Zero Trust principles can be configured through its twin. Because the service twin is the first-class citizen in the cloud runtime environment and not the infrastructure components, all other cloud primitives and infrastructure can be scoped to it and operated as additional service capabilities. This is very powerful, and it provides only a glimpse into the potential of the Service Twin Pattern in how it could address some of the complexities of consuming cloud services.
Flipping the cloud consumption with service twins
There are direct benefits to developers for using the Service Twin Pattern. The twin enables the runtime reuse of commoditized capabilities, such as state access, pub/sub interactions, 3rd party connectors, configuration and secret access, resiliency policies, and others, as the Mecha architecture portrays. Additionally, these capabilities can be consumed as cloud capabilities scoped to a single service, and the management of the twin service can be offloaded to other teams to reduce the operational burden.
The Service Twin Pattern also has indirect second-level effects that can benefit operations teams and change how we use cloud services. In the development phase, Microservices have been embraced as the universal digital functionality unit isolated in distinct source code repositories. They are built, and outputs are stored as isolated containerized artifacts too. In the deployment phase, Microservices have also been embraced as the universal scale unit by the cloud services such as AWS SAM Stack, AWS AppRunner, and Google Cloud Run. Despite this, at runtime, when it comes to consuming other runtime primitives such as networking, storage, workflows, configurations, security, observability, etc., we currently lack a corresponding service-level representation in the cloud environments.
The Service Twin Pattern offers an approach for addressing this granularity mismatch between a service and its cloud primitives, aligning the operational concerns to the service boundary. By creating a cloud-based twin of the actual service, the service becomes a first-class entity in the cloud runtime that can serve as an independent operational management layer and a way to enhance the service with other cloud primitives. It shifts the cloud primitives to the left and forces Dev and Ops teams to think and act in a service-first manner. The service twin aligned with the developer’s view of the world also becomes the runtime management and security boundary for the operations teams.
[Click on the image to view full-size]
Flipping the cloud from infrastructure-first to service-first abstractions
This new model flips the cloud consumption from one where the infrastructure-first primitives were the primary unit of functionality into one where the application service is the primary unit, and other cloud services are complementary capabilities. It aligns a service’s development, deployment, and now runtime aspects into a single, cohesive unit, making it a powerful abstraction that reduces the cognitive load when dealing with cloud services.
The Service Twin Pattern is a pioneering concept that bridges the digital twin concept with microservices and the cloud. It presents a unique approach to cloud services usage, transforming how developers interact with cloud services by providing a more application-oriented and developer-friendly environment.
This pattern’s core benefits are addressing the granularity mismatch between a service and its cloud primitives, aligning the operational concerns to the service boundary, and making the service a first-class entity in the cloud runtime. Furthermore, it shifts the focus from infrastructure-first to application-first, forcing Dev and Ops teams to think and act in a service-centric manner. This shift could significantly reduce the cognitive load when dealing with cloud services, making it a powerful abstraction for developers.
However, adopting this paradigm shift in cloud service consumption has its challenges. It requires a change in mindset from both developers and operations teams, a willingness to embrace new patterns, and the readiness to adapt to a service-first approach. The real question remains whether we, as an industry, are prepared to embrace this paradigm shift and harness the full potential of cloud services.