What is Stone Assemblies in the first place?
It has been a long way before making this decision. I worked for state-owned
companies for years, in fact, I still do, but now I try to see this from a different perspective. I did not keep any of the things that I built or designed in the years of work. Maybe just professional experience.
Now, I decided to start over again, by creating something more personal. Stone Assemblies is a new software development and consulting group or organization or project. Actually, if you are running a software business or starting a
new one, you probably need us ;).
I cannot say that Stone Assemblies is a company or a small and medium businesses
(a.k.a. PYMES). There are many regulations here in Cuba and probably I will need some legal assistance to reach that point. So, let's keep this simple. I just founded Stone Assemblies and of course, I'm the lead software engineer. That sounds great, doesn't it?
The story of the name is quite funny, so I will probably tell you one day about
it, but not today.
Some background and context
Last year I was outlining strategies to modernize the systems of an organization,
implementing proofs of concepts, which would allow their legacy system to support more workload.
This particular system is in fact a database-centric large monolithic one. There
are several options to scale this kind of system.
One of these options is vertical scaling, but they could eventually reach the same state. In fact, the database provider may have limitations to use all the resources, even those limitations could be expressed in the use license. But the main reason is that computational resources are finite.
The other option is horizontal scaling, but even when the database vendor has options for horizontal scaling, it doesn’t solve the fact that the system is actually a monolithic system with all the well-known issues of this kind of architecture. Again, this option could also have limitations expressed
in the license.
Our research led us to review some well-known patterns, and we started with:
Command and Query Responsibility Segregation (CQRS): CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level.
In combination with a migration approach from the:
Strangler Fig: Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system's features, strangling the old system and allowing you to decommission it.
and looking to maximize the added value for a minimum viable product (MVP), we
identified one key feature of the legacy system, so, we decided to also include this one:
Gatekeeper: Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service, validates and sanitizes requests, and passes requests and data between them. This can provide an additional layer of security, and limit the attack surface of the system.
What is Stone Assemblies MassAuth?
The key feature I mentioned earlier, is an extensive, exhaustive validation subsystem that is executed before any attempt of command execution. But all these validations - query base operations - are executed in the main single database demanding computing resources, to the detriment of the performance of the other commands that could be executing at the same time. Remember, this is a very high
concurrency system.
The diagram below shows the monolithic shape of the system.
 |
| Monolithic shape |
So, why not move all those validations to an isolated subsystem? The idea is to replicate all the slowly changing data, which is used in validation queries. With this only action, all validation workloads are executed in isolation, with the advantage that is also possible to assign dedicated resources to run these tasks. The following diagram depicts this scenario.
 |
| Validation workloads run in isolation (CQRS) |
With this idea in mind, is not hard to generalize a solution that intercepts any message, and executes a
preflight without impact the core system. This is the idea behind StoneAssemblies.MassAuth.
StoneAssemblies.MassAuth is a
free, open-source distributed, extensible message-based authorization framework built on top of MassTransit. Actually, it allows you to improve the responsiveness and throughput, from a loosely coupled and message-driven approach.
The following diagram shows, the result of starting to strangulate the monolithic system, segregate the
responsibility of command and queries and the usage of StoneAssemblies.MassAuth.
 |
| Result of system modernization and evolution |
By the way, if you didn't notice yet, StoneAssemblies.MassAuth is a Gatekeeper implementation.
StoneAssemblies.MassAuth is also built on top of powerful and insane extensibility system StoneAssemblies.Extensibility. So, basically, all authorization rules can be provisioned as plugins for the authorization engine, but that's part of another story. I will
tell you more about this in the future.
Send us your feedback
This is a work in progress and we are continuously releasing new versions. Sources and sample codes,
are available in GitHub including some Benchmarks. Packages
as usual, are available in NuGet gallery and we also provide production-ready
of StoneAssemblies.MassAuth.Server (a.k.a. authorization engine) as docker image
available in DockerHub.
Without too much to say, I just invite you to use StoneAssemblies.MassAuth and let me know what you think. You can also look forward to the next post where I will explain how to use
StoneAssemblies.MassAuth from a quick start.
Remember, this is an open-source project, so, you are welcome to contribute. There are a lot of work to do, so
you can contribute by creating tickets, with pull requests, or just by inviting me to a coffee ;)
Enjoy «authorizing» with pleasure.
