Developer Burnout
Thanks again for subscribing to Cloud Musings! Last I checked, it was 50 subscribers strong on LinkedIn. If you haven't subscribed, subscribe to get automatic updates when I publish new editions!
This week, we connected with a number of investors who are excited about the B2B SaaS space like Forum Ventures and Northeastern’s Roux Institute Founder Residency program. I would love introductions to more investors and enterprise partners who are excited about the cloud and developer tools space.
I’ve talked a lot about what we’re working on at Oatfin, but not so much why. I thought I would take some time to talk about that. One of the reasons I started working on Oatfin is developer burnout. I personally experienced burnout many times and most of the times, it was preventable by simply equipping developers with better tools.
I’ve been a software engineer for 15 years. In my experience working at GE, Putnam Investments, Akamai, and many early stage startups, cloud infrastructure was a major challenge. The process is not only manual, but tedious and frustrating at times. If you’ve ever used the AWS or Google Cloud user interface, then you know this pain well.
For example, I was working at a fintech startup and one of my roles was to automate our cloud infrastructure. Sometimes it took days to deploy a simple app.
At the height of the pandemic, I was working at another healthcare startup, and it was a lot of the same frustrations. We moved from servers to server-less and then back to servers. Other challenges we faced were cloud spend, testing, security, compliance, and observability into the server-less apps. I left after 6 months to work on Oatfin because I believe the process should be simpler.
Some problems with the cloud currently:
Painfully slow development cycle.
Manual, tedious, and frustrating at times.
Days to weeks to build a secure cloud infrastructure.
Vendor lock-in means high cost.
Expert knowledge and skills.
If you look at the current workflow for developing a feature, it’s quite painful; write the code, regression test, build, push, and manually test the new artifacts which means a lot of downtime for users. At some companies, we only released code late at night when traffic was slow and depending on the release could last 12+ hours, but we still had to show up for work the next day because that fix we rushed through could cause further problems. For developers, this is one of the main causes of burnout.
There are 3 big tenets in our application: infrastructure automation, security, and compliance. Our focus is cloud native and Docker containers to start.
Why cloud native?
Containerization provides many benefits like porting to different clouds, different operating systems as well as being easier to scale. There is no doubts that more enterprise companies will take advantage of cloud native deployments as they continue to use the public cloud.
Currently, the app allows customers to define their containers from any public or private container registry. We automate the infrastructure so they can choose the type of infrastructure they want to create. Since we have the containers, we can also scan them to detect vulnerabilities and compliance.
There are many features that make us stand out:
Being able to clone an infrastructure to debug production issues.
Schedule a deployment and specifying dependencies that need to be deployed before.
Zero trust security and scanning containers for vulnerabilities.
Compliance automation.
Team collaboration.
Thanks for reading!
Jay