IrishBearHawk

joined 7 months ago
[–] [email protected] 8 points 7 months ago* (last edited 7 months ago)

The real lesson here is don't re-invent the wheel. There are plenty of companies that have fully fleshed out auth/login solutions for you already. I never cease to be amazed with how many companies insist on building shit that already exists and come up with an obviously far shittier implementation.

[–] [email protected] 20 points 7 months ago

Is it the denvercoder one?

checks

That's it.

[–] [email protected] 32 points 7 months ago* (last edited 7 months ago) (10 children)

This happens all the time and it's a pretty simple answer,: the engineering chops of the team may not be up to snuff. Too many old school sysadmins were handed "Cloud/DevOps/SRE" titles and didn't update their skills, it's why a lot of top companies expect their SWEs to manage resources. Hate to say but if your team isn't capable of scaling things using all the additional options cloud providers (and open source tools) give you, many at no additional cost on top of compute/data transfer, to scale your operations to optimize for cost, and also have the ability to build things in a way that avoid vendor lock-in (IaC/Terraform/containerization, along with having someone who actually understands Cloud Architecture), then you may need better engineers. 9/10 chance your team "migrated everything to cloud" as a 1:1 match with what you were running in a DC and then went shocked_pikachu when it was more money. Additionally, have y'all factored in all the time/money spent on maintaining the server hardware, power, DC cooling, etc. too? Cloud providers just plain have better engineers than any average company, especially ones doing the whole "this is more!" dance post cloud migration.

You can absolutely do the whole 1:1 migration to cloud, but always expect things to balloon at least a bit post-migration, but then immediately work on learning all the tools these providers give you to tighten down your cloud spend. How much are you spending on disk? Would bucket storage be cheaper? RE: Containers, even if you DO go that route, do you really need Kubernetes, which will come at an additional monetary and also maintenance cost? The likely answer at least initially is a big fat "no". Are you running every VM, even lower envs, 24/7? Is that required? If your services are not stateless, work to make them such so you can learn about scaling in the cloud, which can even be done w/ VM-based services.

I'm not even going to touch on how much more agility using cloud vs a DC gives you.

This all may sound a bit aggressive, but it's not meant to be. It's just, when you've seen this same complaint many times, ya know. This is a learning opportunity to figure out so much about how to build your environment using relevant cloud services.