Why RAR Architecture is the next big thing

For way to long architects have been designing solutions that are too complicated, overengineered and instead of bringing value to the business they grind the business to a slow dinosaur where the technical solutions become their own eco systems with teams protecting them and as the Business Landscape changes the company is not able to move as fast as they want so they fall behind even more and they are not in a downwards spiral that is very difficult to get out of.

Luckily, the answer to this problem is what I call RAR Architecture, RAR stands for Rip And Replace, what does this actually mean?

Think of RAR as the evolution of KISS (Keep It Simple Stupid) and Micro Services Architectures, RAR will bring enormous value to your business and will allow you to be at the forefront of technology, not for the sake of the technology itself but for the value it brings to your business.

The entire idea of RAR is to simplify things to its basic smallest components and question every vendor best practice out there because honestly vendors are looking to lock you into their solution and provide value to your company by using all their products and services.

This is rarely the best way forwards though because what really is happening is you are unable to change vendor in an easy way, this in turn puts you in a bad negotiating position every time you need to renew a contract with the vendor. I am not saying you should change vendors every 6 months, but I am saying that if you wanted to you should be able to.

By always questioning and understanding the business value of a solution vs its complexity we can design architectures that goes beyond simple disaster recovery, or active/standby solutions and we can design proper RAR nonstop architectures at a fraction of the cost of the many High Availability solutions that exists today.

All you have to do is to think differently and fully understand that RAR architectures will allow you to achieve miracles and allow your company to move faster than your competition and negotiate better contracts thus saving money that you can use to enhance your business as opposed to paying to maintain an aging technology landscape.

What are the steps to achieve a proper RAR architecture? Let me give some real-world examples from implementations that we have done over the last decade.

Example 1: Network Solutions

When designing a medium to large size global network with Private datacenters in three parts of the world, a lot of the clients' discussions where around convergence and speed of convergence needs to be quicker than n seconds, all of this is very much achievable but at what cost? Does the increased cost and complexity actually map to the business need?

As it turned out it didn't so by carefully walking the client through the massive cost difference between a sub 1 minute recovery and a sub-10-minute recovery we were able to not only save a huge amount of money but at the same time achieve the most important step of them all in RAR architectures, vendor independence.

Being able to swap out a vendor requires the use of vendor interoperable protocols, in this specific case we were able to get away from Vendor specific routing protocols in favor or Internet standard protocols like BGP, which every vendor in the world supports and have been using for decades already so vendor inter-operability is well proven.

This allowed the client to:

1. Choose different vendors in different part of the world should they choose to.
2. Build a scalable and predictable network that is so simple that to find support engineers to support it was 13 to the dozen.
3. Change vendor at a moment's notice even in the same city/DC.

Example 2: Non-Stop application delivery

In this example the client wanted to run a nonstop application with very high availability, the interesting part about this RAR solution is that it really demonstrates what RAR can do when done correctly.

Instead of deploying a single application and go all out with bells and whistles to create HA networks, HA clusters, Cloud solutions with complicated load balancer solutions etc. to achieve the required uptime of the application we looked at things from a totally different point of view.

Is it really the application that needs to be HA capable or is it the service that the application provides to its users that is key?

99% of all people get stuck in achieving HA by adding complexity but by using RAR and deploying to different applications that each were so much simpler that we brought in massive value to the benefits, specifically the following.

1. Huge cost savings since we removed all the costly HA solutions from all vendors.
2. The ability to run each solution on a different cloud provider, thus eliminating the need to use complex multi region cloud deployments. We can simply run very simple basic services in each cloud with a simple DNS based service to push traffic to the correct cloud provider in case of failures there is 0 downtime since there is no recovery time needed, one application goes down the other one is still working, simple switch application and continue working.
3. Make it so that if all else fails the application on the clients' customers mobile devices were able to achieve the tasks needed meaning that the service could be provided even if the network in the location was totally down, even if all devices at the clients' location were broken or out of action, they could utilize the end customers mobile device to give the customer the service they needed.
4. Totally remove the dependency on a single application provider leading to direct cost savings as the contract negotiations removed all sort of lock in situation leading to no vendor being able to pressure the client into new contracts because their solution as so intertwined that it was impossible to remove.

This is RAR architecture at its best bringing the following benefits:

1. Huge cost savings.
2. Simple and cheap to operate solutions.
3. Speed and agility to the business.
4. The ability to switch out any part of the solution while still conducting business as usual on the other application, this is true nonstop application delivery at a fraction of the cost of traditional HA deployments.

Of course, RAR is not a one size fits all, there will always be exceptions where the high-speed recovery or a service provides such immense value to the company that its worth spending the extra money to achieve it, financial trading systems is one use case that comes to mind where milli seconds really count, I am sure there other but they are all exceptions and we should never design the majority of our solutions with the 1% exceptions in mind, we should design for the 99% of customers who can really benefit from a proper RAR architecture.

Another thing that is very important when designing RAR architectures is to question and review solutions that has been taken for granted for years.

Let's look at a hypothetic example:

Cloud provider A has a service that includes a front-end web service WYSIWYG type interface that includes a workflow engine that can run in the cloud as well and tightly integrate with the web service front end.

Sounds great to get everything in one package as a SaaS solution, no need to worry about running any infra structure or scaling as it is all part of the service provided.

But with RAR in mind you quickly realize that should you wish to replace the front end you most likely have to change the workflow engine as well since they are somewhat tightly coupled.

It would be a much better architecture to utilize a different workflow engine that is not tightly coupled to the front end but instead provides simple standard REST API's that can be called by any web front end leading to a change of the front end service is totally independent of the backend API workflow engine, meaning we Rip And Replace the front end in parallel thus making it a very low risk project to run.

This also works the other way around, you might want to replace the workflow engine to another workflow engine, with RAR you are free to do so, as they communicate using standard REST protocols, there is nothing locking you in or stopping you from even running front end and backend in different clouds, not saying that is a good solution in most cases but nothing would stop you should you want to and that is the essence of RAR.

Another thing that RAR brings to the table is the ability to increase security and allow you to run a multi-vendor protection thus protecting yourself from vendor BUGs since it the risk that multiple vendors suffer from the same BUG at the same time is much lower than a single vendor suffering from a BUG putting your assets at risk.

Conclusion:

Implementing RAR architectures is the future, it will allow you to become faster with less risk and save a huge amount of money while providing more value to the business.

Contact us on [email protected] if you want to know more and start the evolution towards vendor freedom and the ability to sleep at night without worrying about complex solutions that only makes you slow and allows your competitors to run circles around your business.