In March SONN LLC launched a new company, Router and Switch Analysis (RaSA) focusing on helping companies to design and execute test plans for equipment they are looking to acquire. RaSA is also doing consulting and training on how to properly organize and execute a test of multiple vendors.
CDN
A short review of DediServe
I last mentioned DediServe a week or so ago, commenting on their amazing support (it really is 24×7).
Since then I have had a chance to use their products more in depth and gather enough knowledge for a short review/overview.
DediServe offers Cloud based servers, CDN (the two products I am working with) and other products that I am not working with and will not cover in this review.
Cloud VDC:
I have both a single node VDC in London that I am using to replace a aging co-located box in Texas and a 15 node VDC in Texas that I am working with to see if I can use it to save money over AWS.
DediServe offers many features that go above and beyond what AWS can and at a great price. My current estimates are that using AWS to do the work I need to do would cost around $3500 US a month, from DediServe it is around $600. DediServe offers static IPs and static resources that you can reconfigure on the fly while AWS is more of a on-demand type service. You can get static IPs with AWS but it’s no where near as simple as it is with DediServe.
DediServe prides itself in offering robust, HA platform that is architected as a replacement for ‘traditional’ mission critical infrastructure. Blades, Netapps, 10G networking and other features you don’t find in AWS.
Here is a quick list of Pros and Cons as I see them with DediServe vs AWS (I know it’s a somewhat unfair comparison but it’s what I have been working with).
DediServe Pros:
Support:
Amazing support infrastructure: The team has given me %110 and still continues to work with me on special requirements. I am working with everyone from their support department to C-level employees, everyone is respectful and helpful.
Cost:
literally 1/4 or less of the cost of a similar AWS setup with a fixed cost (vs AWS pay as you go model)
Stability:
I have seen no issues with the functionality of my 24×7 machine in London, it has been rock solid (the 15 node VDC is in a constant flux as I am trying to use it for something it was not designed for).
DediServe Cons:
Deployment:
Standard node turn up time is slower then AWS, a AWS node can be deployed in about 90 seconds, where as a standard (note: DediServe is offering me ways to make this match using local disks) node deployment on DediServe is around 8 minutes (2G RAM, 70G Disk). The solution they are offering me would bring this down to about 90 seconds at a slightly increased cost.
Billing:
AWS is a pay-as-you-go environment where if needed you can cut your costs by shutting down machines and only deploying them when needed. With DediServe you pay for your hardware on a monthly basis. (Note: this can also be a Pro as you have a known cost).
Summary:
I really like DediServe, fantastic folks who go out of their way to support my non-standard use of their products.
DediServe
I have recently had the pleasure of working with a very nice and supportive company in Ireland named DediServe. I am currently using them for some Cloud Infrastructure and have been very happy with them. I am currently moving most of my world to the cloud and only maintaining 1 physical infrastructure location. I have a few VPSs from other providers but the support/quality has been sub par, usable for say a slave DNS server, but not much more.
You can visit them at www.dediserve.com
Launching a CDN reseller/aggregator service.
One of my more recent projects has been the creation of a CDN reseller/aggregator portal. A lot of time has been invested in the project to give customers not only what they need now but what they will want and need later. One of the nice things about having access to a GLB tool is the ability to “route” incoming traffic to the best destination. Sometimes the best destination is based on locality, but other times it is based on performance.
My current project is more of a shell for others to work with and see the power of the tools that XDN provides.
If anyone is interested in looking at it, drop me a line at the usual places.
Hi Tim.
Information Sharing, CDN Federation and the IETF CDNi Working Group.
When I look at the Internet as a whole, I recognize that while there are standards, those standards are meant to help people create hardware/software that will interoperate with others. Standards that are meant to avoid distribution of necessary information due to it being classified proprietary are not as valuable as those that work to define a process.
Currently the CDNI group is working partly to satisfy the providers who are concerned that giving out too much information will allow other providers to use that information in an underhanded way. I do not agree with this direction.
In order for a federation to work, all of the providers in the federation must have something to offer. This means these providers are valuable to the ecosystem. If a provider is advertising x while only having y (capacity/features/etc) then the provider is not a trustworthy addition to the federation.
That being said, my experience from negotiating peering, dealing with DoS and DDoS attacks and other networking issues since the early 90′s has taught me that there will always be a back channel for communication between entities that rely on each other. This will have to be true in CDN Federation.
I am going to recount my view of being in the middle of one of the more famed DDoS attacks. TL;DR – MafiaBoy took down one of my customers and working with my peers at other ISPs was why the damage was limited.
In February of 2000 there was (the first) high-profile DDoS attack on multiple Internet properties including Amazon, eBay, Buy.Com, Onsale and others. During this time I was working for Exodus Communications as a Sr. Network Engineer.
The whole time the engineering and security teams from the different ISPs hosting the providers under attack (myself included) were freely sharing any information possible to help and be helped dealing with the situation. This information included things like router versions, hardware, packet captures, filters used/tried, etc.
I believe this is one of the main reasons the attacks were only effective for short periods of time. This was not the first or last time that these types of discussions happened.
The future of CDN Part 1
A little while ago I left my cushy job at Cisco Systems and went back to the gritty world of startups. Â For those of you who don’t know I’ve done 3 startups in my life: Â Exodus Communications (Acquired by Cable & Wireless), Procket Networks (Acquired by Cisco) and now 3Crowd Technologies, INC.
3Crowd brings a new level of control to Content Delivery Networks; offering the CrowdDirector product with the ability to balance your traffic between contemporary CDNs, Federated CDNs and/or your own CDN (Created using our CrowdCache software).  By offering these tools we are helping content providers to better control their cost/performance ratios, moving traffic around as needed based on performance needs (or a lack of performance).
One of the core differentiators with the 3Crowd CrowdDirector solution vs other solutions is the ability to use the system to do exactly what you are doing today and then add extras as wanted/needed.  In a sense, you can use 3Crowd as a resilient DNS/HTTP redirector system with your current CDN (or even non CDN) assets.  If you find another CDN or put up some of your own Caches you can then use the 3Crowd CrowdDirector to move some or all of your traffic there.
More Later.. 