These forums are read-only!
Migration to Rackspace Cloud: Q&A with Mark Interrante and Rackspace
  • (NOTE: An update and addition to the information in this post is further along in the thread, at this comment.)

    First of all, I want to apologize to the Slicehost community. Yesterday's announcement did not include enough detailed information about the migration to Rackspace. In hindsight, this is now obvious to me and my fellow Rackers. We were eager to start a discussion about our product direction and we recognize that without providing enough specifics, we caused frustration and annoyance for many of you. As you can imagine, we're having a lot of discussions internally here at Rackspace about what we've learned from this, so we can do better going forward.

    We don't have all the answers yet, but the first version of our Q&A is below. We intend to build on our detailed plans using your feedback. Thanks to those who have already commented in these forums; please continue to do so.

    Here's our philosophy on this change and what we commit to:

    • We intend to make the move as painless as possible for you. We're working on one-click-conversion tools to automate the process for you. We're also working on trial accounts specifically for Slicehost customers. More to come on that in future updates.

    • We believe this change will be economically beneficial (i.e., lower cost) for most customers, since the utility-based pricing model will result in lower monthly fees for the majority of usage patterns we see.

    • We will provide as many comparable features to current Slicehost as possible -- plus we will add new features that will hopefully be of value to you. There’s more information in the Q&A below.

    • We truly believe this change will be in the best interest of Slicehost customers over the long term. A big reason we purchased Slicehost was to learn from their technology and their customers so we could build up the Rackspace Cloud solutions to the Slicehost level of excellence. We want to retain or improve your product experience, not make it worse.

    We will share more about timing as the plans come together. There are no changes happening that will impact Slicehost customers in the next 30 days. We’re going to take our time with this transition, so that we make sure to do this right.

    We have huge plans and are making substantial investments in Rackspace cloud products. We really believe that we can make it a good option for Slicehost customers. We ask you to stay with us and check out our updated products as they get released over the coming months. We want to earn your business, and we ask you for that opportunity. Meanwhile, we will keep you updated as our plans develop.


    Slicehost Transition Q&A with Mark Interrante

    How hard will the migration be?

    We intend to make the move as seamless as possible. There are several changes that will happen in preparation to merge into Cloud Servers, but we will work to minimize the impact on our customers. The final conversion from Slicehost to Rackspace will be managed via a one-click conversion tool that will automate the conversion process. Throughout this Q&A, we detail the additional specific changes.

    Are you increasing prices?

    Raising prices or increasing revenues to Rackspace is not why we’re making this change. In fact, we expect the vast majority of customers to pay less. The Rackspace Cloud Server offering is cheaper; its utility-based pricing starts at 1.5 cents per hour, and bandwidth is billed at $0.18/GB/out and $0.08/GB/in. Toestimate your costs, please use our pricing calculator. Most customers average far less than the “break point” (~60GB – 44 out / 14 in would equate to $19.99/mo for a 256MB slice). If you use less bandwidth than that, the utility-based model will save you money. For higher bandwidth legacy Slicehost customers, we are investigating a bundled bandwidth option for Cloud Servers.

    How will my billing change?

    As a Rackspace Cloud Servers customer, you will have the ability to add and delete servers as needed and only pay for the time the servers exist in the system. Additionally, the pricing model is different with Rackspace Cloud Servers: bandwidth is not bundled – it is $0.18 out and $0.08 in. Please see the Rackspace Cloud Servers pricing page for more information, which includes a pricing calculator.

    Will my slices have to move to another Data Center?

    For some of you, yes. Since our St. Louis (STL) data centers (DCs) are not operated by Rackspace, we will be transitioning STL slices to one of our Rackspace DCs. Rackspace DCs have more space, more control and house newer, faster servers. We’re investing a lot in our core data centers, so we expect you’ll be pleased with the results.

    Our intent is for this migration to be easy and function similar to that of resizing a Slice. The major difference of this move may mean a change of IP address for our STL-A and STL-B customers. We understand that our customers rely on IP addresses in their interaction with our services and in many instances use IP addresses in interactions with their own customers as well. Changing IP addresses can be a very difficult undertaking depending upon how applications have been coded and how services are provided. Unfortunately, the IP addresses in STL either belong to the data center operator or conflict with IP space elsewhere within the Rackspace ecosystem. Over the coming months we will be investigating ways to help customers who anticipate problems with changing their IP addresses. While we do not have the final solution to overcome this obstacle we are investigating options such as: advance allocation of future IPs, use of Load Balancing as a Service to smooth the transition, and dual provisioning IPs to assist with testing among others.

    We expect to start the migration out of the STL DCs in Q3 2011. We’ll be sure to post more information on the forums as we get closer to June/July. As we finalize these plans, we will share the latest details, starting with an FAQ in a new thread.

    What features will we get, and which features will we lose?

    Today’s Slicehost product and the future Rackspace cloud products have substantially the same core functionality, but there are a few differences, including:

    Downsize Slices – Because of various differences in the image formats, it’s not technically feasible for us to support this feature. However, we expect you’ll find there are advantages to using XenServer. It gives you more control. Its VHD format allows you to choose the file system of your choice (ext3, reiserFS, etc.), have full control over your kernel, and over time add block storage.

    Some slice sizes will no longer be offered – Specifically 384MB, 768MB, 1.5GB, and 3GB. Rackspace Cloud Servers operates in size factors of 2x, starting from 256MB to 15.5GB. We will map your existing Slicehost packages into the nearest equivalent Rackspace cloud packages. In less than 10% of Slicehost instances, there is not a direct Rackspace equivalent. If you currently have 384MB, 768MB, 1.5GB, and 3GB Linux slice sizes, you will be upgraded to a Cloud Server with slightly more RAM.

    In most instances, the expected monthly cost (even with the upgraded Cloud Server sizes) will be slightly lower than your current pricing (depending on bandwidth usage). The table below shows the current Slicehost instance compared to the equivalent Cloud Servers instance and the associated costs for each. This calculator will provide an easy way to determine costs based on your specific bandwidth needs.

    Slicehost Sizes and Costs
    256MB $20/month
    384MB $25/month
    512MB $38/month
    768MB $49/month
    1GB $70/month
    1.5GB $100/month
    2GB $130/month
    3GB $190/month
    4GB $250/month
    8GB $450/month
    15.5GB $800/month

    Rackspace Cloud Server Sizes and Costs*
    256MB $.015/hour ($10.95/month)
    512MB $.03/hour ($21.90/month)
    1GB $.06/hour ($43.80/month)
    2GB $.12/hour ($87.60/month)
    4GB $.24/hour ($175.20/month)
    8GB $.48/hour ($350.40/month)
    15.5GB $.96/hour ($700.80/month)

    *Bandwidth additional $.18/G out & $.08/G in

    Backups are independent of your slice

    In the Slicehost model, backups are stored locally. In the Rackspace Cloud model, backups can be stored independently. This allows the backup to be preserved even after deleting the slice.

    As @freelock (a Slicehost Customer) said:
    @KnightlyComputing you do have to explicitly turn on the backup service, and it was a bit tricky to find, but out of the gate it's the same as Slicehost - automatic daily and weekly, plus on demand.

    But the big difference is you can name a backup and store it in CloudFiles, and have as many of those as you want. And then you can use those as the base of a new instance! This alone is the biggest reason we're happy with CloudServers -- it's reduced the provisioning time from 2 hours of configuration to 5 minutes!

    We do have to rsync the server over to our customer's accounts, but that still takes a lot less time than setting up all our tools fresh again.

    Product Portfolio

    Rackspace is in the midst of major investment and build out of its cloud products, and this will provide a host of new options to Slicehost customers. New services to Slicehost users would include Cloud Files (and backups to Cloud Files – detailed in this Q&A), Cloud Load Balancing, hosted email options, hosted calendars, hosted SharePoint, managed cloud, backup/virtual drives to the cloud (Jungle Disk) – all from Rackspace.

    Finally, as we finish the transition to OpenStack, even more features and functionality will become available. See Mark’s post.

    What will happen to the Slicehost SliceManager? What’s the plan for Control Panels?

    At some point, SliceManager will be retired and replaced by the next generation Control Panel we are currently building. It’s based on the technology from our recent acquisition of Cloudkick, along with the experience we’ve had with Slicehost. It will be fast and responsive, expose even more functionality, and be designed for ease-of-use. In addition, monitoring will improve significantly as we incorporate Cloudkick monitoring technology.

    What are the plans for the Slicehost API, particularly DNS?

    At the point you transition to Rackspace cloud, you begin using the Rackspace API endpoint. There is additional functionality scheduled to allow for DNS management through a Rackspace programmatic interface. For Cloud Server customers, we have developed a DNS as a Service offering currently in private beta. Stay tuned for more details in future.

    How will this change be rolled out? What is the timeline?

    Nothing that directly impacts Slicehost customers will occur in the next 30 days. We hope to complete all the transitions in the three-to-twelve-month timeframe (to be complete by May 2012). Once we automate the migration process, we’ll announce that the migration period has opened, and you can choose when you want to migrate.

    Will Slicehost support IPv6?

    No. The conversion to IPv6 requires additional code to handle different types of IP addresses. The timing of IPv6 is one of the things that’s driving this change. Rackspace Cloud Servers and the OpenStack code will support IPv6.

    I have more than one slice with Slicehost, will they all transition at the same time?

    Yes, your account will be moved to the Rackspace Cloud along with any remaining Slicehost balance for all slices.

    What will happen to my Slicehost account balance?

    All account balances (positive or negative) will be transferred to your new Rackspace Cloud Servers account.

    Rackspace has stated that Cloud Servers will transition to XenServer – is this true for Slicehost?

    Yes, we will shift our hypervisor to Citrix XenServer from our current Open Source Xen, which we call “Xen Classic.” XenServer is experiencing strong adoption by our customers and partners and is the hypervisor we currently use for our Windows offering. Standardizing on one hypervisor will ensure a smoother transition to OpenStack. We are aware of some functionality differences, including the inability to downsize a slice; however, we have weighed the tradeoffs, and feel the added benefits of XenServer, including its out of the box capabilities, management features and APIs, outweigh the drawbacks of not being able to size down.

    Please know we will be providing migration assistance for anyone who requests it, to make this transition as smooth as possible. For example, we intend to provide a one button “convert me” process within the control panel. Our commitment to Fanatical Support stands and we’ll help our customers in any ways necessary to make the migration happen successfully for them.

    Will you be offering new images?

    Over the course of the next several months, we will continue to expand our portfolio of Cloud Server images. We continually listen to our customers, and right now, RHEL 6, FreeBSD, Debian 6 are the most requested images, followed by OpenSUSE and a few others. To vote on your favorite images or submit ones that are not already on the list, please visit our product feedback forum here.

    Will I need to change my nameservers from ns*

    You will eventually need to transition to Rackspace nameservers, but that process can happen independent of your move to Rackspace.
  • I would like clarification on one point please. Will I be *required* to do a migration prior to May 2012?

    Thank you, Ken
  • By 'downsizing' does that mean that on the new system, you can't change the size of an existing server or does it mean that you can increase but not decrease (i.e. the ability to increase capacity on a machine for a specific high traffic event goes away)?
  • Thanks for posting this FAQ. It's much more informative than the email sent out yesterday. However, I still have concerns.

    The loss of IP addresses for slices at the STL-A and STL-B data centers is a MAJOR problem in your transition plans. I understand that IPs are provisioned to ISPs and data centers, but you need to find a way to make this happen for your your loyal customers. In the case of my company, we have over 250 domains pointing to our Slicehost IP address (where we host websites for lots of small businesses), so even though there will be a one-click transition for the server, there's no such thing for all the DNS updates.

    Would it be possible for Rackspace to set up some sort of proxy at the STL-A/STL-B data centers that would live on for an additional few months, allowing us Slicehost customers time to transition our DNS? There has to be a way for you to make this happen. Losing the IP addresses we've come to depend on isn't an acceptable solution.
  • Regarding switching nameservers, you say it can happen independently of my move to rackspace. Does that mean rackspace will host my DNS records *before* my slice is migrated to Rackspace? Do I currently have a Rackspace customer login?
  • Can we be provided with historical bandwidth data for our slices in order to get a better idea of what our costs are likely to be if we decide to use Rackspace?
  • Having that bandwidth data would be a huge help. Right now, all I know is that I've never gone over my allotted amount here at SH...

    But that's worthless info - if I take my total allotted bandwidth and plug it into the RS calculator, it shows me paying 2x what I'm paying now... So I really have no idea if I need to start looking at alternatives or if RS is a viable option for me.
  • Posted By: HanchorLLCBy 'downsizing' does that mean that on the new system, you can't change the size of an existing server or does it mean that you can increase but not decrease (i.e. the ability to increase capacity on a machine for a specific high traffic event goes away)?

    I also agree that downsizing is one of slicehost's best features that should be maintained. like in the case where a certain server starts to have performance issues, the slice can be upgraded, optimized, and then downgraded to test
  • The ability to do temporary size increases to handle a site getting slammed with traffic via groupon/fark/digg/whatever is important.
  • First, thank you for continuing to provide us with more information. This will help to ease concerns that RS is not paying attention to its customer base.

    A sticking point for our transition is the necessity of transitioning all servers at once. We have 8 to 10 slices depending on the month with two slices hosting several ecommerce sites, as well as the other slices hosting 20 - 200 sites each. If we have to do all of the servers and sites at the same time it is going to be a very long day and night for our systems guys with no good way to make sure its all going to go perfectly.

    It is still not quite ideal, but doing one server at a time is a lot nicer to those of use with a multiple ips and slices to deal with.


  • Good questions all, thanks much. Here are the first few answers:

    @kohudson: yes, you will be required to do a migration by May 2012 at the latest as we are migrating out of the STL-A and STL-B data centers

    @HancorLLC, @dlrust, @mattbeck: you can increase ram/hd (scale up) a server, add servers (scale out) and delete servers (scale in), you will not be able to resize down. We understand this is a core feature used by some of our customers but regrettably this functionality will not be offered once we transition to XenServer. We believe the scaling options listed above plus load balancing will allow for dealing with the situations you have all mentioned.

    @nickp: we are aware and understand the scope of the IP issue and are looking for creative solutions to it. This is one of the reasons we wanted to communicate all of this in advance of when it is actually occurring.
  • @lethe: The DNS transition happening independent of your server migration means that you won't have to change the DNS for your domains right away when you convert to Rackspace. The data for your DNS would still be on the Slicehost name servers, so you could postpone moving the DNS over to the Rackspace control panel until you're finished testing the migration.

  • @jimbattenberg: Thanks for the answers -- I'm glad you're aware of the importance of the IP issues.

    From what we've heard about the transition process, we'll be able to test out our new Rackspace Cloud servers prior to our Slicehost slices being shut off. Do you know how long we'll be able to have both servers active? Allowing customers to transition to Rackspace proactively without impacting any production applications or websites seems like the only good solution if IP addresses cannot be transferred. That will allow us to transition the DNS for all of our customers without having to try to do so all at once. (Effectively, we'll use our existing slices to proxy traffic to our new Rackspace Cloud servers, so that both the current and the new IP addresses will work at the same time.)

    Finally, if it's possible to do as I described and have both our new Rackspace Cloud servers and our existing Slicehost slices active at the same time, will Rackspace allow us to have the new servers at no cost during the transition period (say, 30 to 60 days)? I know you're in business to make money and that you can't give things away for free at will, but this seems an appropriate time and would greatly help ease the transition for many loyal Slicehost customers.

    Also, I think you meant to say "May 2012" in your reply to @kohudson.

    Thanks again for your time.
  • @wlashell - Based on your concerns I wanted discuss two distinct phases of the overall transition. One phase will not directly impact running services and only change the backend systems used to access your account. The other phase will function similar to a resize operation and will result in an interruption to service. Interpreting your comment, I believe you are asking about the second phase of the process. I have participated in a lot of migrations and definitely understand the various use cases for several smaller moves versus one single event. The way we have envisioned the process is that we will provide you a list of your current slices and the ability to select as many or as few slices as you want to move at that point in time (along with a "select all" if that is your preference). This functionality will be made available within SliceManager and will also keep track of the state of each slice (needs to migrate, in progress, or completed migration). I hope this helps you plan for the upcoming process and provides benefit to you and your business in the future.

    Thanks for your question,

  • On the question of historical bandwidth, I'll find out what possibilities exist (how much the billing system keeps and for how long, how accessible it is, etc.), and I or someone else will let you know when we know more. I didn't want the question to sit neglected, but I don't really know our billing well enough to give a definitive answer.

  • @nickp - really good idea. I don't have the authority to make that decision, but I'll take it to those that do. Probably not a quick answer here as I would image a few billing hurdles with implementing something like this (aside from the business decision)...but i like your proposal. As the answer might not be quick (or germane to this thread by the time i get it), would you mind shooting me an email? firstdotlast@rackspace? thanks.
  • @jimbattenberg, Thank you for responding to my question. However, I wasn't really asking if we had to do a migration *by* May 2012 I was asking if we have to do a migration before then. I probably should have been more clear in my question. Basically, I'm asking if we can wait until the last minute or will there be some sort of schedule where certain migrations must be performed in August, others in September, etc. Thanks.
  • @kohudson I understand your question better now. The way this will work is that we will have migration windows for customers based on their location within the data centers. Depending on where your slice resides you will receive notification and be provided functionality within SliceManager to migrate your slice(s). We will seek to provide customers as much advance notice as possible but have not locked down a specific schedule I would be able to reference for your account at this time. We do not have plans to open any of the migration windows until Q3 at the earliest. I hope this better answers your question.
  • Yesterday, at the request of whoever mans the rackspace twitter account I sent questions via email, but got no response, so I'm asking them here again.

    1) Can we get a more solid confirmation that the non-STL data center customers will be able to keep our IPs? It sounds like a yes?

    2) Will our 32bit slices migrate over or will we be forced to switch to 64bit distros?

  • Will having an existing rackspace cloud account affect the transition from Slicehost? Or will that be accounted for?
  • @mattbeck sorry for the delay in responding to your email but I can assure you we are going through the emails generated by this news and are responding to each in turn (I mention this because I am one of the people responding). The delay was caused by us wanting to finish the FAQ first so that we could stay consistent in our answers and not create more confusion. Here are the answers to your questions:
    1) non-STL data center customers WILL be able to keep their IPs - confirmed yes
    2) Your existing 32bit slices WILL migrate over. The issue is that right now Rackspace Cloud Servers do not offer 32bit images as part of their base images. This means new customers cannot select a 32bit image nor can existing customers spin up a 32bit server from a base (Non customer) image. In your case (I assume you already have running 32bit images) you will be able to spin up new 32bit servers by taking a snapshot of your existing slice and using it to build off of. Additionally, we are investigating adding 32bit options for the most popular distributions within Cloud Servers.
  • @RackspaceJeff, perfect thanks.

    I'm not worried too much about new slices. I have a mix of 32 and 64 bit slices, so i'm mostly concerned with what I have currently.
  • @RackspaceJeff, Thank you for your followup response regarding timing. However, in my opinion this is not an acceptable plan. Saying "Depending on where your slice resides you will receive notification and be provided functionality within SliceManager to migrate your slice(s)." doesn't give me much to work with. How much notice will we receive? One week? One month? Can I plan a vacation for Q3/Q4? Go to a conference? Take on an additional project? Who knows? You're telling me that you don't know so there's no way I could know.

    In addition, for those of us with more than one slice who decides what order the slices are migrated? If it's just based on "where your slice resides" then you may specify a schedule that involves migrating my production server prior to my staging server which is just the opposite of what I would choose. This is just unacceptable. You really must give all of us some kind of control over the scheduling of our migrations. Otherwise, I'm in a position where I have to go to another company just so I can exert some sort of control over my migration plan and scheduling.
  • POST EDITED: Oops, I didn't have it all quite right, so I'm taking out what I'd posted. Jeff will explain more as he's more acquainted with the process planned.

    Short version: There's a difference between the conversion to Rackspace (switching the billing over, moving between control panels) and the migration that will have to happen from some hosts (such as the STL datacenters) in order to move to machines running XenServer.

    So the overall big window is for the conversion - that can happen any time once that process is in place.

    The smaller windows will be for the hosts that have to be migrated as part of the switchover to XenServer. Unfortunately those will have to be scheduled within specific time periods. Like I said, more details coming.

    I will add that manual migrations should still be possible if you want to migrate early to have more control over the timing. This article series describes migrating a server via rsync between services, so if you want to guarantee the data on a staging server gets transferred well in advance to give you plenty of time to test, that could be one approach to try to reduce uncertainty. It's less painful than it sounds, and our support staff will certainly assist if you run into any snags when copying the data over.

  • @kohudson, As Jered mentioned we will have smaller windows for the switch to XenServer because we feel it is important to break up this conversion up into many smaller, manageable pieces rather than a single event. The method we chose to break up the process is mostly by how slices are allocated within the data center. Where customer slices would spill over our chosen breaks we will seek to expand the selection to give customers the ability to manage to their particular needs around maintaining an appropriate software development life cycle, keeping failover services alive, etc.

    I want to make sure to note there are two distinct phases of this process. Phase one is a hypervisor maintenance to move over to XenServer (this is the process that will function very similar to a resize operation) and phase two is the actual conversion to Rackspace Cloud (this will not impact running services but will change how services are accessed). None of the phase one customer migration windows will start until mid July at the earliest, we will provide customers at least a month notice of when their migration window will open, and the window will stay open for at least 3 weeks. During your migration window we will provide you a list of your current slices and the ability to select as many or as few slices as you want to move at that point in time (along with a "select all" if that is your preference). This functionality will be made available within SliceManager and will also keep track of the state of each slice (needs to migrate, in progress, or completed migration).
  • OK. Thanks for the responses. It looks to me like I have 2 choices. First, wait until you tell me that I have to move and then I have 3 weeks to do it. Of course, I have no say and no control over when this happens. It will happen when it's convenient for you. Second, I can do the migration manually with a schedule that meets my needs but with more down time and disruption to my users because it may not be simple or straightforward. Of course, if I choose option 2 then I could just go somewhere else. Pretty good summary of the situation? Bottom line: I'm not happy and I'm seriously disappointed in you all.
  • @jimbattenberg regarding the creative solution to the IP address issue. Would it be possible for the "one button convert" to update the DNS records during the migration process? If that is too big of a risk could the DNS interface of the new control panel that you're putting in place display a "X.X.X.X IP address was migrated to X.X.X.X address. Would you like to update the corresponding DNS records?"

    Additionally, if this mapping information is tracked somewhere you could provide a script to handle updating /etc/hosts on each slice based on the mapping data so that servers within the walls of the data center could utilize the new mappings without waiting for DNS cache expiration. Having something that tied into an IP mapping API would dramatically speed up the lookup process though.

    Additionally, if the new control panel could provide some alerts/warnings for IP addresses that used to exist for Slicehost customers which have suddenly gone away, that would probably go along way toward ensuring we don't leave anything out.

    Those were my first thoughts though. I'm sure ya'll will come up with something solid.
  • kohudson: To add to your assessment, the manual migration approach would probably involve less downtime than you'd think. Most of the rsync can occur with the server still running. Testing can likely occur after a basic sync, so you could experiment with the process without any disruptions for customers. If you're hoping to be flexible with the schedule and aren't sure we'll be able to accomodate you properly with the automated process, then it may be worth looking into.

    I'm not trying to discourage you from pushing for an automated solution more to your liking, mind you. I'm just doing my support thing.

  • On the subject of historical bandwidth, I'm told we do not have prior bandwidth usage data stored in our billing system.

    For now it appears the best bet for comparison purposes would be to set up something like munin (or another program that monitors and aggregates bandwidth data). It's not as nice as historical billing data, obviously, but hopefully monitoring for a month or two will help give an idea of what you'd use before having to make a migration decision.

    I'll work on getting a short article up next week on setting up munin with bandwidth reporting, just to try to help out a little on that score.

  • On the nameserver issue --

    Why can you not maintain (and point this at a rackspace nameserver). My customer are nontechnical, and getting them to change the nameserver settings on their domain is a major hassle.

  • I've spent years building my online reputation as a quality mail provider that is listed in many international databases keyed off of my originating IP address. Any IP change will seriously affect my business and my reputation and I need to make plans NOW to move to a different provider so I can start establishing a new reputation on a different set of IPs. Information such as "migrations will begin at the earliest in Q3", does not provide me with enough information or time to plan this effectively.

    I'm open to hearing about your creative solutions, but I'm concerned that there wasn't enough consideration of the various applications that are tied to IP addresses.

    I will also be contacting support directly to get a better understanding of where my slices sit so hopefully I can create a plan that is as harmless as possible to my reputation.

  • colinhines,

    While I certainly understand exactly where you are coming from, I do think that regardless of your hosting arrangement any IPv4 addresses you have built reputation on are going to be essentially worthless over the course of the next year as the entire world makes the move to IPv6.

    You can see what datacenters your slices are in the slicemanager, just open up the specific slice view, it's the like labeled 'Datacenter'.

    If I understand the plans correctly, stl-a and stl-b are eventually going to be phased out which means IPs are facing potential renumbering. All others are within 'official' rackspace DCs and should be able to retain their IPv4 IPs indefinitely.

    From memory I can tell you that only a /22 (4 /24 or class C's) of address space is actually not currently registered with slicehost or rackspace and all of it is contained in STL-A. The rest is at least eventually relocatable by rackspace, however due to the complications of route advertisement, I can definitely believe that the supported migration path will be to renumber even when migrating from STL-B.

    And as a disclaimer - I'm not a rackspace employee and cannot speak authoritatively on this, just offering my own color.
  • OK, the suspense is killing me... Since I have decided that at least for now I'm going to migrate to RS cloud, I want to get over with it as soon as possible, especially since I don't want to make any infrastructure related changes in my software when they might not be needed in the RS could.

    So is there a way to sign up to be a beta tester/early adopter, to finish the process as early as possible?
  • @jason: slightly off topic but why will reputation built on IPv4 addresses become worthless after the move to v6? Certainly it's a larger address space but v4 addresses will persist and still be accessible by more devices and networks. I think I missed your point.
  • Since my account details are inside Slicehost I would hope that I can get a message detailing 1) where my slices are located, 2) which CloudServers match my slices on cpu,ram and disk, 3) and how my historical bandwidth would be priced.

    The trial CloudServers will be useful, but since I have to start working on a migration on my schedule rather than yours, if I start using CloudServers now will there be any way for me to get a discount ?

    Also, since I'm a current Slicehost customer (since late 2006) can you please dispense with the callback from sales to activate the server.
  • johnsatlantic: Sending an email to or opening a ticket through the SliceManager would be the easiest way to get a response with some of that information, since that will make it easier to identify your account.

    You can check the datacenter for a slice by looking at its details - the datacenter is at the bottom of the details list. "STL-A" and "STL-B" would be the only ones that are not already Rackspace datacenters.

    The Cloud Servers pricing page lists the prices and packages available. They don't have intermediate package sizes (384, 768, etc.), but the rest of the sizes should be roughly the same. Just bear in mind that bandwidth is charged separately from the package of memory and disk space.

    Unfortunately our billing system does not store historical bandwidth use, so we can't provide a comparison on that score. For now the best I can suggest would be to set up monitoring on your slices so you can aggregate your present bandwidth use and try to project from there.

  • @mwilliams - After a critical mass is reached, the only way anyone will see your IPv4 address is via some IPv6IPv4 proxy.

    You cannot directly reach an IPv4 network using IPv6, you must cross some NAT device. The best transition path for most is to add IPv6 and run dual stack so that the same resources have both IPv6 and IPv4 addresses and the over time IPv4 usage wanes. There are other more complicated transition paths that involve NAT at the provider level, but the bottom line is that any new devices on the web after a certain point (likely a date in 2011, definitely by end of 2012) will have only IPv6 addresses so my point is that it is going to make sense of you to start 'reputation building' on an IPv6 block anyway.
  • @jason: Thanks, interesting. I was assuming the current prominence of v4 addresses and the widespread lack of preparation for the transition would mean they remain in active use, combined with v6 addresses as you note. I believe my domestic ISP is planning to run 6-to-4 tunnelling for the immediate future for instance. It's surprising to see how many VPS providers aren't yet supporting v6 too. I guess v6 will become the preferred standard at some point though, so point taken.
  • A couple of suggestions for Rackspace.

    1a)Create some plans that bundle Bandwidth AND Backups -- some prefer a single number.
    1b)Place no limit on backup file size -- I could not find a file system with a 80GB limit, just cluster imposed limits; so create an over 80GB backup pool using larger clusters. Then all slices can be backed up.

    2)For customers with slices in STL we don't have a year *:-(; we only have a couple of months -- "We expect to start the migration out of the STL DCs in Q3 2011."
    If the addresses are not kept then the migration will not be as easy as 1-click; many applications would need to have their configurations changed; even a simple application like Apache would require changing 'listen' statements and digital certificates. Nameservers, firewall rules both on-slice and elsewhere, antispam rules, monitoring, and remote access software would also need to change. Much of this may be within multiple organizations and require several people to spend hours of their time per slice. If you own the ASN's(I know you have ours - 12200), and are not otherwise using the STL DC's, please keep the IP Addresses!
    Do a Live SH to SH DC migration for STL-A&B to newDC-A&B before any SH to CS migration --
    e.g. move the AS numbers to the routers at the new DC's and tunnel back to old DC's using something like VPLS so that the location of each IP can be controlled internally; migrate in batches(let the customers pick the time slot); continue running SH in the new DC's; then in the future migrate between SH and CS.
  • First, I'd like to thank Mark for his thoughtful reply, it goes a long way to clearing up the gray areas and assuring me of the details of what's to come. I'm generally optimistic for the future of this move, even though I do think that rackspace is aiming curiously low with their VPS specs, particularly when you consider competing VPS competitors. But I digress.

    I would like to weigh in on bandwidth. I don't know exactly what my bandwidth has been historically, but it's certainly been under 60GB. I recognize that, and I recognize that I stand to save a few bucks per month with the move. However, my current plan includes 150GB of bandwidth for the same price. So, on paper, the new rackspace plan does threaten to take away 90GB of included bandwidth per month away from my plan.

    The argument that most of us will save money makes a good case to be sure, but it also sounds a little flippant like, "look, it practically doesn't matter for most of you." If it practically doesn't matter for most of us, it practically shouldn't matter to rackspace either. Honestly. But the whole issue gets very interesting when you look at it from a revenue perspective. It's like watching rackspace throw both money and good will away.

    Consider AT&T. AT&T did a similar thing with iPhone customers and their unlimited* data plans. They capped bandwidth on new plans to 2GB or 200MB per month. The new plans were cheaper for most people -- most customers able to cut their data bills in half -- so there's a strong fiscal incentive to migrate. AT&T also provided 6 months of bandwidth history so its customers could choose the plan that best fits them. Most importantly, AT&T kept the unlimited plan for existing customers. Many customers immediately switched to save a few bucks anyway. AT&T did this in a customer-friendly and it helped to keep people enlisted and to demonstrate the value of their customers.

    Let me wrap this up. Offering a grandfather bandwidth package to slicehost customers is a potential profit center for rackspace: If a typical slicehost customer pays $20/month for a 256 slice and uses 11GB of bandwidth (10 out, 1 in), they'd pay less than $13 for rackspace hosting. If that customer wants to pay $20 to get additional bandwidth that they don't use, then rackspace stands to generate 65% additional revenue from each of those customers while at the same time offering a tremendous amount of good will. It looks like a win-win to me, for what it's worth.
  • @johnpenn: I think you've nicely resolved some concerns in a pretty reasonable plan. I know there needs to be a sufficiently strong business case for any proposal but if the priorities for the change are more technological than financial, I'd hope fixed bandwidth options like yours might be viable. If RS need further convincing to permit the present plan pricing to continue, overage costs could even be slightly higher than the flat rates stipulated for straightforward cloud plans. The Q&A states "For higher bandwidth legacy Slicehost customers, we are investigating a bundled bandwidth option for Cloud Servers" but it'd be nice to see the option available to all customers.
  • The only reason I don't like "cloud hosting" is the utility based billing... Seriously, it will be cheaper than SH but who in the world would use a server without bandwidth?

    Secondly, its quite assuring when you sign up for vps server somewhere that you have bandwidth to grow along with your site without forking up a bundle to run it.

    VPS was meant to be a cheaper solution than a dedicated server. Looking at the bandwidth charges it would be more interesting to pay for a dedicated server or find a better vps host. You may reply and say a dedicated server doesn't have room to grow...

    IMO, cloud is just marketing ploy to make users feel like they are paying less but in the long run they will be paying more for bandwidth!!!

    No bashing to your service, i just dislike utility based billing. Your goal on the internet is to attract more visitors not to be stagnant.

    Cloud hosting with bandwidth included i would like it more.
  • If we were to migrate our existing sites to RackSpace Cloud our hosting costs would increase 200% due to the bundled bandwidth not being included.

    Regardless, I can't say I have a lot of confidence in this migration process given the way this was announced. It's nice to have this follow up but to receive an email from someone saying we are being forced to migrate and no mention of timeline doesn't inspire confidence.

    Investigation of bundled bandwidth for existing Slicehost customers doesn't sound very promising. We're looking at moving what we have hosted on SH elsewhere at this stage.
  • I migrated OFF of Rackspace CloudServers and moved to Slicehost for two reasons:

    1.) Security.

    2.) Performance. I currently run more than one site and a small gaming server on a single slicehost without traffic, i/o, or user perceived performance issues. I could not do this on my equivalent 256 RS cloud server.

    Being a prior Racker I will give them the benefit of doubt - for now.

    I'm not looking forward to having to "migrate" back. I hope to receive nothing less than 'Fanatical Support' during the migration. I also expect the 'full disclosure' core value to be upheld during this migration.
  • This is a real bummer. Slicehost made me a happy camper with its straightforward tools and simple pricing. I've ran a few tests with Rackspace Cloud and it appears to be a competent cloud VPS offering, but it certainly doesn't capture the "Built for Developers" vibe.

    Where is the DNS management? Reverse DNS? And the API?

    This transition shouldn't have even been initiated before RSC had that service spooled up and ready to go. This alone will make me have to look elsewhere because I'm not about to start paying utility pricing for every zone. Its bad enough a few measly GBs of transfer can't be included.

    And how about account switching?

    I actually am a developer and have access to multiple customer accounts (customers I regretfully had recommended to Slicehost BTW). Am I back to having to login to their accounts separately?

    I'm seriously disappointed to see SH go. It was a solid offering that gave me the no-frills, but essential functionality I needed. Now, not only do I need to undertake multiple migrations for servers that were running just fine, but I have to figure out how to solve for the missing holes in RSC's offering, and try and not pay more for it as well. This is about how I'm feeling right now:
  • One of my favorite movies and one of my favorite movie scenes. And it pretty much sums up my feelings, too!
  • Hmm, so looking at Rackspace there is no bandwidth included...

    How many people would like to move to Rackspace without bandwidth included and pay about 200% of what we pay now ?
    Clean situation that all of us will search for VPS for the same price ?

    Could someone explain it to me because i am pretty confused about this.
  • There's a performance comparison of VPS offering, it's a bit old, does anyone have a link to a more current comparison?

    I've been doing cost and feature analysis of alternatives, and Linode works out to be roughly equivalent for both features and price in regards to Slicehost current but on-the-way-out offering. Their control panel has an awful lot of tech features and they pool bandwidth as well.
  • That's a good comparison, but it's also a bit old, being from 2009. There are some other players in the ring as well such as 6sync and Storm on Demand that are offering cool deals in the VPS market.

    A couple reviews:

    It often depends on what exactly you need when making a good choice for a provider that fits you, so I like to keep informed about as many options as possible. :)
  • Posted By: tswWhere is the DNS management? Reverse DNS? And the API?

    If by "Reverse DNS" you just mean being able to set the PTR for your IP(s), go to the cloud server's page and click on the DNS tab. Scroll down if you have a really tiny monitor. ;-P

    Posted By: coxisHow many people would like to move to Rackspace without bandwidth included and pay about 200% of what we pay now ?

    I don't have a link, but it's been stated somewhere around here that most Slicehost customers use a small proportion of their bandwidth and would pay less at Rackspace. Or at least speculated, and it sounds like good speculation to me.

    Of course, what matters to you is how much you'll pay, and you're the only one who knows that. (Or maybe you don't know it, given the lack of information stored by Slicehost's manager. But you can certainly find out.)
  • About that bandwidth, taking me as example i use all of 450GB bandwidth from my Slicehost plan included.

    So i would like to transfer my SliceVPS to VPS that includes similar plan that i can use, for similar price.

    If i migrate to Rackspace and use 450GB probably the cost are going very big, am i correct.

    Also i am thinking that many users use bandwidth in 'big number', not only me.