Earlier quoted context omitted.
> building your own data center? Or data centers, plural. Now, seriously, if you can beat their reliability, you are in the wrong business. I'll pay you to host my services.
Amazon offers one nine of availability. I'm currently getting three on self-hosted equipment for a high-growth startup, with tens of thousands of concurrent users getting sub-second response times. The key is having intelligent staff who have a deep understanding of your specific environment. This guy's argument completely discounts the value of that - he's essentially saying that using PHP over writing in C is bette…
Delusions that companies have about the cloud
61–67 of 67 posts
Re: Delusions that companies have about the cloud
#62Earlier quoted context omitted.
if you have to prepare for enough redundancy for a location to go down, then the cloud works just as well. I'm really not seeing the distinction here.
It's very difficult to buy a high bandwidth, low latency link from one AWS availability zone to another to ensure that my databases are synced properly such that if one of them goes down the other will stay up, and there will be minimal/no loss of data. But I can buy colo space from two different companies in two different but close cities and gain a lot of redundancy. Furthermore some kind of systematic problem that…
Re: Delusions that companies have about the cloud
#63Earlier quoted context omitted.
It's very difficult to buy a high bandwidth, low latency link from one AWS availability zone to another to ensure that my databases are synced properly such that if one of them goes down the other will stay up, and there will be minimal/no loss of data. But I can buy colo space from two different companies in two different but close cities and gain a lot of redundancy. Furthermore some kind of systematic problem that…
That makes sense, and I agree, but this seems orthogonal to cloud vs non-cloud. If there were two cloud providers in different cities, and they allowed you to buy a good link, then the cloud meets this need too.
The idea of the cloud is that "I just need a box that's SOMEHOW connected to the internet and I don't really care about the details of how precisely" which is fine for a great many use cases.
But there are plenty of use cases where the above assumption does not hold. When it does not hold, using the cloud isn't the no-brainer idea that the author of the article makes it out to be.
Re: Delusions that companies have about the cloud
#64Since corporations want to cheap out and host their previously secure physical boxes all on one server with a wide open console and management system to get into this has made pentesting much easier.
I especially like projects like Whonnix, where fools construct this complex layer of virtual machines on top of virtual machines. It's like taking the shit sandwich of blobs and bugs that is x64 architecture and ethernet drivers, and building a whole mountain of shit right on top then calling it secure.
The cloud definitely has some benefits, but if you're handling finance or require serious privacy better shell out for some OpenBSD racks, virtualize the routing table and set up pf firewalls to isolate the network with real actual isolation and not pretend magic isolation. Best of all there's just one operating system, not three of them piled on top of each other.
Re: Delusions that companies have about the cloud
#65Earlier quoted context omitted.
That makes sense, and I agree, but this seems orthogonal to cloud vs non-cloud. If there were two cloud providers in different cities, and they allowed you to buy a good link, then the cloud meets this need too.
Yes and no. They won't let me put a link in and have the cross-connect plug directly into MY switch(es) because a core tenent of "the cloud" is "we reserve the right to move your instance whenever we'd like to" which is anathema to the idea of me controlling my machines, switches, routers, internet access, etc. The idea of the cloud is that "I just need a box that's SOMEHOW connected to the internet and I don't reall…
I think your idea of "the cloud" is narrower than mine.
Re: Delusions that companies have about the cloud
#66Earlier quoted context omitted.
Yes and no. They won't let me put a link in and have the cross-connect plug directly into MY switch(es) because a core tenent of "the cloud" is "we reserve the right to move your instance whenever we'd like to" which is anathema to the idea of me controlling my machines, switches, routers, internet access, etc. The idea of the cloud is that "I just need a box that's SOMEHOW connected to the internet and I don't reall…
Here at Disney we both control our machines, switches, routers, internet access, etc; and we use CloudStack for an internal cloud. I think your idea of "the cloud" is narrower than mine.
But "the cloud" as the author describes isn't a thing that you can peer into and determine it's inner workings, it's more of a black box that you can run an instance on. AWS, Rackspace Cloud and all the folks who sell VM instances don't publish all the data necessary or give you "hooks" into the network infrastructure where you'd need to really make a reliable system.
That's the whole point of the cloud. I pay you a very small amount of money for a VM that I rent by the hour and I don't WANT to know the details. Once you start learning (or having opinions) about the underlying network topology and everything else you're not "cloud" anymore, you're something else. What's the right name for it? I don't really know. But I would argue that it's not "cloud"
Re: Delusions that companies have about the cloud
#67The cult of the cloud is great business for me since I specialize in finding VMM and KVM bugs. Since corporations want to cheap out and host their previously secure physical boxes all on one server with a wide open console and management system to get into this has made pentesting much easier. I especially like projects like Whonnix, where fools construct this complex layer of virtual machines on top of virtual machi…
Would be interested in VMM bugs with respect to VMware.
Thanks.
Ron (ron.szpak@gmail.com)