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. Companies cannot innovate and compete under such conditions. They may barely survive, at best.
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.
Further, software architectures have consistently missed the mark when considering the multiple decades of vast improvement in hardware architectures. Simply stated, software is in the middle ages compared to the leaps forward in hardware and the contemporary means of efficiency that such hardware can support, but rarely has the opportunity. Archaic software is directly responsible for driving up the total cost of the hardware required to run it. It doesn't matter where you choose to run the software: in a datacenter, private and on-premise, or an off-premise cloud. Your software is almost certainly using vastly more hardware resources than are necessary for the representative business solution.
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 are in need of change in making software utilize hardware in the most efficient ways. We need change in how business-driven solutions and the technical components align to achieve true competitive advantage.
It is rare to see business and technology align to reach a fullness of competitive advantage. If you look carefully at the most successful companies, they are such because of the ability of major stakeholders to communicate laterally, and as a result, the strong human and team partnerships that are formed because a vision is understood and shared. This is not because only one or a few business leaders communicate well. It's because everyone involved has formed open and clear communication channels that consistently and constantly harmonize with making vision reality.
Note that lateral communication is key. It means that executives share the responsibility of delivery because they are not talking down to the other people involved. They see themselves as part of the team, which means they see others as part of their team. In the modern era where software is continually eating more and more of the world, old hierarchies of communication cannot last.
One person understood this well in 1967, and shared his understanding with the world. This person is Melvin (Mel) Conway. He observed that organizations design systems that mirror their own communication structure. This observation has become known as Conway's Law.
Note that Conway's Law is not limited to software systems and is equally applicable to any kind of system. Even the operations of a business is a kind of system, from hierarchies to function or disfunction, because results will occur from the way communication happens. If people see themselves as lesser and driven by command and control, fear and guilt, and the like, the business system itself as a result of that communication structure will disfunction in exactly those ways. If the business decreases or eliminates hierarchy and literally sees and acknowledges the value of everyone as a team member, the business system itself will thrive, because it will function in exactly those ways.
The same goes for smaller teams that are formed to produce software that makes the business system better than it would be without it. A greater extent of better is only realized as communication drives toward deeper knowledge and continuously examines every conceivable possibility for improvement. This requires respect on all sides, which includes those who are not technology practitioners and those who are. They must respect each other and communicate in a way that engenders the example set by the business leaders. In fact, everyone should be a business leader.
Deep communication, critical thinking, and cooperation are indispensable to achieve disruptive, transformational, software systems. Thinking with a goal toward constant learning is key. What are we doing? Why are we doing it? We must think: informedly; clearly; critically; broadly; deeply; thoroughly. What are the business goals and strategies? What are the service-level requirements? All of these can be achieved without threat to anyone, because they are sought after respectfully. The goal is to learn and learn quickly, which leads to transformational breakthroughs.
We need change in how business stakeholders and software developers interact to achieve better business outcomes with software. This only happens with learning, where increasingly greater degrees of better are realized as our team communication drives toward deeper knowledge and continuously examines every conceivable possibility for improvement.
Admittedly, developing software that is most efficient is not a mainstream concern. This is not for good reasons, which include lack of knowledge, complacency, and dismissing the need for self and business improvement by such means. Many simply don't see or acknowledge the costs of inefficiency.
Unfortunately not many software developers are business minded. Such ones often think that business-oriented people should be more technical. This is unrealistic. Although every software developer is capable of possessing a good measure of business savvy, not all business people are capable of becoming good software developers. Yet, rather than embracing business thought, tech-only developers consider their increasing technical prowess as the means to keep themselves employed. This is in conflict with their own interests, however, if their current job disappears due to the business facing costs that outstrip revenues. More to the point, gaining technical prowess in software efficiency is a means of delivering solutions that are less costly and thereby take aim at threats to business profit.
It may be difficult, however, for some to justify what appears to be novel approaches, practices, and techniques. Unless it is currently mainstream, there isn't much motivation to seriously investigate with the intent of adoption. Those disinclined or reluctant to take risks will likely consider the unfamiliar to be too risky to their future success. Others will avoid what requires them to move out of their comfort zone. It requires thought leaders to reshape and motivate the thinking of the overall industry.
But why might developers see a different, yet more efficient approach, as dangerous and even threatening? Those who refrain from the use of the most efficient architectures, programming, and related tools, are generally concerned about the learning curve being too steep, and that they'd be risking failure with the unfamiliar. After all, they didn't learn much about such techniques in school, if anything at all, and they haven't read or heard much about it in the industry news.
Although a learning curve is indeed required, it's not as steep as most think. Yet, that is not actually the point at all.
In actuality if we were required to learn software development techniques to achieve runtime efficiency because the industry were to move in mass in that direction, we could no longer be employed in challenging work if we didn't learn the techniques. Sure, we could probably find work in maintaining the inefficient code that we have known for years and that has kept us in our safe zone. Yet, we should not expect much more.
Imagine what it will be like when not developing software for maximum efficiency is like knowing COBOL in the 1980s, but not seeing the need to learn groundbreaking, newer and promising techniques, such as object-oriented development. Imagine those who used a waterfall process for a decade or two, and when hearing about agile, thought it sounded like chaos and that it could never lead to successes. In both cases there were and are casualties of their (in)decision.
Although developers can now make good money maintaining incredibly messy, decades-old, COBOL code, this is due to the enormous shortage of COBOL developers. Why? Because few over the past many years have seen any future in it. Would you choose to work in COBOL even if the money is good? Probably not, otherwise there would not be such a shortage of COBOL developers. The programmers who wrote all that code probably have grandchildren, or even great-grandchildren, or are no longer with us at all. That's why the companies ingrained in COBOL systems must sooner or later find replacements for those systems. There are now virtual banks innovating in order to replace those archaic banks all together, and to be acquired by the ones who can admit the inevitable.
Although some remaining developers may feel entirely comfortable with waterfall software processes, what is the likelihood of getting a future job if they don't know or are unwilling to learn some form of agile? Even though many have dragged agile astray from its roots, those retaining the balance of simplicity of use are successful. The likelihood of big upfront design having a resurgence in the industry approaches zero.
At some point in the near future, the same kind of eventuality will be faced by developers who don't know or are unwilling to learn Reactive software development.
So, when developers actually face that point of reckoning, what will they do? They will just learn Reactive, because their relevance as a developer will depend on it. Even so, it is certain that their learning would not end with the rudimentary. Like the recent wave of "I am an expert with Kafka," and "I am an expert with Kubernetes," suddenly the very developers who resisted and rejected Reactive will feel the dire need to declare themselves experts with it. It would lead to an explosion of those claiming to have the corner on software efficiencies with Reactive architecture and programming.
Think, however, of the advantages of learning Reactive now. Claims of knowledge and experience would have real substance. Knowledge will actually put the current learners—hopefully you—in that situation when Reactive is at its highest point of demand.
A cognitive bias kicks in when people need a justifiable reason to save mental energy.
Being unwilling to learn Reactive software development now, due to its "learning curve," rather than learning when it becomes urgent to do so, is an example of a cognitive bias. In essence a cognitive bias kicks in when people need a justifiable reason to save themselves from expending mental energy.
Saving ourselves mental energy often occurs when we encounter something new or face a problem that we prefer not to think about. In fact, we will actually choose a more familiar, yet complex, way of doing something over choosing simplicity. That's generally because making things that are as simple as possible requires more thought than pursuing complexity because it is familiar and the result of automatic thought.
To reinforce that the Reactive learning curve is not too steep, those who have already embraced Kafka and other messaging and streaming tools have taken a first step toward Reactive.
This is so in all kinds of human situations. A person will not change some poor eating habits because it takes thought and determination. Thus, most in that situation would simply stick with what is familiar and even be drawn to new food offerings with similar characteristics. This is even the case when a simple diet that is composed of the right foods is far more healthy for them. In many cases change doesn't occur until a person learns that they will die sooner than a normal life expectancy unless they change to a healthy diet. Think about the trouble and risk that would be avoided if such a person adopted healthy eating in their younger years because of being mindful of their future.
How does unhealthy vs healthy diet overlap with Reactive? Building software with familiar tools that offer a thread-blocking paradigm is bad for the heath of software as it pertains to scale and related costs. It is relatively simple to change that, but the thinking of the software developers addicted to a blocking paradigm see it as too much thought and change. For most it might be a matter of waiting for someone to enforce change because the costs of inefficiency are unjustifiable. The ultimate demise of such systems may lead to necessary change, or to the death of business operations remaining heavily vested in them.
The fact is that computer software design is, as of the year 2020, 17+ years behind the design of modern microprocessors. It's literally an upside-down comparison. If you were to return to this document a year from now, it will certainly be 18+ years behind, because thought leaders in this area cannot possibly move the dial in the right direction in only 12 months. It's going to require a sea change in industry mentality driven by true software futurist-leaders to enlighten the millions of less mature ones.
Note that this is not a prediction. It's simply a matter of what is required to cause enormous change. Even so, it's not entirely up to software leaders. When business leaders realize that their money and that of investors is being unnecessarily consumed—squandered—because developers are complacent with changing toward efficiency, this will surly result in an irresistible drive toward change.
A few years ago it was common to hear that CIOs didn't care about the cost of the Cloud. They just wanted to unburden themselves from the complexity and monetary costs of datacenter and on-premise computing. Yet, a few years down the road, those same CIOs who didn't care about cost are now rethinking that decision. They have realized that the Cloud can be or has even proven to be far more costly than was previously understood.
A Forbes survey indicates that too much corporate money is evaporating into the Cloud, to the tune of 30-35%. It's reported as being mostly due to sloppiness. What if executives learned that part of digital transformations could lower those costs not only by 35%, but a far greater percentage of their current overall costs, by running more efficient software systems?
If the problem was not considered urgent even with these discoveries, that is likely to change very quickly, if it has not already. Over-spend on the Cloud is even more disturbing now in the new era of COVID-19. Every Dollar, Euro, Pound, Franc, Krone, Shekel, Yen, Dirham, Dinar, Yuan, Rupee, Real, Rand, and Peso being spent is a glaring source of budget impact. The excesses must be addressed, and software leaders much spearhead the efforts through information and education.
Think of the benefits to the health of the computing industry. If you, after all the above, are still on the fence on this argument, suspend disbelief for just a moment. Place yourself in the position of being very concerned about computing health, because software is not only eating the world, it is eating your business profits. Now, you learn that by adopting Reactive as a primary means of software architecture and development, there are real, extended, fiscal benefits.
Reactive makes full use of hardware CPU power, resulting in the most efficient software
Efficiency reduces the shear amount of hardware required to run the software
The reduction in required hardware reduces monetary expenses
The reduction in monetary expenses increases net revenues
The reduction in required hardware reduces the environmental impact of software
The reduction on environmental impact of software increases quality of life
Although Reactive is not currently a household word for executives and software development practitioners, every business founder, board member, executive, and investor understands that reducing expenses leads to gains. Not to be forgotten is that software efficiency is a first-order environmental concern. If you lead in the direction of Reactive, your efforts will not go unrecognized or unappreciated. You will be the face of the inefficiency resistance and a pioneering change agent toward global software efficiency.
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 and the greater the efficiency.
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 solutions that require outsmarting the tooling to eventually create working software. Yet, the software rendered from this process is inherently complex at the implementation level. As a result, you would never consider showing it to business people, allowing them to 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. When anyone using our toolset feels uncomfortable with any perceived complexity with our concepts/components, we will given priority attention to simplifying further. 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. Business people should feel completely comfortable reading and reviewing your domain-driven source code with your lead.
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 different and likely opposing 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. Actors are objects, but without direct method invocations. Instead actors send and receive messages asynchronously. | |
The platform adoption accelerator for Java and other JVM languages, including a lightning fast quick boot and quick starter command-line interface and Web-based UI. | |
A reactive HTTP server that provides request-response services that can be embedded into any given service. It is small, fast, and supports fluent APIs that adhere to your DDD Ubiquitous Language as a first-class concern. | |
Tooling for reactive Domain-Driven Design projects, and featuring highly concurrent models. Includes compute grid, actor/object caching, object spaces, cross-node cluster messaging, object aggregates, state aggregates, event sourced aggregates, CQRS with projections, messaging exchanges, and long-running processes (aka Sagas). | |
The Reactive Streams implementation for the VLINGO/PLATFORM fully build on the VLINGO/ACTORS reactive and asynchronous foundation. | |
An advanced schema registry provides the means to safely publish standard types that are made available to client services. Provides command-line interface and Web-based UI. | |
The reactive, scalable, and resilient CQRS, Event Sourcing, Object, and Key-Value storage, and projection tools for services and applications. With three major persistence types, all based on reactive and actors, there is no strong opinion about a given approach to persistence. Teams are the best to determine their needs, which may be different between Entity types and from one Bounded Context to another. We support a number of cloud and traditional storage engines: DynamoDB, Apache Geode, and various JDBC types. | |
The way to scale your services across a number of nodes, whose components can communicate and collaborate with components on any given node. | |
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 small set of reusable components used by multiple platform components. (Don't worry, this is not a catchall.) | |
Wire protocol messaging implementations, such as with full-duplex TCP, UDP multicast, and RSocket, using VLINGO/ACTORS. | |
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 reactive metrics collector plugin for the VLINGO/PLATFORM, including support for VLINGO/ACTORS, VLINGO/HTTP, VLINGO/LATTICE, VLINGO/STREAMS, and others. | |
A set of build tool plugins supporting automation for the VLINGO/PLATFORM. |
See each of the documents for guidance on how to use of the individual platform components.
