Hacking SaaS #14 - Back to Basics
Taking a break from the papers and deep dives. Lets took at simple architectures, must-have SaaS features and a whole lotta webhooks!
Our community had quite a few Slack conversations asking “What does SaaS really mean?”. As far as a business model goes, we landed at (mostly) B2B software that is running on someone else’s computer with someone else losing sleep over all things production - from deployments through on-call to “why is AWS charging me 30% more this month”?
So when someone over at Hacker News asked about the “Main things to consider when building an app for business/enterprise?”, I figured y’all would be interested in the answer. The top answer is pretty darn good and covers many of the recurring themes in this community - including the community-favorite OWASP top-10.
I was heading tech and product of a SAAS software for ~15 months so writing this from that experience.
Who is the buyer? Typically they are not same as the user of the product so understand what they look for in similar products.
SSO, preferably SAML based.
As for security, take care of OWASP top-10 and you should be covered for app-sec.
Implement RBAC. Make it easy to add/manage users for an admin-user.
Setup a demo account in sandbox, fill it with data as close to real world as possible. Makes it super easy during sale pitch. You let your product talk instead of you.
Consider multi-tenancy from right off the bat. It's hard to add it later.
Look up your domain specific compliance requirements and build those from ground up. Some such as SOC 2 don't hurt. While at it, get a decent security vendor to pen-test your product, work with them to fix high/medium priority issues and get them to issue certificate. It builds credibility with customers.
Reports. Typically the admins will require a bunch of reports. It's best to give them a CSV/Excel download and let them slice and dice in their spread sheet software.
Users will make mistakes so always use soft-delete. You can always do hard-delete after a few months.
Read the entire conversation for more insights and the occasional, inevitable, “Well, actually…”
Surprisingly not on the list, hopefully because it is too basic to mention, is monitoring. One of the key differences between the SaaS delivery model and the “download and install” model is that as a SaaS vendor, you monitor your software. In the old-school model, the customer needs to monitor the software.
Monitoring is absolutely essential for everything you deploy to production, but too often it is neglected until after the feature is in production, or even after the first time the customer calls you to say “Hey, do you know your service is down?” Design docs rarely include a section on “how to monitor this thing”, conversations about “which OSS project to depend on” rarely includes discussion of monitoring, shipping timelines rarely include time to implement and test the monitors.
No wonder we are all growing in Monitoring Debt! My friend Jean Yang, CEO of Akita, coined this term. And I honestly don’t know how we lived without it until now.
In some ways, monitoring debt is analogous to tech debt: teams can choose to underinvest in monitoring at the time of shipping code at the cost of having to go back and invest in monitoring later . . . .
The costs of monitoring debt are even more insidious. When a team chooses to ship code without thorough monitoring, here are the the immediate costs:
The team needs to accept limited ability to catch issues ahead of customers . . . .
The team has chosen to give up at least partial ability to quickly localize issues when they arise, meaning they are less likely to be able to fix issues quickly . . . .
If you are at all into Serverless, Ready Set Cloud is a great newsletter / blog to follow. It is always on-point and fun to read. If you are not yet into Serverless, but you are considering this architecture for the future, this blog post on Risks of Moving Too Quickly with Serverless is fantastic. The risks it highlights are relevant every time you pick a new and trendy architecture, and the advice on mitigating the risks is basic in the best possible use of the word.
Keep References As References - A reference architecture is intended to be just that…. a reference. They often are proof of concepts that were not designed for production use. When designing the architecture for your product you must keep the big picture in mind. Each component is a piece of a puzzle and you need to know what every side looks like for them to fit together properly. As you build your application, automatically generating your infrastructure diagrams is a great way to compare the plan and the actual implementation. Use this to monitor how you’ve steered away from the plan and course correct if necessary.
This is great advice that literally everyone should play attention to. I need an entire newsletter just to rant about the plague of reference architectures. Meanwhile, just read all his advice.
Seven basic things you can do now to greatly simplify SOC2 down the road. I’d paste a highlight here, but the first few paragraphs of the blog just list all seven things and they are not complicated. If you are building a SaaS product and don’t have SOC2 yet, just go read it.
If you have a SaaS product I’d love to see in the comments below (or in Slack) whether you got SOC2 yet, how many of those you got and how important these things really are.
In the past, I’ve been part of many “Events vs REST API” debates. Little did I know that there is an entire other debate on `/events` REST endpoint vs Webhooks (also REST). Did you know that Microservices need a Webhook Gateway?
But before you jump in to implement them, you may want to read this rather old article on lessons learned while implementing them, and browse the definitive list of every best practice you need when implementing webhooks. If this did not scare you away from webhooks yet, you should definitely read Give Me /events, not Webhooks.
The latter is funny to me because my product has `/events` and I really wish we had webhooks! I believe we’ll end up with both, since they each perform well in different situations - Serverless / FaaS lends itself to Webhooks, apps that need to deal with various network security and deployment concerns will benefit from `/events`, and everyone who uses either API will easily get it to 95% reliability and performance - and struggle with getting to 99.999%.
If you are implementing a very reliable events API, you may be using Kafka, which means you have to be very aware of its reliability guarantees. A lot was written and said about it, but that’s the thing about basics - you always need to come back to them.
And on a related topic, Santona Tuli was a guest on our channel and talked about the unified theory of batch and stream processing: