3 ms·

Okay, I wrote out a whole breakdown of everything that's wrong with this post, but after I re-read it, it came across as so harsh that I've just deleted the lot

Okay, I wrote out a whole breakdown of everything that's wrong with this post, but after I re-read it, it came across as so harsh that I've just deleted the lot. TBH; the only people who would have agreed with me knew my points anyway so bother? I felt like as this is my specific area, that I have a kind of responsibility to people who read misinformation like this to help see through such stuff. It's hard to do for me without getting kind of angry though; opinions like this is why I end up having to deal with 800k/month aws bills and 3 hour deploys.. Either way; regardles of me -- please, people -- if you think that the 'typical journey' of implementing your own infrastructure and migrating a legacy application to run on it is ANYTHING like the description in this blog post, then please take it from me as someone who moves horrible legacy codebases into CD for a living, that you should perhaps seek some alternative advice. Suubu; I'm sorry, I'm not trying to be mean but your typical' private cloud journey is complete and utter horseshit.

deleted 10y ago
[deleted]
oarsinsync 10y ago
> TBH; the only people who would have agreed with me knew my points anyway so bother? Can you please actually elaborate, or it defeats the point of your entire post. While the rant may have helped you, I don't know you, I don't your history, and this post doesn't encourage me to go through your post history to find it. At the same time, OP's post filled me with a slight sense of dread as I'm about to go into a private cloud environment and wondered if I was making a mistake. Your post has certainly calmed those nerves. Actually having some meat with the mustard would help more. Thanks in advance!
- cyberpunk 10y ago
  Well, I don't want to pick the whole thing apart because I've been a bit too mean already, but the 'typical' process of private cloud in that post is bullshit. Lets make some assumptions on this gig you're starting then, we'll imagine you're going into some job at a place which has a horrible legacy codebase (lets' go medieval assume struts and oracle 10, deployed with some ancient bamboo/rpm concoction which takes forever and always dies and the existing ops team barely keep the lights on, let alone are capable of keeping up with the rate dev is trying to let the business move..). So you land. They've got a fresh budget, a load of bearded scala devs who are rewriting the whole thing as microservices and words like "ISB" and "ASYNC" are being thrown around. Hell, someone even mentioned elixir in the bar on your welcome drinkies. You're going to drag this horrible monster into the new world, but to get there and to a better arch you're going to have to replace it a bit at a time, and while that happens the code that's making all the money needs to be maintained, and it needs to change faster. And you're going to do this on prem. So. You land. On prem, ooooeh baby. Realise: the pain you're going to have is not going to be how you instantiate vms to run the apps or spin up loadbalancer IPs or whatever the arse else infra wise -- AWS will do all that right away for you for sure, while working out how to get a bunch of tin to do it will take longer, but it's like getting into first gear slightly faster than the guy beside you on a F1 race -- in the long run, this isn't where the time is going to be spent. Lets say you're the ops dude instead, how do you move a few hundred hand built centos and java boxes to some kind of api based provisioning thingy with no config management? Yeah well.. There are a lot of options, if you're the one building it out, tbh the best choice for the infra part of the provisioning is just to pay someone to make this their problem. Redhat. Vmware. Whoever does Proxmox. Whatever. You'll lose E-Penis points but who cares your job is to help the business work faster. Even if you have do it yourself, there is a large ecosystem around things such as openstack or proxmox or smartos or whatever cobbler and so on, and this stuff is pretty friendly, it won't take you THAT long. Hire a contractor for a bit. Blammo. The post talks about doing 'compute' then 'storage' and 'network' then 'stateless monoliths' and so on. Whatever. That's not reality. Why is the business paying for this? They want to be able to iterate quicker! CD is a tough goal with a legacy codebase, but they got used to agile and hell if it's not going to get faster -- the job is to enable that in any way possible, the tricky part of that is not going to be how you deal with infra, it's how you get the code through a pipeline and deploying painlessy. Infra is a pain point. Legacy environments are fragile as hell and good operations folks are few and far between, and most of them are undervalued and a bit weird. -- but you personally, oarsinsync, are going to better off on prem for a few simple reasons in that world: 1) Total Ownership: Something goes titsup? Yeah, your team owns the entire show up until your ISP. Network borks? Storage slows down? It's all yours. Dig in. AWS develops cross-az latency? Log a ticket and 2 days later when they respond you'll have already forgotten it happened. Explain that to the business. 2) Perf: Don't believe the rubes; you'll be quicker on your own gear if only because you can move your noisy VMs to sep machines, set various limits/quotes/throttles that you can't on a public cloud, and you're not sharing spindles with 300 mongo vms. 3) Expierence: It's not exactly a business goal, but you'll learn more when you're having to stace some jvm at 3:00am and crying into a toilet than if you're just bouncing instances and getting away with shit code. If you just outsource all your problems forever you'll never be able to have an opinion on them, even if that opinion is just "I never want to use RAC again" or "mongodb is death" or whatever..
kesor 10y ago
> opinions like this is why I end up having to deal with 800k/month aws bills and 3 hour deploys.. How exactly would a "private" cloud save you from these clearly cultural problems?
- cyberpunk 10y ago
  It's pretty easy for a team to go rogue and if they have their own AWS account end up in a total mess and solving their problems with hardware. I've been at places where the exact same problem is being solved by several different teams and I think a lot of that was down to that the availability of AWS for instance allowed them to go total silo and act almost like a vendor to the other teams which consumed their apis. Going back on prem really helped, even if maybe it was just the "group project" to do it. Afterwards though I think there's a bit more buy in simply because the company has total ownership of the stack. Some team starts thrashing resources there's a bit more knowledge sharing and the stakes are higher (at least, the resources aren't limitless). You're running your service in AWS and another team consumes it, then RDS starts getting slower what can you do? Blame AWS when you get a nasty call from a PM and go to lunch... On prem? You're probably not far from the DBA who can explain what's happening and you can grab the consumer of your service to help too. It seems to just open thing up a lot.. YMMV. I've seen a definite improvement culturally though.

deleted 10y ago

[deleted]

oarsinsync 10y ago

> TBH; the only people who would have agreed with me knew my points anyway so bother? Can you please actually elaborate, or it defeats the point of your entire post. While the rant may have helped you, I don't know you, I don't your history, and this post doesn't encourage me to go through your post history to find it. At the same time, OP's post filled me with a slight sense of dread as I'm about to go into a private cloud environment and wondered if I was making a mistake. Your post has certainly calmed those nerves. Actually having some meat with the mustard would help more. Thanks in advance!

cyberpunk 10y ago
Well, I don't want to pick the whole thing apart because I've been a bit too mean already, but the 'typical' process of private cloud in that post is bullshit. Lets make some assumptions on this gig you're starting then, we'll imagine you're going into some job at a place which has a horrible legacy codebase (lets' go medieval assume struts and oracle 10, deployed with some ancient bamboo/rpm concoction which takes forever and always dies and the existing ops team barely keep the lights on, let alone are capable of keeping up with the rate dev is trying to let the business move..). So you land. They've got a fresh budget, a load of bearded scala devs who are rewriting the whole thing as microservices and words like "ISB" and "ASYNC" are being thrown around. Hell, someone even mentioned elixir in the bar on your welcome drinkies. You're going to drag this horrible monster into the new world, but to get there and to a better arch you're going to have to replace it a bit at a time, and while that happens the code that's making all the money needs to be maintained, and it needs to change faster. And you're going to do this on prem. So. You land. On prem, ooooeh baby. Realise: the pain you're going to have is not going to be how you instantiate vms to run the apps or spin up loadbalancer IPs or whatever the arse else infra wise -- AWS will do all that right away for you for sure, while working out how to get a bunch of tin to do it will take longer, but it's like getting into first gear slightly faster than the guy beside you on a F1 race -- in the long run, this isn't where the time is going to be spent. Lets say you're the ops dude instead, how do you move a few hundred hand built centos and java boxes to some kind of api based provisioning thingy with no config management? Yeah well.. There are a lot of options, if you're the one building it out, tbh the best choice for the infra part of the provisioning is just to pay someone to make this their problem. Redhat. Vmware. Whoever does Proxmox. Whatever. You'll lose E-Penis points but who cares your job is to help the business work faster. Even if you have do it yourself, there is a large ecosystem around things such as openstack or proxmox or smartos or whatever cobbler and so on, and this stuff is pretty friendly, it won't take you THAT long. Hire a contractor for a bit. Blammo. The post talks about doing 'compute' then 'storage' and 'network' then 'stateless monoliths' and so on. Whatever. That's not reality. Why is the business paying for this? They want to be able to iterate quicker! CD is a tough goal with a legacy codebase, but they got used to agile and hell if it's not going to get faster -- the job is to enable that in any way possible, the tricky part of that is not going to be how you deal with infra, it's how you get the code through a pipeline and deploying painlessy. Infra is a pain point. Legacy environments are fragile as hell and good operations folks are few and far between, and most of them are undervalued and a bit weird. -- but you personally, oarsinsync, are going to better off on prem for a few simple reasons in that world: 1) Total Ownership: Something goes titsup? Yeah, your team owns the entire show up until your ISP. Network borks? Storage slows down? It's all yours. Dig in. AWS develops cross-az latency? Log a ticket and 2 days later when they respond you'll have already forgotten it happened. Explain that to the business. 2) Perf: Don't believe the rubes; you'll be quicker on your own gear if only because you can move your noisy VMs to sep machines, set various limits/quotes/throttles that you can't on a public cloud, and you're not sharing spindles with 300 mongo vms. 3) Expierence: It's not exactly a business goal, but you'll learn more when you're having to stace some jvm at 3:00am and crying into a toilet than if you're just bouncing instances and getting away with shit code. If you just outsource all your problems forever you'll never be able to have an opinion on them, even if that opinion is just "I never want to use RAC again" or "mongodb is death" or whatever..

kesor 10y ago

> opinions like this is why I end up having to deal with 800k/month aws bills and 3 hour deploys.. How exactly would a "private" cloud save you from these clearly cultural problems?

cyberpunk 10y ago
It's pretty easy for a team to go rogue and if they have their own AWS account end up in a total mess and solving their problems with hardware. I've been at places where the exact same problem is being solved by several different teams and I think a lot of that was down to that the availability of AWS for instance allowed them to go total silo and act almost like a vendor to the other teams which consumed their apis. Going back on prem really helped, even if maybe it was just the "group project" to do it. Afterwards though I think there's a bit more buy in simply because the company has total ownership of the stack. Some team starts thrashing resources there's a bit more knowledge sharing and the stakes are higher (at least, the resources aren't limitless). You're running your service in AWS and another team consumes it, then RDS starts getting slower what can you do? Blame AWS when you get a nasty call from a PM and go to lunch... On prem? You're probably not far from the DBA who can explain what's happening and you can grab the consumer of your service to help too. It seems to just open thing up a lot.. YMMV. I've seen a definite improvement culturally though.