🌚

Hey Folks!

Clouddley - Cloud Platforms Reimagined

An image of Clouddley's Dashboard

I want to tell you a story. The backstory of Clouddley, why it was built, what we have built, the journey, and my failures along the way. As a teenager, I dreamed of owning a data center which originated from my love for the mysteries of “The Cloud,”; which in my opinion, is the heart of the internet. Think about every software you have ever used and how it improved your life in one way or the other. When I think about the role cloud computing plays in the existence of this software, I love the Cloud even more. It is the heart of the internet ❤️.

In this article, I want to expose you to the world of cloud platforms and how my teenage desires led me to build a tool that solve issues cloud engineers, developers, and founders face regularly.

Tears, Pains, and Struggles

While working at Deimos, I was intrigued by how cloud platforms have become very complicated. When you want to create an application or deploy a machine on Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP); there are a lot of things you need to configure, like the:

  • Name of the virtual machine (VM) or application
  • Virtual private cloud (VPC)
  • Firewalls
  • Operating system
  • Network Security Groups/Security Groups
  • Memory
  • CPU
  • Type of Virtual Machine to use (a lot of folks don’t even know there are certain types of machines used for specific workloads)
  • SSL configuration

If we dive in a little deeper, we will begin to talk about:

  • Load Balancers
  • DDOS Mitigation
  • Identity Configuration
  • Auto-scaling Configuration
  • CI/CD Pipelines
  • Containers
  • Et cetera.

Some existing tools are used to automate these configuration processes, but they require a learning curve. These topics also involve some level of experience to grasp or hire what we call DevOps Engineers. Let’s not even talk about how expensive running an AWS application could be. We have seen folks rack up $1000+ on AWS bills for running three(3) applications or poorly configured services. You can have $100K credit on AWS and still deploy the wrong configuration and services.

I have racked up to $200 for forgetting to delete some EC2 machines while I was a student. Unfortunately, I could not pay for it, so AWS shut the account down. Another scenario that made me have sleepless nights was how a developer racked up a $4000 AWS bill for DDOS overnight. You can read more about it here.

And the list goes on and on. The issue here is that a lot of folks don’t know how cloud platforms work, how to configure them effectively, how to manage them, and how to get the best developer experience from their prefered cloud platform.

But I did something. I attempted to solve these issues. I re-imagined cloud platforms, and I worked hard with the best team ever to build the new kid in the block.

The Birth of Clouddley

I was talking to my best friend about the idea and how we can fix the issues mentioned in the previous section above. One of the ideas was to work at our favorite companies and build this out. I am a huge fan of Microsoft, HashiCorp, Cloudflare, Stripe, Vercel, and Netlify.

Like all passionate engineers, I applied to all of them. Hashicorp and Stripe don’t hire from Nigeria. I never got any feedback from Microsoft, and I was so sad. I was always getting rejected by Netlify and Vercel. I was an early user of Netlify, loved it, and wanted to join the team, but I never got in! I wish I knew why I was rejected; it would have helped prepare me better :(. I have never been so intrigued by engineering made dead simple the way Vercel and Netlify did. Awesome people!

Learning Golang

I already knew if I was going to build something fast and reliable, I had to use something built for speed. Vercel and Netlify were built in Go and Rust (I’m still determining this, I only checked their career page to establish this). I was familiar with Node.js already but didn’t think that would be cut out for the core systems engineering we wanted to build.

I started learning Golang even while at the University. Thanks to my best buddy Bakare, who helped me with debugging and still helps me now. Eventually, Deimos took a chance and hired me as a 21-year-old undergrad. I got the opportunity to work with outstanding engineers, work on solid projects, and master my Golang and other technical skills so well.

Fast-forward to today, I have become an experienced engineer working on Kubernetes Tooling, Infrastructure, and Distributed Systems. I’m also now a co-maintainer and member of CNCF Helm with over 380M downloads. Do let me know if you want to contribute :).

Taking Risks

As a part of my quest to build out my ideas, I quit my job and started working with Phirmware to build Clouddley full-time. We hired two engineers to assist us in building the server, handlers, services, etc. We started looking at what made AWS expensive, why apps are becoming harder to ship, the barrier of entry, etc., and I kid you not, It was hard. This was not a case of an MVP you could build in a month, and there was no API we could call to abstract some parts. I overestimated the difficulty, and it was a challenging process.

Veronica

Veronica dashboard on Github

During the process of building Clouddley, I started writing a reverse proxy server for serverless applications that we use at Clouddley. I called it Veronica. Veronica helps us distribute traffic to different regions on AWS. It also uses Cloudflare API, Redis Cache, Google Cloud Global Load Balancer, etc. It helps cache static assets, offers CDN capabilities, mitigates DDOS attacks, and more. I will share more about how these work and the system design in a different article someday.

The End Game

But we did it! After months of working, cooking, and building. We birthed Clouddley—a platform that allows developers and startup companies to deploy their applications to any cloud provider from our dashboard in seconds. We have shipped for the AWS cloud platform and are ready to onboard customers. We are looking forward to building for Google Cloud, Azure, etc., soon. We even use Clouddley internally as a team to deploy some of our microservices on AWS, which costs us about $5/month. Take a look! Wild right?

An image showing AWS billing for Clouddley

Honest Work

On Clouddley, All you have to do is connect us to your cloud provider, connect your GitHub account, configure your app, and deploy your app. Dead simple!

A deployed Nodejs app on AWS

A demo showing Nodejs/Express app deployed on AWS(us-east-2) via the Clouddley Dashboard.

Link to the deployed app: https://helloapp-7orgtdxa8a8b-man.clouddley.app/

You don’t have to worry about VPC, Endpoints, IAM role, Policies or which type of virtual machines to use, load balancing, etc. Clouddley manages that for you while being cost-effective. So you can focus on your code and shipping to your users while we do the heavy lifting.

We have finished most parts for AWS. Here is what we have shipped:

  • Managed SSL certificates.
  • Auto-scale on demand. You don’t worry about scaling up and scaling down.
  • Custom Domains.
  • Priority support for premium users.
  • Deploy containers or source code.
  • Auto deployments from GitHub.
  • Content Delivery Network (CDN).
  • Environment variables.
  • DDOS Protection.
  • Nodejs 12, 14, 16, Python 3, and Java runtimes.
  • Dockerfile deployments.

Engineering is getting harder, and my team is constantly working on shipping more tooling. I’m currently working on a distributed backend service for custom SSL certificates. When we issue an SSL certificate to a user for a specific domain, a certificate and PEM files are created. We need to be able to store and read/write this data(io). This data needs to be encrypted at rest, and we need to be able to rotate the encryption key. You can read more about this topic. The certificate must be read at runtime and subsequent requests whenever the domain name is called. These are the kind of toolings we’re building, and we will continue to work hard to ship all the features we need to provide the best experience for our incoming users.

The work is done!

We are looking to onboard customers this week and will be going live (pre-launch). We are still shipping, but the necessary work is done. If you are an AWS customer or planning to migrate to AWS, please send me a DM on Twitter or visit my about page to reach me.

I cannot wait to see the exciting things you will build on Clouddley, and I look forward to the bright times ahead. It’s just DAY ONE!

Nothing is impossible

— Oct 27, 2022