Hi everyone! I am Sam the CEO and Co-Founder of Plural. I’ve been in open source for over a decade. I spent 4 years at Red Hat before spending the next 6 years building products at MongoDB. Most recently I was the Head of Product at Unqork where we saw how difficult it was to create a deployment for our app stack and its related services. My Co-Founder Michael Guarino and I are building an open-source platform that simplifies deploying third-party applications on Kubernetes. Michael and I would love to answer any questions or hear any feedback you’ll have regarding our project. We'll do our best to reply to all of them below. Thanks!
Not OP, but I've been doing it for a few years. Can't say I've ever seen an issue - with Prometheus Operator, which the article mentions, as few times as well
I've seen cases where we started off as simply as possible with no k8's. We built the initial product really quickly using a ton of managed services. Whilst it was great to get us going, once we hit "growth" things just didn't scale. (1) The cost of cloud was getting astronomical for us (and growing with each new deployment) and (2) it was totally inflexible (whether that be wanting to deploy in a different cloud, or extend the platform's featureset) because we didn't own the underlying service.
We ended up porting everything to k8's. That was a long & arduous process but it gave us total flexibility at significant cost savings. The benefits were great, but not everyone has access to the engineers/skillset needed to be successful with k8's.
That's why we built Plural.sh – it takes the hard work out of k8's deployments. I've seen people go from zero to a full production deployment of a datastack on k8's in just 2 weeks. It deploys in your cloud, and you own the underlying infra and conf so you have total control of it. And because we believe in being open, you can eject your stack out of plural if you don't like it and keep everything running.
I think it's funny that everyone uses/loves k8s ends up building a product to make it easier to use. There are a lot of examples in the comments here. To me, that's enough of a red flag that k8s doesn't understand their users or can't meet them where they're at.
> We ended up porting everything to k8's. That was a long & arduous process but it gave us total flexibility at significant cost savings. The benefits were great, but not everyone has access to the engineers/skillset needed to be successful with k8's.
I think the argument from most people advocating against using k8s from the get go isn't so much that you'll never need it, but more that it's better to pay this cost later when you have a demonstrated problem that needs to be solved, even if it's a bit more expensive (and I would bet that the total time expenditure isn't really all that much more moving to k8s later, it's just in one chunk instead of spread over your history).
By deferring the cost of building more complex infrastructure:
- You can use those resources to advance your product (arguably some companies that have hit a wall with PaaS vendors may never have gotten to the point where they outgrew those vendors if they spent more of their time on infrastructure vs. company value)
- You'll have a better idea of what you'll need and where your scaling hotspots are going to be if you've already encountered them. Building infrastructure that allows for flexibility in a few key areas is infinitely easier than building infrastructure that can scale in every way imaginable.
- You can potentially take advantage of new technologies if you defer the decision to when you need it. It would be silly to assume k8s is the final word. If you wait a few years, things will have evolved and you gain the advantage of using those few years of advancement rather than cementing a choice early on.
Had the same exact experience! Just posted a comment. I think could companies have done a good job marketing how cheap it is to get started on cloud. Once things scale, the bills change and it's no longer as cheap to use managed infra.
The night and day difference is hard to explain when people haven't had to deal with all these issues on top of scaling, uptime, performance issues etc. I just can't recommend k8s enough
I would say I would -never- base a hiring decision on someone who was poor at answering a market sizing or logic question. However, I do like to see candidates with determination to try and answer, explore multiple possible answers, and remain cool during their reasoning. To me, it’s reflective of your working style and PM’s must remain calm, rational, constantly thinking of all possible options to solve a working challenge.
But is there data to support that these questions are effective in finding the types of people that you want? Without concrete and consistent answers to questions, you'll be exposing yourself to bias (subconsciously encouraging people like yourself or seeing their vague answers in a more positive light). You'll also make more of the interviewing experience dependent on what you happen to think of and the mood you're in at the time, increasing the inconsistency of your interviews.
I know the intuitive idea is that you'll get to see how the candidate reacts, but that can be done in a less arbitrary way (and in a job-dependent context) through behavioral interviews and the like. Brain teasers are also often poor candidate experience, since they can feel unfair and unrelated to the work. If estimation is a key feature for PMs, it should be part of the interview process with well-defined procedures.
