3 ms·

> 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

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

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