Defining the architecture or choosing the tech stack is always an interesting adventure

From my experience it always has been a matter of choosing your own battle hill, when the choice is done, you “fight” for it.

But the experience also thought me that when you find out that your stack is not longer going to fit the business, you rather change it while you can because it can quickly became the hill where you are going to parish.

We wanted a platform that we could quickly prototype a solution but also could scale to the highest level of performance, we wanted something that we could bring less experienced personnel but at same time we possessed a lot of experience to guarantee proper development and maintenance.

• Team Experience
• Large Community
• OSS
• Reasonable Cost

The selected technologies responded to all the above requirements. For more details we’ve shared our complete stack here .

Development Tools & Services

Choosing Ruby (RubyOnRails) over Go was a challenge due tothe fact that I I’ve been developing my own set of tools (avoiding to call it a framework, but definitely going to need to find some time to make it ready for a proper OSS project)for Go but RubyOnRails was the winning factor. It’s mature, fast (yeah, it’sfaster to deliver products than it’s with Go) and we were very experienced withit also.

For the presentations layer we had the classic fight between Flutter vs. React but actually the choice was much easier here, flutter all day. Based on the fact both platforms matched very well in regard of features, support and maturity the only differentiators where just the experience I had with it and the developers pool available in country.

For the simple pages for Wiza VueJS was the option no competition here.

The choosing of a message queue was also a simple deduction based assertion based on the fact of being a battle tested solution and also because of having a very substantial experience with it. RubyOnRails has very solid messaging queues “solutions”, but I wanted to make sure if I needed to change the backend in the future it will be possible without changing the whole chain.

So, RabbitMQ was the solution as it delivered everything we wanted:

• Scale to large monolith or microservices
• Use of multiple message queues solutions
• High availability
• Simple decoupling

As the image above suggests, we needed a object storage solution and you could hear the drums of Microsoft Azure and AWS in the horizon… but of course we had to go for it because of the simple fact we needed something we could be scale with it.

We went for *Minio a similar service that was compatible with S3 cloud storage service. We could handle the service management, it could give us the tier one level service and we could decouple for other services where we used Amazon S3. So, team experience, large community and OSS boxes are all checked under these technologies.

So… who’s hosting that baby ?

Well, we clearly did not have much of financial room to maneuver to get saved by the magic of push and deploy, but we had the boldness and the ninja skills and also it was 2022 not 1999, Ubuntu VPS + docker + kubernetes equals let’s Go!!!

So, we deployed a couple of virtual private servers on AWS and Azure and got my hands “dirty” on building a multi regional cluster for everything.

Setup a backend services running RubyOnRails API services pods, NGINX fired up and run as Web Server and Reverse Proxy for everything accessible outside and AWS bouncing connections with Amazon ELB.

We run our own container registry just because we wanted to make sure deployments were faster and cheaper of course with the maestro Kubernetes handling the orchestration using MicroK8s with Github Actions.

Keeping an eye on everything

When talking about other people money the first thing that comes to my mind is Big Worm quote about handling other people money “…Playing with my money is like playing with my emotions”and to maintain a tip top service on a financial business without playing withothers emotions it’s necessary top notch solutions to monitor closely everythingthat happens in and around the platform.

Papertrail (SaaS) comes to rescue as solution to log everything from backend services which then shovels them to Loki which we run it as a private container service. Then Grafana centralizes all the monitoring for every single service and server running for the platform.

Decisions are based on data

We try to relay on data as much as we can, and to give the glimpse over what happens at Wiza we had to implement a solution that could give the freedom to collect and analyze data without much technical expertise or effort.

So, Apache Superset delivered plethora of options, more than we needed at start and being a open source software (OSS) made it even more attractive.

‍

The skills to build, deploy and maintain all those tools and services together spans over multiple disciplines and can only be achieved with several years of experience in several areas, I recognize that. But the most significant skill is the ability to incrementally putting them together at the right time, this requires methodology and luckily software engineering has some very interesting ones and I look forward to share next time how we’ve managed to put some of them together to continue to deliver products and features to Wiza in my next post, until them “ Wiza tukina ”