MattRogish

For a B2B SaaS company, the easiest/most likely[1] algorithm to succeed[2]:

1) Be embedded in the industry for a while

2) Make lots of connections, build credibility

3) Build SaaS app to solve key pain point you experienced in #1

4) Sell to the folks you know from #2

5) For bonus points/de-risking: find 25 potential customers (from #2) and reach out to them and validate this idea (Jobs-to-be-Done). Get a handful of them to commit, even verbally, to buy this when you've got an MVP built.

[1] Clearly this is not the only way to be successful, but "I have a random idea lemme build it" is a great way to be not successful

[2] Succeed = your business that makes enough revenue to support you and a reasonable lifestyle, equating (and/or eventually surpassing) what you would typically make at a W2 gig, from a diversity of customers and not trading your personal time for money.

Dang, somehow I missed that. Rawk!

What is interesting is the DB cleaner gem actually does check for `RAILS_ENV=production` and a `DATABASE_URL` that is remote:

https://github.com/DatabaseCleaner/database_cleaner#safeguar...

It's possible they disabled the localhost check at some point.

Edit: It does now, after Travis folk fixed it. :D

And, Rails (which I assume they're using) typically loads DB credentials from a `database.yml` file for a particular `RAILS_ENV` (local dev, local automated testing, prod). By setting the `DATABASE_URL` env var, they are overriding that (this is fine/expected behavior for app deployment as far as Rails is concerned; it's comparatively less common for localdev). So that bypassed the `RAILS_ENV=prod` check that might also have caught this (e.g. `RAILS_ENV` was undefined or `development`).

So I'd really have loved it if they dug into some of the UX factors to this issue:

* Why do they allow remote access to their production database? (Is it too hard to get a local database copy? "For debugging purposes"? Why was the eng in prod the day before? Was it unintentional? Should we revisit those assumptions? Should we resolve whatever issue that caused us to shortcut by allowing remote, direct prod db access?)

̶ ̶W̶h̶y̶ ̶D̶B̶ ̶c̶l̶e̶a̶n̶e̶r̶ ̶a̶l̶l̶o̶w̶e̶d̶ ̶n̶o̶n̶-̶l̶o̶c̶a̶l̶ ̶(̶o̶l̶d̶e̶r̶ ̶v̶e̶r̶s̶i̶o̶n̶?̶ ̶m̶i̶s̶c̶o̶n̶f̶i̶g̶u̶r̶e̶d̶?̶ ̶e̶t̶c̶.̶)̶

Why, for localdev, they override database.yml and use env vars (which I've found is more cumbersome to use and not as common). Yeah, in production you should use RAILS_ENV/DATABASE_URL/etc. - so are they attempting to have prod parity? Why or why not?

* Why are folks routinely logging in (for debugging purposes) with a DB user that is, effectively, root? I bet that user can `drop table` too. Should folks have a limited access account and then jump through a hoop or two for root?

It sounds like they want to "debug" prod by running some local rails tools (rails c?) with DATABASE_URL set to the prod db. Is that the "best" way to do it? heroku etc. actually open a rails console in the environment and not locally.

Hi Michael,

Although we strive to hire everyone who reaches the final stages (it's super time consuming for everyone, you and the team!), ultimately we have to turn away people who are awesome but aren't a perfect fit (at our teeny-tiny size back in [time redacted] when you interviewed, we were even pickier than we are now; I wouldn't read too much into our decision to not move forward).

We've made a lot of changes in our process since you spoke with us and I hope we're more communicative - to the best of our ability - in our process. I wish you the best of luck in your future endeavors!

-- Matt

Hi,

I'm sorry you felt your time was wasted; we do not aim to do that at any point in the process (it wastes our time, too! :D). We are a kubernetes consulting and DevOps-as-a-Service shop, and some amount of our demand's final materialization is unpredictable. We take pains to mention that in the beginning but, if we didn't, that's on us and I'll make sure we don't miss that again - thank you for bringing that to my attention.

I don't know your situation, but it's highly likely we had a significant influx of demand that suddenly softened, and we had to back-off on the hiring. Or, perhaps also likely, we hired someone that more closely matched the position and needed to pause the search (we have 3 people starting on Monday, Feb 5, for example; we've hit our quota of less experienced Kube experts and have re-focused on people with extensive cloud production kube experience).

As a profitable but bootstrapped firm that has (yet!) to lay off people due to underwork, we strongly bias against pre-emptive hiring.

I wish you the best of luck in your career, and if you are still looking, in your search.

-- Matt

Hi! Thank you for your question!

Due to $reasons, we can only accept applications from folks that currently possess a right to work in the United States (e.g. https://www.thebalance.com/how-to-get-a-permit-to-work-in-th...)

https://www.ReactiveOps.com | Sr Site Reliability Engineer (AWS/GKE Kubernetes) | Full-Time; 155-160k DoE; 0.01% equity | Remote, Right-to-work-in USA

ReactiveOps is a DevOps consulting and services company, focused on AWS/GKE. We setup, maintain, and operate Kubernetes clusters for our clients, setup CI/CD, migrate their apps into Kube, etc., in addition to day-to-day cloudOps works. We are in Slack with them and act like their "outsourced, in-house Ops team". Our goal is to exceed the capabilities and care of an in-house Ops organization. We are a completely distributed team of 16 highly motivated folks, and are 100% bootstrapped and profitable.

We're looking for AWS/GKE operators to join our growing team! You can see more details and how to apply here: http://pages.reactiveops.com/careers/site-reliability-engine...

https://www.ReactiveOps.com | Jr-Mid-Sr Site Reliability Engineer (AWS/GKE Kubernetes) | Full-Time; $90-160k DoE; 0.01-0.1% equity | Remote, Right-to-work-in USA

ReactiveOps is a DevOps consulting and services company, focused on AWS/GKE. We setup, maintain, and operate Kubernetes clusters for our clients, setup CI/CD, migrate their apps into Kube, etc., in addition to day-to-day cloudOps works. We are in Slack with them and act like their "outsourced, in-house Ops team". Our goal is to exceed the capabilities and care of an in-house Ops organization.

We are a completely distributed team of 16 highly motivated folks, and are 100% bootstrapped and profitable.

We're looking for AWS/GKE operators to join our growing team! You can see more details and how to apply here: http://pages.reactiveops.com/careers/site-reliability-engine...

EKS is likely to be in preview/beta for most if not all of next year. Even after it exits preview, you'd probably want someone else to kick the production tires. Given how Kube on EC2 is doable/manageable (that's what we do) I don't see a reason to stop. If Kube is the right choice for you now, it's the right choice on EC2, and once EKS becomes a thing you can migrate to, you can just do it.

We (ReactiveOps) use a combination of CircleCI and some scripts wrapping kubectl https://github.com/reactiveops/rok8s-scripts

We (https://www.ReactiveOps.com) run a lot of clusters for our clients in AWS (and also GKE, but..) using kops. It's definitely possible to run a lot of clusters, but kops is only one piece of the puzzle. Autoscaling, self-healing, monitoring and alerting, cluster logging, etc. is all other things you have to deal with, which are non-trivial (they scale workload per cluster, so...)

We open sourced our kube generator code, called pentagon, which uses kops, terraform https://github.com/reactiveops/pentagon

I was talking with a friend about this, that works at a big SV company that is known for high comp. Why don't they have a child care facility? Surely they can afford it!

His response was - paraphrasing - "What happens if someone quits, or is fired? In SV/SF, waits for child care facilities can easily take 6-12 months. If someone is terminated from our company, the last thing we want for them to do is have a crisis about where their children are going to go."

I believe they have a stipend, but I'm not sure about that.

Of course, I can't say if this is Apple's rationale, but it wouldn't surprise me if that had something to do with it.

Building this stuff by hand is... yeah.

We open source our Kube bootstrap toolkit (which uses kops). No one should build this by hand. It would be like, I dunno, setting up a MariaDB Galera Cluster by hand when you intend to use RDS (not a perfect example, please no pedantry!). It's a fun learning experience, I guess - if you're into that sorta thing - but is not what you want to use in any production context.

https://www.reactiveops.com/blog/kops-102-an-inside-look-at-...

https://www.reactiveops.com/blog/using-k8s-scripts/

Use the automation to bootup clusters, please!

SEEKING WORK (REMOTE) - DEVOPS (KUBERNETES, AWS/GKE AUTOMATION) CONSULTING

We're a team of 7 engineers at Reactiveops.com that do AWS/GCP automation centered around building your own PaaS with Kubernetes. We also do "DevOps-as-a-Service" where we maintain that PaaS for you and do additional stuff on a monthly basis (we're in your slack, working 1-1 with your eng, etc.).

We've worked with companies like Boxed, Betterment, Node.io, etc. and can work with small startups to bigger companies. And, we open source all of our code so there's no lock-in for the stuff we make (based on kops, ansible, terraform - e.g. https://www.reactiveops.com/blog/using-k8s-scripts/ and https://www.reactiveops.com/blog/kops-102-an-inside-look-at-...)

Feel free to email me at matt [at] reactive ops dot com or call me 917 336-3943 for more info!

We (ReactiveOps.com) use kops: https://github.com/kubernetes/kops

It works well with Ubuntu and we are working on CoreOS (although no promises it gets merged back into core).

Kops can do upgrades although historically it was safer/easier to stand up another cluster alongside and migrate.

Happy to help if you have any questions - Matt [at] reactiveops.com.

Well, yeah. That's why they bought Joyent.

We have 2 people on rotation and anything like this you pair with someone else and talk through it. As we like to say "It's only a mistake if we both make it."

Modern jetliners have batteries in case of engine or generator failure (you can buy a 767 battery here for about $11,000[0] http://www.skygeek.com/saft-018550-000-nicad-battery.html). And, of course, to start the plane should you not have any ground power.

Of course, they don't power much - typically a few backup instruments and the APU starter - so the RAT[1] is used to power certain hydraulics/instruments so that the pilots can maintain control.

[0]Why is the battery $11,000? Well, it has to undergo a lot of testing and contain thermal runaway. See the problems with the 787's new Lithium Ion battery https://en.wikipedia.org/wiki/Boeing_787_Dreamliner_battery_...

[1]For fun, here's a test flight that shows the 787 RAT deployed: https://i.stack.imgur.com/xYQPP.jpg

"Available with 128GB DIMMs. Expected availability late 2015"

Typo or haven't updated the site since last year?

Disclaimer: I founded a DevOps (now Kubernetes) consulting company.

We, up until recently, had our own (closed source) ansible/terraform/packer immutable AWS-based PaaS sort of thing. We abandoned it in July when Kubernetes hit 1.0.

It's not just if Flynn and Convox and other VC-powered startups whomever can even exist another couple of years - but whether they exist and if they can out-compete Docker and CoreOS and Kubernetes and... etc.

My feeling is that a lot of infrastructure companies died in July. Just like Blackberry after the iPhone - gradually, and sometime in the future, suddenly.

What's the future for these PaaS companies? I dunno. Consulting services? Managed PaaS? These are fine, but... have a finite growth curve. Not everyone wants or needs to be a unicorn - for sure - but if you're tying your SaaS or web business to someone's infrastructure code, you kinda want:

a) the thing everyone else is doing (so you can grow your own team eventually - it's easier to hire a kube developer than a eg. flynn dev)

b) something that will be around for a long time and

c) something that has the best blend of features/power/ergonomics (Kubernetes has almost 1,000 contributors. Flynn: 98. Convox: 52. Bigger isn't always better, but...)

For us, that's kube. We're still iterating on our our business model - perhaps we just stay as a kube consulting shop for a good while - but running an Open Source PaaS business is not where we think the puck is heading.

Another company that does this - very little marketing - is https://www.replicated.com . I don't get paid for recommending them but they do great work (some of our clients are theirs etc).

This is exactly it. When you're recruited (and you're always recruited - it's super rare to have a C-level position open on the website and submit a resume to) to a firm as an exec you have (generally) tremendous leeway to negotiate your own contract, exit criteria, etc.

Yes, the board provides a starting point, but it's much more collaborative negotiation - and you (as the incoming exec) are gonna negotiate based on the criteria I mentioned. It's not at all like an IC where you basically get a "take it or leave it, plus a few % more on salary if you push back" offer. It's a different universe.

Is it fair? I dunno. The "intrinsic value" argument doesn't really apply - the CEO is worth $10M/yr if the board thinks they are.

A general case CEO/exec job is far, far riskier than a IC software developer. If you're a fantastic (heck, halfway decent) developer, you can be fired, laid-off, or simply quit and find a new job relatively quickly. And yes, you're generally paid a lot of money (compared to the rest of America).

As an executive in a general case (sure, we can all find outliers) company, there are comparatively far fewer jobs for you to go to. If you fail, you fail spectacularly/publicly and may not be employable for years. The high compensation is in exchange for the risk of the job and the low probability of finding a new one.

Semi-related (not what you said - of course): "I deliver $1M in value to the company so I should be paid $1m" is a thing I see every now and again. That's not even remotely how any of this works.

Having lived in NYC pre-and-post Uber, the difference in Manhattan traffic is astonishing.

Manhattan 2006: http://www.shutterstock.com/video/clip-2475317-stock-footage...

Manhattan now(ish): http://cdn.newsday.com/polopoly_fs/1.12078243.1469201706!/ht...

If you were to teleport a Manhattanite from 2006 to 2016 I think they'd be shocked to see the large number of non-yellow cabs on NYC streets.

Regardless of how you feel about Uber-the-entity, the mark it's made on NYC streets is undeniable.

We start from kops, but tweak it. Kops is great, except it's not integrated into the rest of your VPC etc. as 'old-gregg' suggests.

Or you could hire us, too. We do consulting/kube-as-a-service for folks in AWS/GKE :D (https://www.reactiveops.com).

We've been deploying Kubernetes for clients since, well, 1.0 (very recently) and have nothing but great things to say about it. If you want something approximating a Heroku-like experience but in your own environment (AWS, GKE, or even on-prem) K8s is a super awesome way to get there. Sure, like anything it's got some rough edges that you'll get cut on, but it improves every 3 months. :D

Big kudos to the k8ts team at Goog, and all the other contributors!

I have over 500,000 BIS lifetime miles and I'm still exited by the takeoff roll. Airlines are starting to retire 744s. If you have a chance, find a way to ride in the upper deck. It's quite something!

For small businesses, Apple's joint venture is great. Drop your Mac off and get a loaner. http://www.macworld.com/article/1158330/computers/joint-vent...

We use it. Super simple to get setup.

My quote is "everyone leaves Heroku eventually". Either you hit something that Heroku won't let you do (because of their tightly bound model) or you are burning tens of thousands a month on what would cost 20% on AWS/GKE, and you do it for cost savings (people are nontrivially expensive, of course)/ownership.

Everyone leaves Heroku eventually. :D

https://www.getcloak.com - works on my Mac and various iOS devices. Well designed, have been with them since the beginning with no issues.