Entrywan turns 1: Happy Birthday!
2024-07-31
It’s hard to believe an entire year has passed since we started this little project. Starting any kind of company is hard–this one is certainly no exception–so it’s worthwhile to reflect on and be a bit proud of what we’ve built and the customers we’ve been able to serve.
Image credit: Romain Gle
When we started out, some believed a public cloud couldn’t be launched by a small team of dedicated hackers without some serious corporate backing. Whether it’s long lead times for certain types of equipment or a shortage of IPv4 addresses, there must be some insurmountable hurdle, right?
I’d like to share a few insights into our journal so far and some lessons learned.
One secret that’s helped us enormously was the decision to self-host all of our own services and tools–everything from this website you’re reading now to our company chat and videoconferencing are hosted on our own equipment. In addition, all of the tooling needed to build and ship our products is self-hosted too–after all, hosting our source code or build infrastructure on a competitor’s systems seems wrong, but not doing so also provides comfort to customers that we don’t have any dependencies on their other cloud providers, a crucial element of redundancy.
“Eating our own dogfood” has forced us to improve our services to our own standards. One example is virtual machine instance creation, something we’ve engineered to take around 2 seconds (compared to many platforms where it can take 30 seconds or even longer). Now that many of our other products are based on these instances, it means they benefit from the same turn-up speed and that our testing and deployment pipelines can be executed very quickly.
A second secret has been to double down on remote work and ensure full vision and autonomy to all. While many companies are issuing return-to-office mandates and finding ways to track and monitor their staff, we’ve taken the exact opposite route–we’ve embraced our remote culture and learned to benefit from it. As a result, we’ve been able to work with the brightest, most dedicated and most experienced people on the planet.
We’ve made plenty of mistakes too.
We shipped the first version of our instance snapshot product too early. Unlike a full backup, a snapshot is only stored on the same physical machine, limiting its usefulness in the event of serious failure. Second, by not requiring a full shutdown before making a snapshot, it’s hard to guarantee that restoring an instance from a prior snapshot won’t result in consistency issues. We plan on releasing a full backup solution for virtual machine instances with backups stored on our object storage platform, guaranteeing at least three physical copies of the backup are stored.
Second, we took too long to start marketing and participating in community events. It took us several months to even publish our first blog post. If you’re thinking about starting a company, do that even before you start working on your first product!
Thanks to everyone who’s supported us over the past year. We’re looking forward to many more!