Hacker News new | past | comments | ask | show | jobs | submit login

One is welcome to use staff that cost $20k per month (e.g. DevOps engineers who understand those four technologies well enough to use them in production) to shave ~50% off one's AWS bill, but one needs minimally two to three of them, so your friendly neighborhood insurance company should probably pay their $15k or whatever a month without blinking.



In many (perhaps most) areas of the US, DevOps staff do not cost $20k per month. For example, 92% of Boston rates are less than half that[1].

This implies that a $40k per month bill for AWS[2] could pay for three DevOps engineers and save approximately $10k per month in the vast majority of the US.

1 - http://www.indeed.com/q-Devops-Engineer-l-Boston,-MA-jobs.ht...

2 - derived from your statement that a staff of $20k per month would save "~50% off one's AWS bill"


Not to quible, but fully loaded costs and salary costs can be dramatically different.


Quite true regarding company (fully loaded) costs.

IMHO, a reasonable estimation for fully loaded cost per employee (excluding facilities expendetures) is approximately 1.4 * ES, where "ES" is the employee salary.

The "three DevOps engineers and save $10k" estimation was based on working backward from the 92% of available jobs in Boston being less than half of the stated $20k per month cost. Assuming a Gaussian distribution where 0.5 * $20k per month represents the high end of two standard deviations (since Boston ranks quite highly in S/W salary nationally), most DevOps engineers will be paid roughly half of that as well.

This yielded an estimation of $6.5k per month per DevOps employee or $19.5k per month for three.

Since all of this was off-the-cuff, I figured it best to throw in a bit of "fudge factor" and present a $10k per month savings.

As always, YMMV and I could be completely wrong about all of this :-).


It's not that hard, and if you are so huge that your devops takes a team you have a good problem. If you are a startup then architect your software so it can be scaled but otherwise just stick it somewhere and worry about product market fit. You can decompose and refactor and distribute once your product has enough users for it to matter.

A lot of the difficulty also comes from over engineering and premature scalability obsession. You often just don't need all that. I swear over engineering is the bane of software and devops these days. We've gone from java factoryfactorysingletons to "how many distributed systems fads can I use in one stack?"




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: