we do use forward secrecy for all our client facing services and of course accept https only. we are also looking at upgrading from 128bit to either 256bit or even 512bit to offer a further 'extended runway' against future direct decryption :)
three points:
1. apathy is the friend of all such measures
2. the NSA aren't the only gig in town both in terms of agency and country and in any case have a nothing close to ubiquitous coverage
3. as hard as you might find it to believe some people do have principles and beliefs. our company was founded and has always operated in line with those of our founders. all this is nothing new. again refer to point 1 about apathy.
The Patriot act has provisions that can potentially be applied to subsidiaries of US companies abroad but not vice versa. If you think about it it would mean shareholders of companies could be pursued globally under US law just for owning shares in a US company. It's all around a bad situation right now with conflicting sets of rules and that's without a doubt.
Yes we have private VLAN functionality. We'll be expanding this to up to 8 per server shortly.
* Bring your own IP space
Yes, this needs to be manually added to our BGP sessions but isn't a problem and we do this regularly for customers.
* Redundant exterior routing (e.g. I advertise my prefix through a new provider during an extended downtime)
We have multiple redundant carriers and they failover automatically. Actually the failover happens instantaneously, even if you are actively pinging you don't even get one dropped packet :-) If you have your own private infrastructure space elsewhere we also are able to choose the preferred carrier too.
* Out-of-band access
Not sure in what context you are talking about here. If you extrapolate I can give feedback.
Yes, all cloud brokerage attempts have so far stuck to the resources and avoided trying to do any unified billing. Its really tough to accomplish.
Can you think of other areas where competing services have common open billing? Great for sure but difficult commercially. Especially when you start bringing in credit risk and other non-technical factors.
Yes this is definitely possible and a multi-vendor approach in the cloud is achievable at quite a low bar in terms of customer size. You only need to look at outages at Reddit and many others to see the benefit of that approach.
A test along the lines of the one conducted by Google against Bing would reveal the correct situation. Essentially 'seed' the registrar with some crazy domains that no-one would want (google did this with unique searches) and wait. This would be particularly effective against less popular domains which gain less interest to begin with.
If you see any of these zero value domains get registered you have your answer, or at least a very high confidence in your initial assumption.
Welcome to Hacker News, I see this is your first ever contribution.
In terms of what you say, we actually have many unique features and could no way be described as 'off-the-shelf'. We are continuing to innovate and will be launching future first-to-market features in the coming months.
Do any of those providers offer you a free choice of operating systems? i.e. install any operating system you like, any version? Or control of the full server?
There is a very big difference between a VPS where the vendor places restrictions on many things and retains full root access and our cloud servers were you have total control over the software running on your server and full root access.
Put it another way, if I gave you two servers, one dedicated, one a cloud server in our cloud. If you SSHed in, you wouldn't be able to tell me which was the cloud server and which was the dedicated server based on your control of the server. That's totally different to VPS.
Essentially you are combining the control of dedicated servers with the flexibility and transparency of cloud architecture.
Traditional VPS providers slice up large dedicated servers to share them between customers. Typically VPS providers use a container technology such as Virtuozzo to isolate multiple users on a single server from one another whilst running a single shared instance of the operating system. By contrast, our KVM technology enables every user to run their own isolated copy of an operating system of their choice, providing a greater choice of operating systems, higher performance, deeper configurability, and stronger isolation and security guarantees.
Its a cloud server. You can vary its size an re-provision at will. Also, all resources are unbundled so you can tweak the RAM for example leaving other resources unchanged. You can see a video of a cloud server being deployed at http://www.youtube.com/user/CloudSigmaCH . It takes a couple of minutes.
We are offering cloud servers i.e. stand alone servers in a cloud environment. You have complete control over the software and networking layers. So you are basically running Debian (in this case) with the same level of control that you'd have over a system installed on a dedicated server. You have full and sole root access inside your system.
Yes you are right, it is certainly easier to snoop on customers as an IaaS vendor if you keep full root access and file system visibility. I'd say that constitutes 'lazy policing' and not needed and that is certainly our experience :-)
Botnets etc. rely on free hijacked capacity not computing resources bought on an industrial scale on commercial terms. The cloud is no more prone for use as a botnet or other problematic activity than dedicated hardware. Although often touted, I've yet to hear a compelling case for IaaS clouds being any more susceptible to such use than VPS, shared hosting etc. etc.
Likewise, such activity becomes very obvious very quickly and it isn't access inside a customer's cloud server that allows you to spot such activity.
As I say, there are not real reasons not to give customers full control of their cloud servers any more than they have full control of their dedicated servers. In fact, the flexibility of the cloud makes policing it more easy than dedicated hardware without snooping inside customer servers or restricting their ability to control their computing.
In terms of administration, customers can choose to use their own in-house admins or that of a third party and many of our customers do. The point is they done have a choice, with other clouds they have one choice, the cloud vendor as the admin. That's overly restrictive and it isn't surprising why you get such concerns raised over security and control in the cloud.
Actually in our cloud there aren't any shared software resources between cloud servers which is why you can run any operating system you like. Each cloud server is a standalone entity in its own container. We feel this is a lot more secure and flexible.
With regards to IO throughput, this along with networking performance are two areas we identified and sought to address when designing and building out our platform. You might be interested to read my blog post earlier about benchmarking cloud servers and differentiating performance between clouds at http://bit.ly/a7CqV3 . Basically storage performance is one of the key differentiating factors between clouds. Again the performance has as much to do with vendor hardware and architecture choices as it does to do with fundamental cloud computing issues.
The API doesn't solve the real problem of vendor lock-in and the OpenStack API is basically the Rackspace API with all those restrictions. We posted regarding this previously at http://bit.ly/fSJZ79 . It isn't fundamentally bad but it just reinforces the same restrictive model.
It doesn't answer the fundamental points we raise regarding false constraints imposed by vendors such as yourselves (not specifically aimed against Rackspace) like:
- bundling of resources
- fixed instance sizes
- software level control by the vendor
- filesystem visibility by the vendor
etc.
We have taken a different approach. Our point is there are many approaches and implementations to IaaS and the current larger ones impose many restrictions on customers and are much more like traditional hosting type models on something that can be a lot more open and flexible. We are talking about the true sense of 'open'.
Why not allow customers to have control of their operating systems, networking and server instance sizes? The underlying virtualisation platform supports it. That means the vendor is actually choosing to impose those restrictions on the customer in their software. We choose not to. Its just a different approach.
Yes it does and the critical difference is that the customer doesn't have control over when instances are yanked. Likewise servers/drives aren't persistent so you can't have nodes hibernating and then bring them in response to pricing.
Our system is designed to let you control when servers are turned on or off in order to perform orderly computing. Likewise the fact that the servers and drives are persistent allows you to shut them down and back up again over peak times and keep data persistent. This is great if you are doing large jobs like 3d rendering for example.