So, what have I learnt after building @desanahq for 2 years?
Start simple, start small. Kubernetes is not necessary. Microservices are not necessary. gRPC is not necessary. Self-hosted CI is not necessary. Self-hosted databases are not necessary. The requirement to scale does not occur overnight. These things can wait.
Kubernetes is incredibly powerful and has a lot of potential. With a basic setup, it’s almost definitely more powerful (and more costly) than you need it to be when running simple applications. If you don’t need it, use the likes of @heroku etc or a @goserverless platform.
We’re now at a point where Kubernetes makes sense. It helps us scale as we need to and I actually know what I’m doing with it now...
Unit tests with 100% code coverage is excessive and restrictive. Test the bits of logic which you know are complex and which you know will cause you a potential headache in the future.
Integration tests are probably a better way to go. It’s the much more efficient equivalent of the old skool way of “testing”, where you change something, refresh the page and hope to see what you expect 🤷♂️
Microservices are fine, but they don’t necessarily provide resilience. An argument for using microservices is that if one service goes down, the rest of the app is still fine. Chances are, your databases will bail before your application code does, in which case, it’s game over.
gRPC/Protocol Buffers are amazing! Since it generates the stubs for most common languages, if you change your definitions, as long as you ensure those definitions are consumed by the clients, simple errors can be caught at compile time 🎉
Unless you have a small army of developers with lots of teams needing access to the same data in a normalised way, my concept of internal microservices is incredibly pointless 🙃
A better way to share common data access logic is to use something like a @lernajs monorepo. We now use the concept of repo packages (for data access), service packages (for business logic) and API packages (for public consumption of our services).
If you use Javascript, use @typescript. It plays well with @grpcio. It also reduces the mental capacity required when working within a monorepo i.e. needing to know the parameters of particular function from a different package.
Just because you want to learn loads of new things doesn’t mean other people on your team will. You’re either going to have to do a lot of hand holding or you’ll have to explain concepts you yourself haven’t fully understood.
Don’t underestimate how long things out of your control will take i.e. App Store reviews. This almost caught us out meaning we’d have nothing for iOS users to use for National Coworking Day.
Don’t neglect sleep. Without sleep, you can’t function, you can’t communicate, you can’t survive 💤
Don’t forget to appreciate those who have to put up with you day in, day out 🥰 They’re the ones who have to listen to your inane ramblings and deal with your grumpiness when things aren’t working!
Your product will pivot. That’s okay. Customers won’t come instantly. That’s okay. Trust your team. Stay positive, keep your head up and don’t be afraid of uncertainty ✌️
Hiring is difficult. Make it easier for me? :) desana.io/careers
