3 ms·

These are really helpful insights. Thank you. Position wise yes, high level newly-minted CTO-ish-type office sounds about right, sorry to be vague. Decision is

These are really helpful insights. Thank you. Position wise yes, high level newly-minted CTO-ish-type office sounds about right, sorry to be vague. Decision is made, implementation and vendor selection is the hard part. I have already moved many applications as proof of concept and the savings seen is one driver of this change, and me being the one that moved them is one reason I get to be involved/doing/advising/engineering this. We are not FAANG and not located in cool locales so harder to attract great talent. The cloud vendors are in fact already offering to take on a lot of this work of transitioning, which I am avoiding to avoid lock in at all costs. And for others reading it's not UPS/Fedex just to throw that out there, I saw another thread on UPS yesterday trying to move huge organization's ops to 21st century and was trying to think of examples of what I assumed were large legacy companies that are not core tech and those popped to mind. That thread also served as a catalyst as I'm also wrestling with moving a huge orgs ops to the 21st century. I have taken your advice on email: throwawayacct4q@gmail.com

CodeWriter23 8y ago
Of the apps you have already moved, are any of them in the range of poorly documented, duct taped together, you know, the nightmare apps that I’m sure you have there? Just to be sure you’ve established both ends of the costs-to-savings spectrum. It may be the most cost effective approach is to outsource some apps and keep others on premise.
mmt 8y ago
> Decision is made, implementation and vendor selection is the hard part. >The cloud vendors are in fact already offering to take on a lot of this work of transitioning, which I am avoiding to avoid lock in at all costs. This gives you a distinct advantage, in that you could, subsequently, move back and be your own "private cloud" vendor for even further cost savings. > We are not FAANG and not located in cool locales so harder to attract great talent. You may find that becomes less true as housing prices in cool locales continue to rise. Alternatively, you could open offices in those locales, since, if your infrastructure is going to be cloud-based (public, private, or hybrid), it's less important that the staff be co-located with it. There's also the notion of a remote-first engineering culture that I'm sure you can find plenty of evangelism for, just by searching.
exikyut 8y ago
Wow, I must admit that my original comment was written from the position of "now how would this kind of thing happen in real life" and involved a rather heavy-handed dose of armchair speculation. The various details I mentioned (CTO-type position; that the decision is made; that the vendors have offered to help) were all "well it would probably happen this way" postulations. Ha. (Did any lunches happen yet?) Vagueness is fine and important. Oh, and congrats on the newly-minted position :) TIL what FAANG is ("Facebook, Apple, Amazon, Netflix and Google"). I see. Well, maybe posting in the monthly "Who is hiring?" threads could be helpful. (Reading through previous hiring threads is probably the best way to get an idea of what+how to post: https://hn.algolia.com/?query="ask%20hn:%20who%20is%20hiring%3F"&type=story&sort=byPopularity https://hn.algolia.com/?query="ask%20hn:%20who%20is%20hiring...) Who is hiring? is all semi-anonymously done, of course; what goes into the post is rough location, perks, job focus (an interesting question), benefits, etc. (Heh, I'd just link to this thread in the "benefits" section - then applicants would know they were applying to somewhere that looks like it actually respects what puts the intelligence behind "artificial intelligence" :) there's not enough of that out there IIUC, see eg http://rachelbythebay.com/w/2018/04/17/company/ http://rachelbythebay.com/w/2018/04/17/company/). > The cloud vendors are in fact already offering to take on a lot of this work of transitioning, which I am avoiding to avoid lock in at all costs. Well, for what it's worth, it is a necessary step. a) you're switching sysadmin+ops+networking+infra teams, so the replacement team does kind of need to get an idea what they're up against; and b) there's a reasonable chance that your deployment will give $vendor a run for its money and require small bits of build-out (probably edge-case handling) to more smoothly support your use case(s). This was why I mentioned the analysis teams would be taking their insights back to HQ for debriefing (cue internal mad scramble :P), but didn't manage to articulate that in my previous post. Hmmmm, on that note, that gives me an idea: maybe port one or two of your craziest components - the ones that are the hardest to wield and integrate and _will_ have problems - to both vendors, and see what the customer support response is like. Ah, wait, that won't work, you won't be able to hide which account you're calling with problems about and the sales teams will make sure support pulls out all the stops. Of course once you actually sign up with a $vendor, you're a captive audience and will be subject to all the bureaucratic rainbow tape. Ah, so this is one motivation to sign up with both vendors: to avoid lockin so they still have to work hard for your business. So THAT'S why vendors work so hard for exclusivity. Hah! I suddenly understand a new reason why there's such a big reason to get vendor logos onto webpages, it's not just advertising for the vendor but because it almost certainly represents lockin - because it would be politically incorrect for a newly-cloud-ified company to say "we went with GCE and AWS!", wouldn't it? That makes it look like one provider isn't enough - when in reality, one vendor would probably provide all requirements, but once they're "it", they've got the contract and can stop working. (Something something psuedo-strawman argument...) Hmmm. So that's a bit of the risk balance: go with one vendor and risk lockin and being a captive customer, or go with both, get slightly shunned ("we don't want your logo on our webpage, and we don't want you putting our logo and $competitor's on yours") and have a bit more control because both vendors are competing. (So then the shunning would be mixed with wooing. That would be interesting to watch. Why am I imagining buying popcorn...) (This stream of consciousness approach was unintentional but I don't think I can express any better by refactoring the presentation) Hm, another thing I thought of: if your existing workforce is big enough (at least 50-100 people? {EDIT: oh, thousands, this would work amazingly then}) and everyone's fairly isolated/segregated, you could take advantage of the segregation by getting everyone {or maybe many} to explain their systems to everyone else {or many others} - maybe explain to multiple people with decreasing levels of familiarity. This would mostly be an exercise in "rubber duck debugging", with the decreasing levels of familiarity forcing people to articulate better. This approach kills two birds with one stone: not only does it mean people have properly articulated their systems (and found lots of little edge cases), at the end of such a venture, everyone would know a lot lot more about everyone else's stacks. This in turn would have two benefits, a) people would better understand what the components they manage are talking to, and b) overall agility would increase as 1) remote teams could take simple steps to fix remote fires and 2) devs would better empathise with what they were interacting with, which will produce a more cohesive system overall. Now I'll go reply in the thread where you explain current costs. Wonder if you've gotten any emails from anyone yet :) I'll try and follow up w/ a ping hopefully soonish (might take me longer than I'd prefer but it'll happen). (Also, the F5 key on my laptop is far too easy to hit... when this happens, I quickly open Chrome's task manager, SIGSTOP the renderer PID for the tab I'm in, gdb -p <pid>, generate-core-file, then grep my post back out. This is the 2nd time I've done this and it works absolutely great because HN uses <textarea>s :D. CTRL+W is harder and either requires a hasty drop into hibernation, or SIGSTOPping all the renderers then generating+grepping core files one at a time. Good luck if the ^W killed the renderer and the memory is now unallocated. Goes and installs form saver extension)

CodeWriter23 8y ago

Of the apps you have already moved, are any of them in the range of poorly documented, duct taped together, you know, the nightmare apps that I’m sure you have there? Just to be sure you’ve established both ends of the costs-to-savings spectrum. It may be the most cost effective approach is to outsource some apps and keep others on premise.

mmt 8y ago

> Decision is made, implementation and vendor selection is the hard part. >The cloud vendors are in fact already offering to take on a lot of this work of transitioning, which I am avoiding to avoid lock in at all costs. This gives you a distinct advantage, in that you could, subsequently, move back and be your own "private cloud" vendor for even further cost savings. > We are not FAANG and not located in cool locales so harder to attract great talent. You may find that becomes less true as housing prices in cool locales continue to rise. Alternatively, you could open offices in those locales, since, if your infrastructure is going to be cloud-based (public, private, or hybrid), it's less important that the staff be co-located with it. There's also the notion of a remote-first engineering culture that I'm sure you can find plenty of evangelism for, just by searching.

exikyut 8y ago

Wow, I must admit that my original comment was written from the position of "now how would this kind of thing happen in real life" and involved a rather heavy-handed dose of armchair speculation. The various details I mentioned (CTO-type position; that the decision is made; that the vendors have offered to help) were all "well it would probably happen this way" postulations. Ha. (Did any lunches happen yet?) Vagueness is fine and important. Oh, and congrats on the newly-minted position :) TIL what FAANG is ("Facebook, Apple, Amazon, Netflix and Google"). I see. Well, maybe posting in the monthly "Who is hiring?" threads could be helpful. (Reading through previous hiring threads is probably the best way to get an idea of what+how to post: https://hn.algolia.com/?query="ask%20hn:%20who%20is%20hiring%3F"&type=story&sort=byPopularity https://hn.algolia.com/?query="ask%20hn:%20who%20is%20hiring...) Who is hiring? is all semi-anonymously done, of course; what goes into the post is rough location, perks, job focus (an interesting question), benefits, etc. (Heh, I'd just link to this thread in the "benefits" section - then applicants would know they were applying to somewhere that looks like it actually respects what puts the intelligence behind "artificial intelligence" :) there's not enough of that out there IIUC, see eg http://rachelbythebay.com/w/2018/04/17/company/ http://rachelbythebay.com/w/2018/04/17/company/). > The cloud vendors are in fact already offering to take on a lot of this work of transitioning, which I am avoiding to avoid lock in at all costs. Well, for what it's worth, it is a necessary step. a) you're switching sysadmin+ops+networking+infra teams, so the replacement team does kind of need to get an idea what they're up against; and b) there's a reasonable chance that your deployment will give $vendor a run for its money and require small bits of build-out (probably edge-case handling) to more smoothly support your use case(s). This was why I mentioned the analysis teams would be taking their insights back to HQ for debriefing (cue internal mad scramble :P), but didn't manage to articulate that in my previous post. Hmmmm, on that note, that gives me an idea: maybe port one or two of your craziest components - the ones that are the hardest to wield and integrate and _will_ have problems - to both vendors, and see what the customer support response is like. Ah, wait, that won't work, you won't be able to hide which account you're calling with problems about and the sales teams will make sure support pulls out all the stops. Of course once you actually sign up with a $vendor, you're a captive audience and will be subject to all the bureaucratic rainbow tape. Ah, so this is one motivation to sign up with both vendors: to avoid lockin so they still have to work hard for your business. So THAT'S why vendors work so hard for exclusivity. Hah! I suddenly understand a new reason why there's such a big reason to get vendor logos onto webpages, it's not just advertising for the vendor but because it almost certainly represents lockin - because it would be politically incorrect for a newly-cloud-ified company to say "we went with GCE and AWS!", wouldn't it? That makes it look like one provider isn't enough - when in reality, one vendor would probably provide all requirements, but once they're "it", they've got the contract and can stop working. (Something something psuedo-strawman argument...) Hmmm. So that's a bit of the risk balance: go with one vendor and risk lockin and being a captive customer, or go with both, get slightly shunned ("we don't want your logo on our webpage, and we don't want you putting our logo and $competitor's on yours") and have a bit more control because both vendors are competing. (So then the shunning would be mixed with wooing. That would be interesting to watch. Why am I imagining buying popcorn...) (This stream of consciousness approach was unintentional but I don't think I can express any better by refactoring the presentation) Hm, another thing I thought of: if your existing workforce is big enough (at least 50-100 people? {EDIT: oh, thousands, this would work amazingly then}) and everyone's fairly isolated/segregated, you could take advantage of the segregation by getting everyone {or maybe many} to explain their systems to everyone else {or many others} - maybe explain to multiple people with decreasing levels of familiarity. This would mostly be an exercise in "rubber duck debugging", with the decreasing levels of familiarity forcing people to articulate better. This approach kills two birds with one stone: not only does it mean people have properly articulated their systems (and found lots of little edge cases), at the end of such a venture, everyone would know a lot lot more about everyone else's stacks. This in turn would have two benefits, a) people would better understand what the components they manage are talking to, and b) overall agility would increase as 1) remote teams could take simple steps to fix remote fires and 2) devs would better empathise with what they were interacting with, which will produce a more cohesive system overall. Now I'll go reply in the thread where you explain current costs. Wonder if you've gotten any emails from anyone yet :) I'll try and follow up w/ a ping hopefully soonish (might take me longer than I'd prefer but it'll happen). (Also, the F5 key on my laptop is far too easy to hit... when this happens, I quickly open Chrome's task manager, SIGSTOP the renderer PID for the tab I'm in, gdb -p <pid>, generate-core-file, then grep my post back out. This is the 2nd time I've done this and it works absolutely great because HN uses <textarea>s :D. CTRL+W is harder and either requires a hasty drop into hibernation, or SIGSTOPping all the renderers then generating+grepping core files one at a time. Good luck if the ^W killed the renderer and the memory is now unallocated. Goes and installs form saver extension)