Introduction
Obsolete and brittle architecture, and deficient software design, have resulted in the competitive paralysis of the software industry. It is quite common for large enterprises, that once enjoyed competitive distinction, to be hamstrung by Big Ball of Mud systems that prevent more than a few releases per year.
These legacy monoliths have generated profit for decades. Yet, the gradual myriad of changes to these revenue generators have led to a paralyzing tangle. The recurring plea for help? Teams are demoralized by the mud, and hardware has outpaced software architecture. Large companies that have experienced stagnation need liberating relief and mobility through enterprise modernization and transformation.
We are in need of change. We need change in how we interact with business stakeholders to achieve better business outcomes with software. We need change in the level of complexity regularly experienced with the software components that we build on. We need change in how business-driven solutions and the technical components align to achieve true competitive advantage.
Use the open source (OSS) vlingo/platform to achieve the simplification of distributed, concurrent, reactive, event-driven, and microservices architectures. Along with Domain-Driven Design, this is the crossroads where business strategy and modern technology meet. This means that the vlingo/platform doesn’t get in your way as you build your Bounded Context with its Ubiquitous Language. Rather, the vlingo/platform facilitates the explicit and fluent linguistic expressions of your core business models. Consider our platform DDD-friendly. Together with simplified multi-core enablement, your teams are supplied with a powerful toolbox full of versatile components supporting innovation.
There is far too much complexity in the software industry. The overarching vision for the vlingo/platform puts extreme emphasis on simplicity. With our platform components, preconfigured for common use cases, you should be productive within minutes, not an untold number of weeks or months.
In 1973, Dr. Carl Hewitt and his colleagues formulated the Actor Model. In recent years, the inventor of object orientation, Alan Kay, has stated that the Actor Model retained more of what he thought were the important object ideas. So, when you think of the Actor Model, think of objects done right.
The vlingo/actors toolkit is an implementation of the Actor Model. The ideas behind the Actor Model are powerful, and the vlingo/actors toolkit elegantly implements the concepts behind it with simplicity. The vlingo/actors toolkit is type safe by design, and services use it by defining and implementing domain-specific interfaces as actors. This box shows how actors work and what they do.
How actors work and what they do |
An actor receives messages in its mailbox, and processes one message at a time when a thread is available. |
Fundamentally, actors are non-blocking and share none of their mutable state with the outside, not even with other actors. |
Actors use available threads, and you can’t run more threads simultaneously than there are available cores, e.g. |
The basic unit of computation is expressed through actors. Actors send and receive messages asynchronously. |
As objects create other objects, actors can create other actors. |
Each actor can designate the behavior it will exhibit for the next message it receives. With vlingo/actors this can be accomplished by actors implementing multiple type-safe domain-specific interfaces. |
As objects are typically used, software developers have become accustomed, even addicted, to the blocking paradigm. In the blocking diagram a Client object invokes a method on a Server object. This is an in-process (in-VM) invocation, not a remote client and a remote server. The point is, when a method invocation occurs, the Client is blocked until the Server returns from the method invocation. This means that the Client can perform no additional operations while the Server is handling its request. In contrast, the Actor Model works differently as is shown in the message-driven diagram.
When the Sender actor wants another actor to provide a service, it sends that actor a message. The message is sent to the Receiver actor and handled asynchronously when a thread is available. The Sender is not blocked, but continues moving forward with its current activities, and when those complete, it returns from its own message handling. As a result the thread previously used by the Sender is now available for another actor. This achieves maximum efficiency across all actors in your service instance. The more cores that are available, the greater the overall throughput.
With vlingo/actors, type-safe messages are the fundamental building block. For those that depend on static typing, a strongly-typed Actor Model implementation is crucial to reassure developers that they are sending the correct and intended message to each actor. This is guaranteed by the compiler, and adds no overhead beyond a typeless implementation.
There is far too much complexity in the software industry. The overarching vision for the vlingo/platform puts extreme emphasis on simplicity. In a few moments you can download the platform components through your build definition, with the whole platform fully configured for common use cases. You can be productive within minutes, rather than the typical untold number of weeks or months. Try it!
The vlingo/actors toolkit is the bedrock on which our other platform tools are implemented.
Some have asked us to compare the vlingo/platform and specific components, such as vlingo/actors, with other frameworks and toolkits. This is the wrong question because it assumes that our platform is founded on the same motivations as those frameworks and toolkits. The point is, the design of our platform has unique motivations not found in general architecture and programming tools. Our platform starts from completely different first principles. Thus, don't expect us to provide a checklist of feature comparisons, because our checklist would look far different from those that others would produce. Our comparison to the frameworks and toolkits would be unfair to those because we have such unique motivations and they could never align (unless, of course, they would make big changes and copycat).
Most of the other frameworks and toolkits have been created on first-principles of heavy technology solutions, and sometimes those tools includes support for actors. Yet, the creators and users of those tools are generally drawn to complexity as if it is a "right of passage" to deliver deeply complex tools that require outsmarting the tooling to eventually create working software. Yet, the software rendered from this process is inherently complex and you would likely never consider showing it to business people so that they can confirm its adherence to the business mental model.
To understand the vlingo/platform, you must start from different first principles.
Simplicity
DDD-friendly
Other than considering our platform, these combined principles are so extremely rare that we consider our tools quite unique.
The vlingo/platform was designed for building fluent domain models inside applications and services using a DDD mindset. The vlingo/platform is built on actors but is not just actors. It is simple to use, and anyone uncomfortable with any perceived complexity around any of our concepts/components will be given priority attention. Building fluent business-centric domain models is what DDD modeling is all about, and supporting the same fluency in the other components in the architecture of services is an enormous plus. You are not mostly using technical tools, but tools that support readability in a business-technical partnership.
The people who will choose to use the vlingo/platform or any of the other frameworks/toolkits will be those who gravitate to one or the other set of first principles. That's because the first principles represent two mindsets.
The following components are available for use.
Component | Description |
The type-safe Actor Model toolkit for reactive concurrency, scalability, and resiliency using Java and other JVM languages, serving as the foundation for the message-driven platform. | |
An identity and access management tool used by the vlingo-platform where data and its use must be secured. Your services may use this facility but are not required to. | |
The way to scale your services across a number of nodes, whose components can communicate and collaborate with components on any given node. | |
A small set of reusable components used by multiple platform components. (Don't worry, this is not a catchall.) | |
The means by which services register with the system and discover collaborators. It's not a passive "look-up registry." It is a publisher of service availability and access. | |
A reactive HTTP server that provides request-response services that can be embedded into any given service. It is small and fast. | |
Tooling for reactive Domain-Driven Design projects that are highly concurrent. Includes compute grid, actor caching, spaces, cross-node cluster messaging, CQRS, and Event Sourcing support. | |
A plugin for the Maven build tool supporting automation for the vlingo platform. | |
The reactive, scalable, and resilient CQRS storage and projection tool for services and applications built on the vlingo/platform. | |
An implementation of vlingo/symbio state storage for the Amazon AWS DynamoDB. | |
The reactive Apache Geode storage for services and applications built on the vlingo/platform. | |
An implementation of vlingo-symbio state storage for JDBC databases, including Postgres and other hardened relational databases. | |
The reactive metrics collector plugin for the vlingo/platform, including support for vlingo/actors, vlingo/http, vlingo/lattice, vlingo/streams, and others. | |
Wire protocol messaging implementations, such as with full-duplex TCP and UDP multicast, using vlingo/actors. |
See each of the documents for guidance on how to use of the individual platform components.
