How We Built: Moving from AWS to Equinix Metal & Cloudflare
One of the best things about building your own product is dealing with real-life problems and we are enjoying every moment with that.
This post is not about here’s a pro, here’s a con, and here’s another pro. We spent the most valuable asset that we own to build something from scratch — our time, through different platforms in the hope of finding the right place for our solution and this post is the first part of the story.
The Contradiction
The reason Qubitro exists is all about making things simple. What we offer and how we offer is another post content but let’s start with why there is a contradiction between the reason we exist and the traditional cloud providers.
When I say making things simple, it also covers the pricing, the way we generate revenue. The typical way of building a solution is combining some managed services and offering a product or services.
However, it simply is not possible to offer high-performance, easy-to-use solutions with a marginal improvement on the business model (pricing) in the traditional way. That is why we moved away from the idea of using managed services since day one and decided to go with an open-source software stack and develop some parts from scratch.
A simple example would be working with MongoDB instead of DynamoDB or CosmosDB which I will cover with all details in the next post.
The Problem
Apart from the core business value, freedom, and technical flexibility, here are some common problems that we faced off.
A complex pricing, surprised billings, and vendor-lock
Like many other startups, we already work hard and try to optimize our time, and spending quite some time on pricing every month is just a waste of time for us.
This is quite a known problem that we see in the sector, we even see new cost optimization startups that try different approaches from time to time.
And when you combine with all the unnecessary time-consuming stuff like IAM, AWS unique naming convention, we were having a hard time focusing on writing a simple code. Those are important, mission-critical for many businesses, but not for us as we are a speed-driven early-stage Startup.
Being able to scale when you need to, not later
When there is a spike in usage, being able to scale is not a theory but a requirement. Waiting at least 30 minutes to spin up a new machine, or opening a support ticket to increase available resources wasn’t quite an option obviously.
We had some moments that were painfully difficult :)
We don’t need fancy services
I personally believe that traditional providers fit better when you need complex solutions as a service.
What we do is pretty simple and depends on relatively old technologies. We don’t get the benefit of AI or ML in any case for example.
Moving everything to Equinix Metal
I shared our first blog post about our journey to bare metal a few months ago. Everything has worked pretty well since then with great support from the Metal team, and we wanted to go further.
The first thing you’d notice when you switch from a traditional cloud provider to Metal is plenty of resources and everything is much faster than standard virtual compute instances.
A screenshot from the Equinix Metal dashboard to visualize some locations and hardware options.
There are also plenty of good operation system options from Ubuntu to Flatcar.
Object Storage and Caching
We were hosting our objects (images, files, etc.) on AWS S3 combined with AWS Cloudfront, like many others.
We had two options to go with; with the custom domain name on Cloudflare for caching, or Min.io with the same approach.
Both cases are super easy, all we had to do was creating a CNAME record on Cloudflare.
The last 12 hours metrics at the moment:
That is amazing how easy this trick is and much less expensive compared to AWS Cloudfront or Azure CDN.
Kubernetes to Serverless
qubitro.com is our main page, visited more than any other sub platforms as expected. It’s developed by using React and used to be living in our production cluster. We wanted to make it more accessible, have a much faster loading time, and not blocking the main traffic.
There are good solutions, such as Netlify but we noticed a React framework called Flareact, built for Cloudflare Workers. With a few tweaks and a simple GitHub action configuration, we were able to serve our main page across the globe for free!
We also had small pieces of code that handle small tasks like sending a welcome email, synchronizing users with CRM, etc. and they were also living in the cluster. They also now deployed as a worker to the Cloudflare.
TCP/UDP Proxy at Scale
One of the benefits of AWS Classic Load Balancer was being able to offer MQTT over TLS, which is not possible with typical load balancers on Azure or GCP.
I had a chance to play with Spectrum, a reverse proxy product that extends the benefits of Cloudflare to all TCP/UDP applications.
Spectrum offers real-time traffic acceleration and DDoS protection with the following options for each subdomain.
- Edge TLS Termination
- Origin TLS Mode
- IP Access Rules
So, with this transition, we were also able to move our broker to Equinix Metal and combined it with Spectrum.
With the following configuration, it looks fast, isn’t it?
Summary
We managed to design a simple system for our current needs without compromising on performance, security, and privacy.
Thanks to these amazing solutions, we feel more confident and competitive in the market.
From databases to choosing the programming language, we will be sharing our experience weekly upon this post.
Helpful Links
