"To bring Octopus Cloud to market quickly, we did the simplest thing possible; we took our self-hosted Octopus Server product and bundled it into an EC2 instance for each customer that signed up. We had to make changes to the product, but mostly around permissions."
I have used octopus and I could have told them that they can't lift-and-shift. The amount of requests the app makes is ridiculous, the way they wrote their database is appalling (actually crazily dumb https://octopus.com/blog/sql-as-document-store). Everything about it would mean they can't scale in the cloud without wasting a ton of money.
"Cloud stuff can be really expensive" - yes if you write dog shit, putting that in the cloud will be expensive.
Why didn't they just make 1 table with 1 column and put a JSON object in it with all customer data? This would fit their design objective "Avoid the need for joins as much as possible"! It's brilliant! We'll call it: noSQL, because we don't even have to write that pesky SQL!
Can't wait for the next blog post where they discover another naughty trick called primary keys to increase their NoSQL performance even more!
because they didn't know what they were doing - I can say this as this is what the blog shows, they don't understand databases and customers (including me) have suffered this
I've learned much too late in my career that competent software engineering is completely orthogonal to creating a successful(from a market perspective) software product.
> Why would you bother with a relational database at that point? That sounds like it’s not normalized.
It's non-1NF, though they sometimes (based on expected cardinality) normalize that aspect via a trigger, using the application-accessed table as, in effect, something of a write-through denormalized materialized view. It's not an entirely unreasonablev way to use an RDBMS in and of itself.
It’s much better now since SQL Server 2017 added a new string split function. But I actually had to do basically the same thing in an earlier version of SQL Server (in my case, it was because I was interacting with a legacy application that spits out pipe-delimited strings) and the string parsing increased the execution time by several orders of magnitude.
ACID guarantees have nothing to do with relational vs non-relational. FoundationDB is one example of a non-relational key value store that none the less provides ACID guarantees.
The best part is the "simplest thing possible". They actually didn't do that at all. I hate to dog-pile on this team, but damn, 100k spend in a month isn't simple at all!
While I agree with you that it seems like they make some serious engineering mistakes, it was a successful MVP in that it told there there was sufficient demand to justify a rewrite for the cloud.
I have used octopus and I could have told them that they can't lift-and-shift. The amount of requests the app makes is ridiculous, the way they wrote their database is appalling (actually crazily dumb https://octopus.com/blog/sql-as-document-store). Everything about it would mean they can't scale in the cloud without wasting a ton of money.
"Cloud stuff can be really expensive" - yes if you write dog shit, putting that in the cloud will be expensive.