Ask HN: If I Close My Data Centers, What About the People/Jobs Lost?

https://news.ycombinator.com/item?id=17329028

181 136 8 years ago

news.ycombinator.com

(throwaway account)

I have a chance to basically migrate 90% of my F50's data centers to commercial providers. The cost savings are awesome, but what about the people currently doing legacy stuff? theyre doing stuff like manual config, and future state is everythign automated as much as possible in the cloud and shutter the data centers.

I think the harsh truth is that many wont have jobs post move, but maybe I'm being cynical. maybe theres a chance to retrain the employees, but even doing that automation generally reduces the workforce.

whats your take? what do I tell current employees? how many can I realistically be able to save from being jobless?

xupybd• 8 years ago

Can you last long term if you don’t move? If there are huge savings to be made others in the same space might jump on the opportunity.

It’s a horrible thing to have to let people go but the alternative may be far worse.

tucaz• 8 years ago

I will assume that at the current state you are able to pay both the datacenter costs and people costs since it seems that is what you are currently doing.

With that assumption in mind, if you do migrate and realize that you now don’t need 80% of the people you needed before, it could mean one of two things:

- you are now able to pocket whatever savings you were able get from the migration and either save it or invest in something to potentially keep that money in the economy, just in a different way

- you now have 80% of your people free to do whatever other things you didn’t do because they had to maintain datacenters. That is huge in terms of efficiency gains and allows you to redirect that money to increase the value provided by your company either by repurposing the current workforce or getting rid of them and bringing people you could previously not bring on board due to existing costs

Either way I believe that everybody is better off After the changes.

Efficiency gains such as the one you are describing is what makes it possible for economies to grow and keep moving forward.

Can you imagine if you had to handle cows, pigs and farms to have a BLT? It’s very good that such things are outsourced because that allows for improvement that would otherwise not be possible.

subway• 8 years ago

Odds are high that the anticipated cost savings sits largely on the folks they intend to sack, rather than on any power/real estate/bandwidth/hardware savings.

throwawayacct4q11• 8 years ago

Actually the cost savings hinge on the massive cost savings from moving to a commercial cloud, laying off workforce would save more, but would prefer to save a bunch by moving to cloud and keep the workforce for other things.

s73v3r_3• 8 years ago

The people who would be laid off are likely not better off.

rbanffy2• 8 years ago

In that position, you could:

a) get the severance package and retire

b) get retrained and stay

c) get retrained and then leave because you really hate cloud ops

d) get the severance package and move to a similar job

suff• 8 years ago

They need cloud certifications. They should see this as a fabulous opportunity to get paid to do cloud training, hands-on work. If you become a cloud architect or a cloud security expert, whether it is at your company or somewhere else, there will always be great opportunity. If they refuse to learn to serve a changing market, that is where they will run into problems. You can only ride a single skill for so long. If you stayed in the horse-shoe business after about 1904, life was not great.

dankohn12• 8 years ago

I'd recommend CNCF's training for Kubernetes: https://www.cncf.io/certification/training/

We offer a free edX course and then a paid one that prepares you for the Certified Kubernetes Administrator exam.

Disclosure: I am executive director of the CNCF and helped create these courses.

P.S. No job will be around forever. You are not doing you or them any favors by trying to maintain them in inefficient roles. But you can invest the resources to bring them with you to the new world.

jhowell2• 8 years ago

If your business has competitors, and they move to the cloud, conceivably they will be able to lower prices, and/or provide more service/features because of cloud scale. In most instances, the less your competitors charge, the more customers flock to your competitors. It is not personal, but economic in my opinion.

throwawayacct4q11• 8 years ago

Our business is an old, traditional business that happens to have lots of data centers for legacy reasons. Even though we spend $BBB on data centers, they're not the core of the business and a very small part of overall revenue. Realistically, even if we didn't move from data centers we would be good as long as the core non-tech business functioned.

alpb• 8 years ago

Are you sure you’re spending triple-digit Billions in dollars for datacenters? Or are you just trolling?

jhowell2• 8 years ago

As an economic principal what you suggest is not the best use of inventor assets and compounds when you factor in employee efficiency/return per employee. If you invested your hard earned money into this business you would want cost efficiencies and high productivity. Company executives have a fiduciary responsibility to do so in the US. If you're running a business and are not seeking cost efficiency but instead are more interested in employee satisfaction, likely you should be in HR and let the CEO handle day to day operations and the bottom line, so you can contribute to the company by driving employee retention, satisfaction or some metric that reflects positively on the bottom line. It's OK to the a CEO. It's OK to be in HR. It's not OK to be a CEO in HR. It's not OK to be a HR as CEO.

jonex• 8 years ago

While automation is removing some jobs, we are far from a fully automated society. I obviously don't know about the specific job markets where your data centers are, but in general, the ones having the hardest time finding a job aren't the ones with years of work experience in running data centers.

They might have to retrain and if they live in a small town they might have to move/commute to find something new however. This can be hard enough for some people that they won't be happy about it.

In the end, I think it's hard to argue that we should keep being inefficient just to save jobs. History haven't been nice to that kind of companies.

tyingq• 8 years ago

Retrain them in AWS, devops, or something that has similar need, versus hiring from outside.

throwawayacct4q11• 8 years ago

Best way to retrain without having to pay AWS a huge fee for all the certs?

alonmower• 8 years ago

Negotiate a discount for the certs as part of the large contract you’ll be signing with AWS

jdubs• 8 years ago

Paying for certs will pale in comparison to paying for inefficient infrastructure costs.

segmondy2• 8 years ago

The certs are cheap $150 each. If you have that many you can create your own internal exam

friedman23• 8 years ago

I really think the worst thing you could do is continue to run the business in an inefficient manner. Improving technology and as a result efficiency is the reason we have advanced so much as a species.

However, you don't need to be callous in your pursuit of efficiency. You should try to give these people an opportunity to update their skills and get a new position. You might not be in a position to do that however.

buahahaha• 8 years ago

Just retrain them.

They're going to have tangential skills to the new platform.

Get your network team to learn all about VPCs and networks and security groups and peering and VPNs, train them to be your in-house experts to deal with changes and expansions and to help trouble-shoot issues.

Chances are you're still going to have systems, your systems engineers can be repurposed to better tie in your monitoring tools, your security tools, etc. You're going to need authentication and identity management, and probably have internal people handling it.

If they're motivated to keep their jobs, all it should cost you is a $5-20K/head in training.

That's peanuts compared to the turmoil of everyone thinking they're going to lose their jobs, or the costs of hiring new people w/ pre-existing cloud skills. It is cheaper than the stop-gap of paying outside consultants till you can bring in the interior staff. Also, these people _know_ your existing systems. They know your business logic, they know what needs to be up and they know what can't break on Thanksgiving weekend. That is valuable knowledge that is a hidden cost in rehiring the work force.

You're going to find new challenges in the new system. If your employees are willing to transition, then transition them. It is your best bet.

If you have a subset of employees that can't/refuse to transition, put them on performance improvement plans. No rumor mill - if you're on a PiP you need to shape up or get out; if you're not on a PiP keep doing well, your job is safe.

marktangotango• 8 years ago

This claim of massive savings is ludicrous for an f50 in the first place. It’s doubtful their cost is primarily maintaining and admining fleets of x64 servers, which is what the “cloud” is optimized for. These companies generally have massive costs from legacy mainframe, iseries, mvs etc systems. The ops creds are suspect to say the least.

citrablue• 8 years ago

Your comment would be more palatable if you gave the OP benefit of the doubt. It seems reasonable to assume that someone who is in the position to affect such change, and is willing to ask HN for advice, likely has actual cost savings estimates.

Perhaps saying something like, "Are you sure the cost savings are really there, and you won't face unexpected hidden costs in the future? I have experience with X,Y,Z, and we found that while the cloud is optimized for x64 deployment, we had hidden costs A, B, C, crop up after 9 months."

As it is, it's only added noise and made you look bad.

rbanffy2• 8 years ago

He mentioned 90% of their datacenter operations. I assume the remaining 10% would be the assorted legacy every large company has of SPARC, PA-RISC, POWER, i and zSeries accretes over time.

Those will remain where they are and, eventually be ported or replaced (or kept alive - IBM mainframes have been legacy-friendly for over 50 years now) by newer systems as they are phased out.

fakecigar• 8 years ago

I can't agree more about retraining these guys. Hiring cloud engineers with good skills is extremely difficult

ma2rten• 8 years ago

But is OP really going to have the same cost savings if they retain everyone? I am assuming labour is a huge part in that figure.

gaius3• 8 years ago

The cost saving from going cloud in a large part comes from utilization. 1 box that you can keep busy at 100% by clever workload timing is cheaper than 10 boxes that are idle 90% of the time that you just need to spike on. Or capacity that you can give back when you don’t need it. Rack space is expensive, power and cooling are expensive.

The job of the people is to translate the business requirements into stuff actually happening, and that doesn’t go away with cloud. If anything you need to do more of it (someone has to take care of auto-scaling, a thing that wasn’t possible in your legacy DC, for example). The worst thing you can do is sack the people then realize you need consultants at 5x the cost to do anything now...

michaelt• 8 years ago

The ideal situation is to be in a growing company, and to move employees from shrinking areas into growing areas.

For example, if the company needs 8 fewer people to install and set up servers, but 10 more people to work on robust automated code deployments to support business growth, and both jobs need Unix skills.

Hence, the setting-up-servers department budget shows cost savings, the overall technology budget grows by 2 employees instead of by 10, and business growth means overall profit increases.

gus_massa• 8 years ago

How many are them? (10? 100?)

Are some of them close to retirement age?

throwawayacct4q11• 8 years ago

Thousands, many close to retirement age. Think a company like UPS/Fedex that isn't at its core a tech company but with tech datacenters for logistics and billions in revenue.

TAForObvReasons• 8 years ago

If serious, consider offering an early retirement package and see who bites.

russtrpkovski2• 8 years ago

Thousands? I really find that hard to believe.

supahfly_remix• 8 years ago

Are you sure the savings will be real? I've read that real savings results from using the cloud for bursts while keeping the base load on-prem. (Never done this personally so can't speak from experience.)

Once you let those people to you will be losing their knowledge in this area. Not sure if it matters.

southern_cross• 8 years ago

Since you're thinking towards the future, think also to the time when you will probably have to move an awful lot of your stuff back in-house, which might be much sooner than you'd expect. Plenty of companies which outsourced in a big way some years back have already been through a similar cycle.

A former Fortune 500 employer of mine went through the outsourcing boomerang. Now I understand that they have big plans to move everything to the cloud within the next two years. Knowing their systems like I do, and knowing that the CEO who is driving this is fairly noobish (note that I said CEO rather than CIO), I don't think this plan is going to work out too well for them. But given that since I left they've had to file bankruptcy, and in doing so involuntarily dropped to about half of what they were before (employees, assets, etc.), I guess this is just par for the course for them now.

downrightmike• 8 years ago

Good luck being at someone else's mercy when the problems that are being held together by duct tape come to a head.

omeid2• 8 years ago

At the same time, I rather negotiate with a service provider than employees who have implemented their position into the system.

sdfin• 8 years ago

Your competency is eventually going to do the same and save money and have advantages over you if you don't take advantage of the awesome cost savings. Then you may cease being competitive and would have to close the data centers anyway.

As others said, you could retrain them.

gboudrias• 8 years ago

I've never managed more people than myself, BUT don't underestimate how difficult it is to find people in IT. It's really, really hard, and even harder to find people willing to stay longer than 2 years.

Loyal tech workers are invaluable right now. But then again I'm not the one who has to make that choice.

lmeyerov• 8 years ago

Embracing automation and moving to cloud systems means layoffs for a dying/stagnating company and an opportunity engine for an innovating one. Our startup does GPU visual graph analytics for boosting visibility, and we see a world of a difference in velocity etc when we engage with a company that has cloud data lakes etc than one that doesn't. And, that includes F50s and federal agencies: super normal!

Technology employees should embrace new tools; that's part of the job that ensures compounding effects over time.

gjkood• 8 years ago

You obviously have a good heart for asking the question!

I have a feeling that whatever decisions you finally take would take into consideration the wellbeing of your employees.

I would assume that the folks who are doing the legacy stuff have the necessary aptitude to pick up the skills that are needed to automate for the future. Can their existing data center skills be translated into learning about AWS/Azure, VMs, Containerization and the necessary scripting and DSLs around those toolsets?

Obviously there will be reductions in headcount but give them the option to retool for the future. Even if they are not all retained but if you retrain them then they will still have options elsewhere with relevant skillsets.

You are finally running a business after all where revenue and profit are the drivers.

Good luck and I would say that your employees are luckier than those who consider them as mere resources and not people with lives and loved ones to take care of.

segmondy2• 8 years ago

Just do it. Most old school sysadmins want to write their Perl and sh scripts not terraform and cloud formation scripts.

I got my devs to embrace GCP, AWS, ansible, terraform, docker, k8s, devops and SRE before most of the admins. Most of them left to go safe companies where they can stick to their old ways.

gaius3• 8 years ago

I got my devs to embrace GCP, AWS, ansible, terraform, docker, k8s, devops and SRE before most of the admins.

Yes, devs are often enthusiastic because they think they can ditch those boring old operations people who always stop them having fun.

Next thing they know they're on call 24/7 and don't get to write application code anymore, just operations stuff...

The truth is the need for ops people doesn't evaporate when you go cloud, be wary of anyone who says it does. This is the same dynamic that played out with MongoDB.

dev_dull2• 8 years ago

The new reality is that the barriers are gone. Ops must dev, dev must ops.

Who can get away with a job that just requires them to open a Java IDE? Those jobs are just as extinct as a pure ops role.

mmt13• 8 years ago

Yes, devs are often enthusiastic because they think they can ditch those boring old operations people who always stop them having fun.

I think it's more subtle than that. (Also, I think the parent was trolling, but you knew that). It's that there's a certain class of programmers (and/or managers with exclusively programming backgrounds) that truly believe all (technology) problems can be solved with software.

If one assumes that belief, then the hostility to someone who believes differently is arguably inevitable.

It also explains why, to some, "Devops" is code for "wannabe dev" or some other coding-first role.

Next thing they know they're on call 24/7 and don't get to write application code anymore, just operations stuff... The truth is the need for ops people doesn't evaporate when you go cloud

That explains the dozens of seemingly-identical job postings from tech startups for "Devops" engineers with both experience in the above latest tools and operational experience. Fortunately, they only ask for 1-3 years, which is realistic.

This is the same dynamic that played out with MongoDB.

Ultimately, though, did it matter? If we sometimes got fail whales instead of 140 characters, we still didn't get flying cars.

Alternatively, for whatever reason (freely flowing VC? low interest rates?), there's too little incentive for low cost or high reliability ops right now.

empath753• 8 years ago

I was an admin that learned to be a dev specifically so I could work on cloud stuff. I almost doubled my salary in 3 years.

mmt13• 8 years ago

That's the part that amazes me, just how much more companies pay for the cloud stuff, even on the labor side, yet startup executives (some of whom I've personally interviewed with) keep insisting it's cheaper.

codingdave• 8 years ago

If you are in a position to make decisions for that many people, is it a safe assumption that you have a fairly robust knowledge of how to enact organizational change? Because based on my limited knowledge, major change like this has processes to be worked through which will help answers some key questions -- what is the current and future state, who will gain/lose, what will your communication plan and transition plan be, etc.

You have much more knowledge to give those answers than we do. What to tell employees, and who can/not be saved from losing their job depends on those answers.

I will say that open communication, with complete answers of what people should expect, will help the change to happen without losing the trust of those who do get to stick around. You will have some harsh truths to share. If I worked for you, I would want to hear them as soon as there are enough answers to not leave me in limbo on how it affects me, personally. Not sooner, not later.

cjalmeida2• 8 years ago

I would second this comment and add that proper change management is needed to ensure a smooth transition. As soon as the word is out, if you don’t have a plan and/or don’t communicate in the right way, your people will start sending out resumes and that can wreck havoc in your business.

As you might expect, replacing top notch techies is quite hard. So managing the transition and making sure those that won’t be kept are better off is not only a good heartened approach but important to the success of the project.

Management consultants usually get a bed rep but that’s something they’re pretty good at. If you’re an F50, you have the budget to hire a top one.

georgebarnett• 8 years ago

I have some experience in this area. My thoughts:

Retraining can be done as part of the project, but you need to figure out what the project and sub projects looks like first. Then you an know roughly how you’ll move people around at various phases. It takes time to build new systems and time to train. Line those up and you can take advantage of them.

Be careful with costs. They will blow out if you aren’t mindful.

It’s going to be messy for a LONG time, which causes a huge amount of pain in the org. Be ready for this.

Moving to cloud brings a whole new set of problems you haven’t thought of yet. For example, cleanup becomes more critical (old resources cost money, but can’t be “seen” because they’re not physical and just a hidden line item somewhere).

There’s more. My email is in my profile if you wish to reach out.

nasmorn• 8 years ago

Cleanup is even a problem in smallish startups with some dozens off devs. I cannot imagine the amount of security groups a F50 must have after some years

late2part2• 8 years ago

What type of commercial providers are you saving money by moving to?

synesso• 8 years ago

This happened to my friend in his 50s. He was a storage specialist working for a bank. Since they outsourced to IBM a few years ago he's been stacking shelves in a supermarket.

markbnj• 8 years ago

If you let yourself get that specialized then you're always going to be one or two innovations away from a layoff. I kind of feel that anyone who inhabits a niche like that for a long time is going to be in danger of becoming a victim of their own comfort seeking. Our industry is not kind to those who don't continually challenge themselves and learn new things. As a counter example to your friend's situation, I'll be turning 58 this november, and I'm an SRE/devops engineer working on kubernetes-based infrastructure in google cloud. Five or six years ago I was a back end .NET guy, a few years before that I was doing ASP web apps. Before that C++ and COM/DCOM stuff, and before that Orbix/CORBA, and before that... you get the picture. The old saw is that nothing stays the same, so if you're not moving with the world you can be sure it's moving past you.

apapli• 8 years ago

I imagine it is going to take you a LONG time to do this. Some apps will migrate easily, others not so much. If you want to look after your people build a program of work in place that helps you realise immediate benefit while giving you the change to reskill people as you migrate to newer tech.

poster123• 8 years ago

Jobs in the private sector do not come with lifetime guarantees. If you have new jobs you could train them to do, great. Otherwise, give the people you will lay off notice and severance, and let them figure out what to do.

s73v3r_3• 8 years ago

To any companies wondering why their employees jump ship at the drop of a hat, or why there's just no loyalty anymore, this attitude is it.

Spivak• 8 years ago

Sure, but it's a cycle that is easy to fall into and hard to break now that we're here. Distrust begets distrust.

throwawayacct4q11• 8 years ago

No. As an engineer myself, this is exactly what I'm working to avoid. I know we could terminate, but these people have built careers and have deep knowledge of the systems and business, I'm not letting them go without at least giving them the choice to retrain.

ezequiel-garzon• 8 years ago

Out of curiosity, what does F50 refer to here? Google doesn’t help, nor does https://en.m.wikipedia.org/wiki/F50 .

tills13• 8 years ago

Fortune 50, I assume.

dankohn12• 8 years ago

It refers to the 50 biggest companies in the https://en.wikipedia.org/wiki/Fortune_500

Mc91• 8 years ago

You should do the move. Sysadmin is now a niche discipline, people work in devops now. The tech economy is good and their skills are getting more obsolete.

Just start slowly migrating things, and train them in devops skills. Then, even if you have a reduction in a year, they will have a year worth of modern skills in EC2 devops and the like.

It's going to happen, so better it happens now than in the future.

ultrasaurus• 8 years ago

Kudos for keeping your sights on helping your team! I'm a big fan of holding on to a group of people that understands your business (I'd rather retrain a technology than instill passion and domain experience).

Not 100% relevant (and not my better writing) but here are some of the things I've seen companies do in terms of moving people around from NOCs that might give you some ideas https://www.pagerduty.com/blog/future-of-noc/

If you'd like a soundingboard to brainstorm with feel free to ping me at dave@euri.ca

kylec• 8 years ago

Since it sounds like you're going to save a bunch of money, I suggest letting them go and using that money to provide very generous severance packages (months of salary at least). Then they can choose to retrain themselves, take some time off, whatever. It works for Netflix.

sjg007• 8 years ago

I would build your own cloud. You have customers. Don’t give them away.

panic• 8 years ago

Maybe this is unrealistic somehow, but what about paying the difference in cost directly to the affected employees?

joewee4• 8 years ago

There are a lot of benefits to migrating to the cloud, in my experience, cost isn’t one of them. Unless of course you are mucking around with accounting tricks by cutting employees and moving that cost to services or cost of goods sold, I’m not a expert in this, but it works and will save you money because you can control these expenses more easily and because of how payroll vs services are accounted for.

You should aim to keep 50% of your workforce. 25% won’t want to change 10-25% won’t be able to. I would invest in training on automation and multicloud / hybrid cloud management. I recently worked on a large scale migration and you will definitely discover that the cloud wont work for a lot of your high performance computing, or it will be cost prohibitive. You also need to take into consideration intellectual property, does the company really want all of its IP on another conglomerates infrastructure? But most importantly you need to avoid lock-in to one provider at all cost, training your trusted resources who understand the business requirements on hybrid cloud or multi cloud implementation will really enable cost savings because you will have leverage during price negotiations. If you get locked into one provider you are going to get royally screwed on long term cost, seen it happen.

boulos• 8 years ago

Disclosure: I work for Google Cloud (and I assume/hope someone at Google is competing for your business).

Some of those folks happily do updated things, but others (like people that rack servers) won’t have an obvious new role in a cloud focused world.

My (now) colleague at Nic Harteau gave a talk at our Leaders’ Circle event talking about precisely this in Spotify’s move to Cloud: how could he keep the infrastructure team as they moved to cloud? As it turned out, most of them happily adjusted what they were doing because the mission was the same: serve the product teams / groups that need infrastructure from them. Sure, now you don’t configure a physical firewall, but there are still firewalls in cloud. In a sense, they’re even more important!

I believe Nic said only one person from the group left. The engineer was focused on building their own SDN stack on-prem. That job, and other “things the provider completely handles” do go away. But that person likely would have been massively useful in helping guide how Spotify should use Google Cloud’s own SDN setup. There are lots of ways to architect how services interact in clouds, and a lot of it comes down to funny networking.

So I’d say more than you might think, but please don’t mislead them.

gsich• 8 years ago

Why not automate your stuff at your current datacenter?

mathattack• 8 years ago

First path is to retrain them. Getting more cost efficient can coincide with overall corporate growth.

Some people prefer to remain in their specialty or struggle to make the leap. In that case if they have tech skills, someone will take them. It may require a move, but they will land. It's one thing if you're firing people in the dark days of a deep recession. (Folks let go in 2001 had to leave California) It's another thing if you're letting people go into a market of 4% unemployment. If they can't get jobs with similar pay, then you were overpaying them.

stretchwithme• 8 years ago

Tech jobs exist because of automation and they eventually go away because automation. But every dollar saved in salary is available to spend on hiring people to do other jobs. It works out in the long run, but that doesn't make it easy on those who have to transition.

I think it would be useful if employers eliminating jobs could have sort of a reverse auction where other employers offer comparable jobs in exchange for a portion of the savings. And the workers could either take their severance or accept one of those offers with no interruption in their benefits or work.

zer00eyz• 8 years ago

Cloud/Comerical <> automation.

I have been burned in the past by "commercial", thankfully I wasn't the guy who had to go to the board hat in hand and say "this isn't in our control"...

Every comercial provider is going to do everything in their power to "lock you in" they are going to put up features that are "better enough" that you migrate to them and then they own you.

Automate, reduce your workforce as needed (it will be less than your plan) and then look at the commercial provider as a second step, look at them in relation to a real DR plan. You might not like what you see for day to day operations but having them on stand by in the even of an emergency could make you a hero and present a massive cost savings already.

exikyut4• 8 years ago

Saying first what I want you to see the most: please add a throwaway email to your bio profile (and maybe add a new comment with it so more see it). I guarantee people will want to say hi privately - not [just] vendors but random people who have on-the-ground advice.

Hopefully you still see this even though it's been a few hours.

Glad I went through the thread: there was quite a bit of extra narrative and detail in your comment replies.

Our business is an old, traditional business that happens to have lots of data centers for legacy reasons. Even though we spend $BBB on data centers, they're not the core of the business and a very small part of overall revenue. Realistically, even if we didn't move from data centers we would be good as long as the core non-tech business functioned.
Thousands [of engineers], many close to retirement age. Think a company like UPS/Fedex that isn't at its core a tech company but with tech datacenters for logistics and billions in revenue.
[T]he cost savings hinge on the massive cost savings from moving to a commercial cloud, laying off workforce would save more, but would prefer to save a bunch by moving to cloud and keep the workforce for other things.

Ok, here's my take.

I wonder what your [job] position is, heh. Maybe someone with a CTO's ear, or maybe you're an unusually empathetic CTO.

In any case you're clearly at the point where you've had the internal discussions, the trigger has been assembled and is ready to pull, and you and/or the team (committee?) has probably already been groomed by all the gigantic providers' sales teams, which of course pull out all the stops in your case. If I understand these things correctly, if you haven't yet had an amazing lunch or two on one or more vendors' dimes, you will :) (or at least the high-level people will, would be nice if you get included).

Sales is important. But always remember, particularly for large potential accounts like yours, the sales numbers will always be what the high-level execs want them to be, and the sales teams will be spinning the story the execs want to hear. The on-the-ground experience is always going to be rough. You've probably experienced similar transitions, and that's what's informing your skepticism some of your team won't have jobs. Nice you're giving your people some thought.

On the one hand, it doesn't really matter who you sign up with, as vendor ceases to matter somewhat short of the $B mark.

On the other hand, try to mitigate the risk of discovering that a vendor can't provide a given feature at some eleventh hour, or you may end up in a confused tangle of AWS and GCE deployments (because the other major vendor will of course have the missing feature, and the fragmentation will begin).

How I'd achieve this: every time you go "ok, so this is our implementation blueprint", start the rounds of internal technical enumeration over again. Spend time with the engineers to understand pain points. Talk to as many people on the ground as possible, especially the forgotten people in the corners. One-on-ones, or small groups of people who are known to gel well with each other (no impedance mismatches, work well together), could be good for extricating annoying gotchas. This could look like devs aimlessly paging through source code and saying what they think (this could catch tiny things well), or it might be more structured with general architectural discussion.

Do NOT have the cloud provider vendors do this work (of talking to your existing team); I wouldn't be surprised if they offer to do it, but if they do, all their feedback ultimately goes to the sales guys (via an internal engineer digestion process), and not directly to you.

Well, the analysis team will probably generate a high-level report that contains all the information they've discovered (this is probably legally mandated for full disclosure about what they now know), but all the on-the-ground details about inefficiencies, vendor-specific pain points and so forth will only be derived by vendor-internal engineering debriefs, and you'll naturally never get any of this particularly valuable information - unfortunately this approach is within the vendors' business focus, as inefficiency means more compute resources used ($), and pain points mean more vendor-infrastructure maintenance ($). You could respin this statement to say that the vendor who makes the most attractive offer is the one who knows their system is the worst fit for your system, but I don't know :)

Instead, if you don't have the internal resources (or freshness/objectivity) to put together a bird's-eye view, get an outside consultancy to help, directing them to investigate your current architecture top-to-bottom-and-back-to-top-again, and advise on ways the system can be rearchitected for efficiency and optimization within modern cloud infrastructure. (They'd then be the ones doing the one-on-ones and so forth I mentioned above.)

Another thing that may be extremely useful would be to take the "we're moving to the cloud traction" and carefully smudge out (some of) the dividing line between "we're overhauling everything to migrate it and make it work most efficiently within $vendor" and "we're rearchitecting major components so they work more efficiently overall" so the line between these two sentiments is blurred, and both things wind up happening in lockstep. Obviously the two ideas are intrinsically distinct and this can only be taken so far - "rewrite everything from scratch to get it running in the cloud" wouldn't pass any accounting costing or time-boxing :) - but you can probably push this far enough to extract some usefulness from it (eg, you probably have an idea how long upper level will be willing to wait for this transition to finish - 2 years? 1 year? 6 months? - and you might be able to squeeze some interesting and useful tidy-up operations into that window).

Blurring the lines between these two things will play to your existing devs' strengths, as rewriting/restructuring is easier on the brain than the "replace engine in flight" of picking up all the existing state, punting it into to the cloud ad-hoc, and running after all the resulting fires that get created and scrambling to get it all working perfectly.

It won't be a perfect transition if you're really a $BBB operation, and restructuring will be the easiest way to cohesively get the existing devs into a flexible frame of mind and ready to deal with whatever curveballs get thrown their way.

This is one way you could efficiently achieve keeping a lot of your existing team.

Plus, restructuring means everything can slowly be built up onto the new system; picking everything up at once and expecting it to land on its feet probably won't go very well.

Depending on how things go, if you bring in new techs to assist with understanding modern best practice/hitting the ground running, I cannot recommend enough pitting them against your current team when doing onboarding/interviewing, as they'd be an EXCELLENT catalyst for judging candidates' character.

These are a couple of lateral ways the current workforce could be creatively employed during this time. I reckon careful management would see everyone kept on until retirement.

The current team knows all the systems inside out. Letting them go would make everything a thousand times worse.

Also, another reason I thought it would be cool to put an email is because your post makes for a perhaps-unwitting but nonetheless effective and interesting recruitment drive; I'm aware of very few (okay, zero) high-level people at equally high-level companies who really care about their employees. In my case this is because I don't have any connections, but the same probably applies to many others.

I don't know why https://news.ycombinator.com/item?id=16283252 stood out to me a few months ago, but your post resonates similarly. Probably because it incorporates a similar human response too. (Note that I have no association with the potential companies listed and have never talked to any of the users in that thread, I just thought it was interesting)

throwawayacct4q11• 8 years ago

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• 8 years 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.

mmt13• 8 years 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.

exikyut4• 8 years 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...)

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/).

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)

notatoad• 8 years ago

Your people shouldn't be doing manual config regardless of if you're on-prem or cloud. If they are, you're going to have a tough transition to cloud, and you're still going to need a lot more of those people than you think you will.

noobermin• 8 years ago

Hate to do this, but be mindful people bearish on the benefits of moving in the first place will be downvoted crazily, potentially by people who have an economic incentive to convince you this is a good idea.

rshlo• 8 years ago

Hire for attitude, Train for skills - If you've good dedicated people that you can trust, I'm sure they can be trained for other positions. Good people are always hard to come by, and they will be even more loyal if they will see that the company doesn't ditch them.

eksemplar2• 8 years ago

We’re in the process of moving our infrastructure to Azure. Being the public sector we take things relatively slow, but we’ve already fully embraced Azure ad as well as office 365, one drive for business, planner and all those other things.

The next step is our servers, they are already virtual and hosted in our own cloud, but moving our database cluster to a commercial cloud is still a big step politically.

Anyway, you retrain your employees. You may need fewer in the long run, but finding people who are actually professional at stuff like setting up on-premise security inside Azure hasn’t been easy for us. We’ve had 3 very highly regarded consultant agencies to help us, and they quite honestly didn’t know anything but tech-book Azure. More than once we’ve had to send consultants home because it became obvious they knew less about this stuff than our people.

Azure has also opened up for a range of automation through services, but that’s not really automatic either. We’ve had to retrain our people in powershell, and now we’re running a lot of stuff through the orchestra service. So right now, we’ve actually not needed fewer people, just better trained ones.

I image you could replace Azure with Aws or any such service and it be the same story.

int_19h• 8 years ago

If you don't mind me asking - why Azure specifically?

brianwawok2• 8 years ago

I would guess they are a Microsoft Shop.

Azure seems to have a compelling platform for Microsoft Shops. I don't see the allure for a Linux shop. Sure you can run Linux on Azure, just like you can run Windows on AWS... but I don't think either is optimal.

theyinwhy• 8 years ago

Microsoft throws the moneys at you and "owns" places. They marched into our company as if they owned the place. They have all the selling power and all the money to "convince" you. And yes, contracts are time limited so the big squeeze will be coming eventually.

eksemplar2• 8 years ago

We’re the public sector, we operate more than 500 it systems, some of which won’t be leaving the windows platform.

We run office 365, Skype for business and handle our Security through af and adfs for 10.000 employees.

So we’re already heavily invested in Microsoft as far as what our IT staff is trained in, and they prefer Azure to say AWS often for non-technical reasons, but that sort of motivation is still important from a management point of view, even if you can run windows in AWS.

That’s one reason. The other factors is that we’re in the EU and Microsoft were the first to implement our laws, without fighting them. Unlike AWS I can physically visit our Azure servers, though this requires you to throw a lot of money at Microsoft. Last but not least, Microsoft is a trusted partner that we’ve worked with for 25 years, Amazon is not.

There weren’t any other options than AWS and Microsoft, because we’re in the eu and in the public sector, and AWS wasn’t under the privacy laws at the time we started.

A lot of our neighbors are choosing AWS though, so it’s certainly viable today.

kriss9• 8 years ago

You're taking the marketing approach as opposed to coming up with real solutions -- think critically about the business need, investigate the cost savings and make a transition plan for those who actually add value to the organization.

1) Consider if your organization has a future strategic value for having the org capability in house (is this datacenter simply a necessary evil or does your organization deploy new technologies to new locations for any part of its business)?

If so, you may be outsourcing a core part of your organization's capability (consider it). If not (e.g. these are all simply HR and other general business systems [ or services which do not depend on anything physical], you should proceed to evaluating costs

2) By the thought that you would outsource the majority of jobs means that you probably shouldn't have had the employees in the first place (in the Fortune 50 I know, we mostly used contractors with a quarter dozen employees). Hence I would evaluate if there are other business units which might benefit from their skill (power related, analyst related et al) and offer training per the previous notes.

A good decision to be a part of and my hope is that your answers here inspire the right questions (to allow for the right transition plan for your organization and company as a whole).

jwildeboer• 8 years ago

My rule of thumb: invest 30% of the cost savings into training your people on skills you need now but also with a view to future plans. Invest in preparing your people for new ways like DevOps, microservices. With their experience and knowledge they can save you even more looking forward.

And even if you don’t need them all, by training them you give them a better chance when finding new jobs. A small investment can go a long way. Also helps your companies reputation when people don’t simply get removed.

jedberg• 8 years ago

When Netflix moved from the datacenter to the cloud, there were a whole bunch of really good people with skills we didn't need anymore -- sysadmins, DBAs, datacenter techs, etc.

Netflix went to them and said, "do you want to learn some new skills that apply to our new cloud based infra?" Some said no, and were given big severance checks and glowing recommendations. Others said yes, and were retrained.

And some were retrained but it didn't work out, it turned out they weren't interested in the new work, or just weren't needed, and so they too were given big severance checks and glowing recommendations, and went to look for new jobs using both their old and new skills.

It's nice that you're worried about them, but the best thing you can do for them is offer them the chance to learn new skills, either through new jobs or paying for them to learn new skills.

brianwawok2• 8 years ago

This seems best - offer them the choice.

Don't go "learn to code cloud formation in 30 days or lose your job with no severance".

mesozoic• 8 years ago

Progress

lsc4• 8 years ago

so, uh, I'm not weighing in on the job stuff... but I suggest you check your numbers on how hosting in the public cloud is cheaper than your own data centers.

I mean, sure, automating things is great, and running your own hardware cloud-style is great for a lot of workloads... but that doesn't have a lot to do with the decision to rent rather than own your servers.

Cloud providers charge a lot compared to owning your own hardware, unless your load is extremely bursty.

The bandwidth prices are particularly eregrious. They are like what you would pay for bandwidth 10+ years ago.

I personally ran a small VPS company and managed to turn a (small) profit while selling compute for rather less than amazon, even though I had to rent space and power from a fancy pants datacenter by the rack. I was essentially paying retail, and I only had 20-30Kw of capacity, max, and even at that scale, owning was cheaper than renting.

I can only imagine that at F50 scale, the economics tilt even further towards own, as you can much better amortize the labor than I could

(and it's not like the datacenter loses money, either. Renting datacenter space is like renting commercial realestate. When your lease is up, the renewal rate goes up to whatever competing space costs + what it costs you to move. Owning is so much better in that respect.)

empath753• 8 years ago

Amazon etc negotiate prices for large accounts so the price you pay will not be the same price that a Netflix pays.

lsc4• 8 years ago

Sure, and it's possible OP really is saving money by renting their hardware instead of owning. I don't know the details of their needs or of their costs or what cloud provider they are moving to or what deal they cut with that provider.

I'm just saying, there's currently a huge push to rent your essential services from service providers such as amazon, and from what I've seen, it's pretty easy to "move to the cloud" and then find that your total cost goes up pretty dramatically vs. owning hardware.

I mean, yea, "cloud" does make sense sometimes. But... it is sold as being cheaper, and quite often it is not.

Even if the rates look good up front, you've got the same problem that you have when leasing commercial realestate from professionals; they are professionals, which means that when it comes time to renew the lease, the rate will go up to match what renting something similar would cost from a competitor, plus slightly less than whatever they think it will cost you to move. If you can't switch cloud providers and your cloud provider knows it, you can count on your negotiated rates going up next contract renewal.

Havoc• 8 years ago

If you don't do the move someone else will eventually given the monetary incentive. This isn't something that can be stopped.

Better that it happens under the watch of someone that clearly cares

arminiusreturns• 8 years ago

theyre doing stuff like manual config, and future state is everythign automated as much as possible in the cloud and shutter the data centers

Ok, who let the C'level out of his cage? Quick, convene a meeting about meetings and distract him with new synergistic products that mesh the work output of the teams into a new daily reporting product with shiny graphs for him to make informed decisions about, preferably by proposing an "cloud only" data scientist.

But seriously. This comment alone shows this person doesn't have a clue wtf they are talking about. If your guys were so focused on manual config that was a management problem, and isn't an inherent fact about the current state of data centers. So you decided to move data centers, you just moved the jobs somewhere else, to the new provider (Let me guess, amazon, microsoft, or google...)

Say it with me: "There is no such thing as "the cloud"."; Say it again: "There is no such thing as "the cloud"."

Your shit still runs on servers, that at the end of the day someone manages the systems of. So they manage the systems at a lower level that is transparent to you as the modern datacenter is able to hotload blocks, devices, vm's, containers, etc across a swath of machines, clusters, etc.

At the end of the day, you made a business decision that decided managing your own on prem wasn't for you. For some companies, that can be the right strategic move, but as the salty ol bofh who has seen it happen, it's not all puppy dogs and rainbows and there are many pros and many cons to such a move... with "the boss" usually completely underestimating the cons.

Next up: the boss asks how to ease the transition of the low level programmers because he's hiring a new wave of nodejs/meanstack devs because "there's so many of them he can pay them less than the greybeards" and "they are young and know all the cool new devops agile cloud cycle methodologies" and "c++ is dying".

Whatever f50 this is I'd longshort the fuck out of it. I bet it's in a downslide for other reasons and IT is the easy dept to squeeze politically while ignoring the root causal issues that are probably management related.

tldr; Data centers aren't going anywhere, your shit still runs on servers, people still design build and rack boxen, design, fine tune, and diagnose networks, munge and wrangle data, etc, etc, and the skills they have are still in high demand the world over. Disagree? Tell me how many data centers as a percentage that have fully automated robotized racking?

throwawayacct4q11• 8 years ago

You really have this completely wrong. I am a systems/network engineer and am newer to the business side. Asking here to get some upsight into the people side. Thank you for pointing out that things run on servers, that was news to me.

mmt13• 8 years ago

Sarcasm is rarely well-received here. Also, I think anyone reading any of the rest of the thread would see that you do have an understand of the issues, so no need to defend yourself.

Conversely, the parent commenter uses hyperbole to the point of appearing not to have that understanding.

For example, even without "fully robiticized" datacenters, there are remarkable economies of scale before that, including ordering servers by the rack (or maybe even row at a time), pre-assembled by a vendor.

Things really can be different, even though they can be the same.. even both at the same time!

dev_dull2• 8 years ago

There’s actually a huge difference in performing their job in a DC/NOC versus on Azure or other cloud providers.

dang• 8 years ago

You can't post attacks like this to HN, and abusing the site this way will eventually get your main account banned as well.

https://news.ycombinator.com/newsguidelines.html

empath753• 8 years ago

You’re not going to be able to just flip a switch and do that migration instantly. You have time to retrain people and some people will adapt better than others.

jroseattle• 8 years ago

Your employees need skills that are useful and in demand. They need those going forward, whether you close your data centers or not.

I'd suggest you be upfront with them. Use this as a pro-active way to show you want them around, but it's not business-as-usual. The good ones will see this as an opportunity for the long term, while others may view this as a time to move on.

To reinforce plans, show them what skills you need after the move. This will give a north star to motivate those who want career mobility.

j45• 8 years ago

The implementation of hybrid cloud support is the key thing to consider pursuing both from a strategic and technical perspective. I have provided complex hosting for large corporations for more years than I like to remember and it is the only thing of lasting and permanent value for a few reasons:

Having a completely migratable cloud setup, between any cloud provider, or back to your own environment (OpenStack, etc), is the single most important long term investment to consider for your stack.

Your situation sounds very advantageous in having the expertise ready to containerize machines, and dockerize applications that may not be. This too, is a very marketable skill for people who may be leaving.

Historically, connectivity has driven location of data. Popularity has oscillated between on-premise vs client-server setups (cloud). Currently, the cloud is in vogue, for many great reasons. The pendulum though seems to have historically swung both ways.

While network speed will continue to increase, and computing power will continue to increase, other factors may play into why a corporation wishes to keep it's data in-house, be it political, security, industry practices, or a sudden wish to change directions due to a failure too many of a cloud provider.

The cloud providers do a very good job of making it easy to get sucked into their world.

It would be interesting if you followed up here with the decision you made and why. Not enough thought seems to be out in the open about these types of decisions, let alone at your decisions.

srah763• 8 years ago

You can reach out privately to other companies and leaders you know if they may have a position for them. HR can also help find positions for people, that’s part of their job.

What you can’t do make a decision that’s good for a very small number of people at the expense of everyone else in the company if you’re a leader.

true_tuna• 8 years ago

This sounds like a very exciting time, the work is changing, the very economics of the business are changing. Remember to lead throughout this transition. Communicate well, frame the transition in a positive way and take care of people. Do not allow your exuberance at the potential cost savings blind you to the pitfalls in a project of this magnitude. The transition will be harder than you think, take longer and cost more. That being said, it’s probably worth doing. Along the way you must remember that your employees are a super important part of your business so treat them accordingly.

Offer training. The automation work is more gratifying and valuable anyway. You’ll be offering them a step forward. Some will take it, some will move on. Even those who move on may find that the change catapults them forward as well.

I trained a colleague in cloud automation in two months. Admittedly he is very capable and committed, but you’ll find that in some of your people too. He’s now worth more than anyone I could have hired. You have the opportunity to elevate your existing employees significantly. Embrace that opportunity.

PM me if you’d like to see the training materials I’ve put together.

throwawayacct4q11• 8 years ago

I would love to see those training materials! I don't see any contact info, but maybe you could shoot me an email to the email in my profile?

Ask HN: If I Close My Data Centers, What About the People/Jobs Lost?

Related Stories