Thread by @_yoitsro

According to my commit log, it's been almost exactly 2 years since I started building @desanahq as we know it today. This is how it went down. A thread 👇

#startup #developers #nodejs #javascript #ios #android #nativeapps #kubernetes

@desanaHQ When we (@michaelcobyburn and @SteveInJeans) started, I was keen to build something which would "scale". I thought "if this does well, it's going to have to cope with the demand". We had no money and we all worked full time doing other things.

As if things weren't challenging enough, I thought I'd also take the opportunity to learn some new things. Enter @nodejs "microservices" on @kubernetesio on @googlecloud. Oh, and we had to launch in time for National Coworking Day (18th May) which gave me less than 5 months...

Kubernetes would definitely help with scaling, so why not?! Next thing, how do I structure the project in a "microservicey" way?

I did some reading and I decided to use the concept of internal microservices and public microservices. I was already familiar with @nodejs, so I stuck with that as my runtime.

Internal microservices: responsible for interacting with the databases and external services.

Public microservices: responsible for serving clients, business logic and interacting with the internal microservices.

Why this way? It meant I wouldn't have to rewrite database access logic for every public service which required data. I could centralise database access and that way, if we ever changed databases, we'd only ever need to update a subset of services.

The next thing: how do I get the public microservices to talk to the internal microservices? Remember I wanted to learn some new stuff? Why not add a service mesh in the form of @Linkerd into the mix?!

When I started learning about Linkerd and service meshes, @grpcio and Protocol Buffers kept on coming up. A strongly typed, efficient communication medium between the server and its clients. Sounds cool, but I don't need to learn that too.

Narrator: "He used gRPC too..."

The next thing: how do I run @mongodb and @elastic (stateful workloads) on Kubernetes where the principal is that a workload’s containers could be killed at any time? Simple: I leave that up to someone else and install @helmpack and use an existing stateful chart!

So, just to recap, I'm now dealing with @kubernetesio on @googlecloud running microservices written in @nodejs using @grpcio for inter-service communication and running @mongodb and @elastic deployed using open source @helmpack charts 🤯

Oh, and since I knew I was going to be writing a native iOS and Android apps (we'll cover more on this later), there was no reason why I couldn't use gRPC to communicate with the public microservices!

I've worked at a startup before where the focus was more on delivery and less on quality (totally my choice, by the way). I decided that if I was going to start something new, I was going to do it properly: unit tests with 100% code coverage and integration tests.

This meant I needed to set up a continuous integration/continuous delivery platform. We were already using Kubernetes, so it made sense to set up our own CI server on there. Note: it never makes sense to spin up your own CI...

After a couple of months of extremely hard work, it was time to start thinking about building the apps. Like I say, I chose to build native apps. Why?

My only real experience with hybrid apps was an Ionic app which used Angular 1. Performance was terrible. From what I understood, React Native apps had performance issues and some "native" functionality had to be compromised on. Not for me.

Thankfully, I had some friends who were willing to help out! Getting the native apps setup to use gRPC was actually pretty painless 🎉

I had to figure out how to get Linkerd setup to act as an ingress and eventually, I managed to find a configuration which worked well. Everything was all great until it wasn't. The server stopped responding to requests!

It turns out there was an issue in Linkerd (github.com/linkerd/linker…) where it gradually stopped routing traffic to the right places. A workaround: restart Linkerd every now and then... #turnitoffandonagain

Okay, 3 days to go and we're generally functional, the Android app is done and in the Google Play store. The iOS app is done but failed approval... because of the same issue #fml

I restart Linkerd and resubmit the app 🤞 It fails approval again, this time because the app required users to sign up before they could use it. Okay, fine, I've not slept properly in a few days but sure, I'll change some things so searching for spaces can be done anonymously...

I resubmit the app at 8.30am on 17th May, the day before National Coworking Day. Bearing in mind it takes around 24 hours for App Store approval to happen, this was make or break... 😱 I went to sleep that night and slept like a baby (because of sleep deprivation)

I wake up the next morning, the morning of National Coworking Day. SUCCESS! THE APP HAS BEEN APPROVED 🎉 The first booking comes in and we are elated! 5 months of hard work, late nights and a lot of learning have paid off!

National Coworking Day is a success, the day is over and I’m now at the party afterwards. Here’s a still taken from a video. As you can see, I’m in need of some self care…

Since then, we’ve reworked things, improved things, simplified things and we’re in a much more stable and sustainable place. We’ve raised funding, we’re working on @desanahq full time and we’re growing! Come and join us 👉 desana.io/careers/