 So, while they check into that, I'm Dan Shepard. I'm a product manager at Rackspace. I focus on Rackspace Private Cloud powered by Red Hat, and I specialize in day two operations of OpenStack. Here we go. I'm Ryan Nichol. I'm also with Rackspace. I'm a private cloud specialist. Work with customers to discuss on-prem and off-prem OpenStack solutions. Also an AWS certified solutions architect and generalized awesomeness. So the question we really want to present and talk about. So speaking with customers across many different verticals and industries, at some point there's probably a journey where they're going to start to consume cloud. And oftentimes, that cloud is AWS or some sort of public cloud. And there's a notion around the cloud is cheap. After some cycles and starting moving more workloads, oftentimes the invoice starts to grow and grow and grow. And then so the thought becomes, well, if it's so cheap, then why is my invoice just increasing and so high? Is there a cheaper way that we can do this? And when we dig into that, you really start getting into, well, what makes AWS appealing? Why did people come there in the first place? And they're looking for flexibility of having infrastructure that they can call programmatically not have to worry about the underlying bits that are making it happen. But also the hourly billing model seems attractive when you talk about small scale bursting workloads. But what we find more and more when we go out and talk with the customers is, well, I did all that. And then I scaled up. And I've been there for eight, nine, 10 months. And now all of a sudden I'm spending more in AWS than I was spending when I was doing an on-prem to begin with. And what we see there is there's a great opportunity for OpenStack to come in and say, hey, we get that. And in your scenario, there's an OpenStack private cloud that may fit your needs. So for the purpose of this talk, we use Rackspace's private cloud powered by Red Hat as that example. What makes this a good example and a good comparison for AWS versus a private cloud is it is a managed service, the same as AWS is a managed offer for a public cloud. That means the customer doesn't have to worry about how do I get my API up and running? How do I do upgrades of the cloud? How do I ensure that the cloud is going to perform the way that I need it to perform? All of that's taken care of by Rackspace. So it really allows us to compare apples to apples when we look at an managed, when we look at an AWS offering where it is more of a managed IaaS. So the next couple slides, really, so the rest of the presentation, honestly, is going through a specific customer use case, their experience and what they're looking for in an AWS solution versus how that translates into an open stack solution powered by Rackspace. So the customer in particular is a global media organization. They specialize in taking video content, transcoding that content, optimizing, and then serving it out to their customers globally. The workload is basically a QA environment that does just that. And the challenge that they have in exploring where to put this solution is they require it to be off-premise. Basically, it's a solution that's always on, so there's not a lot of scaling going on. And basically, when they looked at doing this at AWS, they found that the cost was much higher than what they had anticipated. So then the option then that we were presented is, can you help us look at an open stack solution that compares against AWS? So to talk through a little specifics around what exactly they need, basically, each instance that they would deploy would have 32 BCPU, 24 gigs of RAM, 150 gigs of SSD local storage, and a fairly high egress bandwidth from EC2, or just to the internet in general, of around 1,500 gigs per month. Wait, you mean transcoding video takes bandwidth? That's what they say. That's what they say. Basically, the way that they would scale this solution up is they're gonna give themselves a year to scale this up to what basically the full requirement was. It would be deployed and scaled in 40 instance increments, essentially each phase occurring every two months. So over the course of the year, they're fully scaled at 240 instances. Basically, high utilization, always on, which if you're familiar with doing cloud cost calculations, 730 hours is an always-on instance. This, in their case, they're Red Hat Shop, so they required Red Hat Enterprise Lennox, GuestOS. It's a CPU constrained workload, so it's one-to-one VCPUs is the over-commit ratio, and because performance and compute is so important, they need to at least an Intel Haswell processor or newer. I just wanted to point that out. Everyone feel like that's a cloud-friendly workload? I mean, if you look at what their requirements are and see what they're doing, this is an example of probably a customer who got on that journey and said, I wanna go to AWS and I wanna be cloud-native and I wanna do cloud things, but their workload just didn't quite fit. So I'm looking at what does this look like in AWS? Basically, when you look at the instance resource requirements that are required to run and closely match what they needed, the C3 8x large instance type is what met that criteria, at least from a resource standpoint. So it's 32 VCPUs, 60 gigs of RAM, two, 320 gig SSD local storage. Basically, the way AWS allocates VCPU or looks at VPCU as one hyperthreaded core equals one VCPU. These particular instances run on compute nodes that have Ivy Bridge hypervisor processors. They have the Red Hat, the RHEL OpenStack subscription, and basically the solution was delivered in a single AWS region, utilizing a number of availability zones within that region. And basically, as the solution were to scale in this particular case, and when you look at the phases, basically it's just deploying 40 new phases or 40 new instances, rather, in each phase. So the OpenStack solution that we laid out, it really follows reference architecture for what we deploy for all of our private clouds, which is a four node control plane. Three of those are controller nodes and one is the deployment node. If you're familiar with the Red Hat solution, it's Red Hat Director for deployments. And then it's the compute nodes on top of it, 40 nodes for each deployment. And then we leverage Seth as our default and distributed storage platform to allow the customer to have access to block and object via Seth. Yeah, and so the way the solution, the requirements didn't mean that we needed to include cloud forms and some of the storage options in this case. Basically, it was the redundant networking, TIGG, control plane, and then X number of compute nodes. And the way the scaling worked on the compute nodes, you can see the resources there in the chart that were provided per compute node. Basically, in each phase, we would add 20 additional compute nodes until we got to phase six, and at which point it was mostly static. And again, one vCPU equals one hyperthreaded core. The solution's hosted in a Rackspace data center in this case. And it also includes subscription for the Red Hat Enterprise Linux OSP. So to start looking at the cost, if you're familiar with AWS, they have multiple options when it comes to the cost models that you can choose. On the top right, where it says on-demand hourly, that's the price per hour on demand for that particular instance. The customer preferred to commit to a one-year term. Within AWS, there's three options when you commit to a one-year term. You can do all upfront, you can do partially upfront, or you can do nothing upfront, but that's your instance that you have if you don't want it anymore, then you'd have to go through efforts of reselling on the marketplace and so forth. But basically, by committing to a year, paying nothing upfront, that will give them a 28% discount on the on-demand hourly rate for that instance. When you look at the chart on the lower, so basically this shows each of the six phases as a scale over time. The first column is the monthly cost for the EC2 instances. The next column covers what the bandwidth cost will be. The way that bandwidth works in this particular case is basically a tiered discount model that you see on the top right there for the data transfer out of EC2 to the internet. The next column over covers the monthly cost of both the EC2 instance and the bandwidth, and then just to break it down a bit more, the per instance cost per month is the final column in the chart. One thing that's important to note is this doesn't cover the other costs of deploying AWS, so there's not supports not included, monitoring, snapshots, elastic load balancers, other things that would be required for the solution. When we look at how this translates to cost in the rack space model, basically if you think back to the reference architecture, we basically have high availability networking. The cost per month is in that solution. Basically again, like AWS, this is a one year commitment that's paid monthly with nothing up front. The way that bandwidth works in this particular case, so each physical node that's deployed comes with two terabytes of free monthly outgoing bandwidth. Each additional gig beyond that is just charged at two cents per gig for an overage. Basically this solution covers the cost of the hardware support as well as the Red Hat OpenStack platform support that is billed on a tiered discount model based on the node type within the solution. And so how do these compare? When you look at this chart, the numbers on the left represent the monthly cost. Basically this shows the monthly cost over time, so on the bottom are all the months, so each two months that starts the new cycle where they add 40 additional instances. The yellow line represents the AWS cost on a one year commitment with nothing paid up front. The red line represents the Red Hat OpenStack platform with rack space priced out over time. The green line, we'll talk about that first. Basically the green line shows the amount of money they've saved over the first months as this solution is scaled up by going with the rack space solution versus AWS. Some of you may say, well, there are other options around pricing. You can pay everything up front, which gives you a larger discount with AWS. In that case, for comparison, the dashed purple line is actually the AWS cost if they were to pay for the entire year up front. So even in that case, the solution itself paid monthly at rack space on OpenStack is still cheaper. To look at it over two years, because once this thing is scaled up, basically at that point it stays relatively static unless they bring on more customers, which I'm sure they hope. But basically looking at the same lines to represent the same things over the course of two years by having this particular workload type on OpenStack saves them almost $1.2 million versus what it would cost for the same resources at AWS. To break it down just a little bit, so when you look at this, this basically represents the cost per instance excluding bandwidth, because truthfully the bandwidth in this particular case is pretty high, so it may not necessarily be common to every kind of static workload or steady state workload. So when you look at just the instance costs themselves, basically in phase one, when they have 40 instances deployed, the cost for the OpenStack solution is 11% higher. And really the reason for that is because when we deploy a single tenant private cloud, that includes dedicated networking, that includes a dedicated control plane to house the OpenStack KPIs. So it's not until we can scale just at the compute tier that that's really where the economics start to be much more favorable for OpenStack. So as you look as this goes on, the percentage of savings at a per instance cost just increases over time as this thing scales out. In a similar comparison, this is the bandwidth. So this is the outgoing bandwidth. Basically you can see as the solution scales up at phase six, there are roughly $22,000 per month with AWS just for the bandwidth. And with the OpenStack solution, it's just under 8,000 a month or 64% lower. You know, that alone is really impactful in what makes up a lot of the savings when we look at the overall cost of this solution. So I know some of this might seem a little bit like maybe we cherry picked some workloads here. So can you talk a little bit about how, what this represents in the market when we're all talking with customers? Like how often, is this a common use case? Or are these the things that we run into more often than not? It is, so I talk to a lot of customers that either have a company-wide strategy to move AWS first is what they look at and what they try to do. And a lot of times there are workloads that folks just think, let's move it to the cloud. And now a couple years have gone by and then we have to sit down and say, why am I paying too much for this? And a lot of times it's because there are workloads that don't really make a lot of sense and they're always on and the utility price model that AWS builds just doesn't work for that type of solution. And our core messaging around that and the way we start thinking about that has really changed over time and as we've learned more about what's common in the market. When it comes to when should you choose what a private cloud option over a public cloud option really starts getting more into how strategically important is this for your organization and how many instances do you need to run? Are they always on? And you have to start looking under the covers what are the workloads that you're trying to deploy. We do talk with a lot of media companies that have large amounts of data and they're looking at cloud first strategies and they're trying to understand, well, yeah, but I gotta put 20 petabyte of data onto that cloud to make it usable for me. Well, now you have massive bandwidth transfers just to get it all out to the cloud. You have massive bandwidth fees whenever customers start streaming 8K video. Once that becomes available, all of these things start adding up into the cost model that really drive for why is OpenStack relevant? Why is OpenStack still growing? It's because as customers go to this cloud first strategy, they realize AWS isn't that silver bullet that it was being built as a couple of years ago. And so lastly, just a high level look at what are in this particular use case, what are some of the advantages and disadvantages of each platform? So when you look at Amazon, you know obviously the advantage of a public cloud where you have the flexibility to scale much quicker is certainly available. There's multiple data centers in the solution that they were working with given the number of availability zones within a single region. On the OpenStack side, basically this solution, while it was in a Rackspace data center, it could be deployed in any location. The customizable nature of the hardware to most closely align with the instance resources that work best for their application. And with Rackspace, this solution is basically supported 24 by seven by 365. Some of the disadvantages with AWS, the C3 instance type that most closely matched the resources that they need were actually an older instance type within AWS. So that particular hypervisor had an older processor within it. The cost for outgoing bandwidth was significantly high. Basically the support either through AWS or some other managed service provider would require an additional cost. The disadvantage on the Rackspace OpenStack side is as you scale, there needs to be adequate planning on both behalf of the customer in Rackspace to ensure that we can get resources and things online as you need to scale up. And then a multiple data center solution would require multiple control planes to allow default tolerance and redundancy that they were getting through the multiple AZs at AWS. And with that, I think that's it. So our goal was to have some time for questions. I know that we talked a lot and there was a whole bunch of numbers up on the screen for a while there. So we're happy to dig into some of the data and talk about maybe the use case and a little bit more specifics if that's interesting to everyone. Could you use the microphone? Yeah. We are streaming. So do you see on a day to day basis a lot of customers moving from AWS to your Rackspace cloud? Is that a common use case these days? Yeah, so I think it comes up a lot. You know, I don't know on a day to day basis but I certainly have seen over the last probably six months to a year as folks maybe have been on AWS for quite some time now and the bill has kind of gotten out of control. I feel like it has come up a lot more. Once we kind of have started to kind of work through some of these and the data becomes available where there actually is a significant value of moving to an open stack private cloud for particular workload types. I think we'll probably see more and more of that over time. I hear it more frequently these days as well. I think the cloud first strategy that everyone had and was running with and that AWS is a silver bullet people are realizing that it comes with a lot of costs that they just didn't see. There's also as data becomes more and more your anchor that keeps you where you are the bandwidth costs are just starting to chew people up. So when we get into media companies and we start talking through that and start looking at large amounts of data that they just they have to have it's unencrypted video footage that they need to transcode and host this data. It becomes a huge weight on them and they're really looking for how do I go back to what I used to have before of having control over my hardware and my cost but still have the flexibility that I've come to expect with AWS. So we talk a lot about internally like moving from Amazon into our own internal cloud and actually one of the biggest challenges we get is from the developers. And they say, well, I could move my workload but this is gonna cost me a lot of time and effort because I've kind of coupled myself to Amazon internal tools or systems or workflows or policy languages or whatever. Can you talk to anything around like making that migration easier on the developers? So it's they don't have to choose so much between like shipping two new features or essentially moving their app. You know, it's a very tough thing to do because they could get more features out which gets them more money which offsets the cost of the infrastructure so they feel justified in that action and unless we give them kind of less reasons to scoot out of that they'll continue to perpetuate that pattern. That's what Amazon wants right there. Yes, depending on what services they're consuming from AWS it can be a pain or it can be this overwhelming months of marching towards migrating away from AWS. And I think some of this is where we get into the conversations of are you building a microservice oriented architecture? Are you building cloud first architecture? Are you bringing workloads? Did you bring workloads to AWS that maybe shouldn't have been there in the first place and figuring out which category they fall in because the stuff that shouldn't have been there in the first place, they're probably not taking advantage of all the services AWS has to offer. The stuff that is cloud native that is typically the place where they've taken a lot of liberties and leveraged a bunch of the services out of AWS. And those are the ones that become the tax on how do I move out? And it really does, it is a trade off. So doing this kind of calculation and getting into the weeds of what is the value of moving away and comparing that against what is the feature and the expected return on the feature that you're going to deploy over that same amount of time becomes the product managers and the product team's role. They need to sit down and do the math and talk about why is this important for their organization? Yeah, I guess from an open stack as a whole, it feels dirty to me, I get it, but if we could maybe create an abstraction layer that just perfectly mirrors Amazon, right? Then it just makes it so much easier because they just change an endpoint and do it. So it would be my dream if we just kind of made it. I think at one point, we started down that path, right? And Amazon just builds and deploys services very quickly and you look at some of the services that they're focused on now, the Lambda for example, right? And it doesn't inherently fit with the mission of open stack. We have to get to a point where I think the community needs to come together and say, yeah, we're not gonna solve all of the things that AWS does, but we're gonna solve them in a better, more meaningful, more cost effective way and then the communities are gonna have to stitch together across different products to get there. Thanks. So what I was hearing in your use case is that the characteristics of a workload that probably shouldn't have been on Amazon to begin with is that they're always on and they have a high egress bandwidth. Are there any other workloads that you've looked at or thought about that any other characteristics before you deploy the workload the first place where you'd say, okay, this is probably fine for public cloud, but this over here should definitely go private and should go open stack first. Yeah, so there are a lot. I would say one that's common is around security or ones that require certain, required to be in a certain location, right? So they have data sovereignty or something like that. I think the ones that we see most common are the ones that are just sort of set it and forget it in Amazon or public cloud in general. So we see, I mean, we get into the use cases around compliance, security, and then retail comes up a lot. Apparently other major retailers have a desire to not run an AWS, go figure. It's really purpose driven, right? Like I need to be in region for data sovereignty. I need to be super close to whatever thing it is that I'm trying to work with. Large data deployments and databases are examples, right? I have a big ERP system and I'm connecting to my mainframe for up to date real time inventory management. Those things customers start looking at, well, it performs a lot better and it fits my security and usage model a lot better if I can put it in the same data center as the mainframe. However, they didn't typically pick them up and try to shift them to AWS. Yeah, so I think another one that comes up kind of more frequently or that I've heard more recently anyway, is the scientific research. You get funding to do research projects, you deploy the solution in a public cloud, you generate all of this data and then all of a sudden the funding isn't available anymore. What do you do with this data that AWS or public cloud is still gonna continue to charge you for, right? Having that data within an internal private cloud based on OpenStack will allow you to keep the data that you just spent all that money and time generating. Any other questions? So this was a managed offering, right? So the customer, so where was it actually hosted? Was it on-prem or was it in a colo location? In this scenario, we were using the Rackspace data center so it would have been like a colo for the customer. So they're not worried about the electricity bill or anything like that? It's all rolled into the cost. Yeah, their goal was to get off-prem. They didn't wanna have to worry about that anymore. And that's why we chose the managed offer because it's a single source bill with one line item similar to what you get from AWS. And you have the other model where it is on-prem and still Rackspace offers managing their services. Absolutely, so I mean, same service that we provide in our data center can be provided to any customer data center. So for the colo part, under the cloud networking, is that an option for the customer to dictate, okay, I need VXLAN, I need these ADCs or obviously that is extra cost to the customer, right? We have a prescriptive deployment because we do this at scale and across a lot of customers where some things can be enabled, some can't, some are a combination of the two where we sit down and work on it together to come up with the best way to solve for it. So I can't just blanket statements and say, oh yeah, we can customize it however you want. There's a lot of customization available but the specific choices that you want to make are something that we work together in a partnership on. Okay, and last question from my side. Is there like a critical mass where for this customer of yours, was there hybrid cloud an option saying that, okay, let's get you to AWS and then let's, for extra load, we bring up your prior cloud and over time there's a balancing act between the two clouds and then eventually might end up with one cloud after 12 months. So the part that we ran into really became the data, right? You're running encoding and then hosting or basically hosting out the media that you just encoded. So you have to be close to your data. So when you go to a hybrid cloud model and you're looking at, I'm gonna burst into AWS, well now everything I just burst into AWS is further away from my data. I have to pay data charges in both directions now and it just wasn't as cost effective as planning your capacity and having it all on your private cloud. Okay, thanks. Yeah, in this particular case too, it was very predictable what the workload was gonna be and again it was just always gonna be on. So there weren't really like scaling events that would make bursting somewhere attractive versus just having it all somewhere. Other questions? We've got a few minutes. I mean, we can ask Ryan to sing a song for us or something. I can't. All right, oh, another question. Let me push you back a little bit. Some of the big companies are looking at moving to Amazon Cloud by scrapping internal cloud initiative. What was the rationale behind that? That's one question. Second question is that the data traffic what you're talking about, if you set up an MPLS VPN tunnel between Amazon and internal traffic, that's all washed out, right? Yes. What do you think about the direction going forward? So the MPLS, let's start there. Yes, from your private data center to AWS, that traffic doesn't count, but out of AWS to the end customer would have still counted. So there were the additional bandwidth charges there. And then there's the cost of the MPLS circuit every month that has to be counted for as well. It's in the semantics, but ultimately we went down that path as well and it still came out that it was more cost effective to run it all internal. Part of that's because we have a fairly aggressive volume discounting that gets applied in Rackspace. So the more you run, the better your discounting gets. So to go to the other question, the, I mean, maybe Ryan, you can share some of your insight on why large companies are looking at cloud first strategy and then I'll. Yeah, so the question you asked, just to clarify there, the question was around why they're gonna go to Amazon, why go with somewhere like Rackspace or another data center versus their own? Correct, yeah, what I'm trying to say is all this plus presentation, is it the negotiated price you're listing out with Amazon or it's a list price of the Amazon. Oh, got it. That makes a huge difference because Goldman Sachs, they negotiated a price with Amazon, they're going to public cloud. Right. For example, capital financial, in-duit, they are all going into Amazon cloud. Correct. 100% so there should be some rational behind the scene happening with Amazon, with big companies, those guys are going out. Look at Amazon cloud conference, 32,000 people. Yep. What we have here, 5,000, 6,000. I'm just comparing, what is the industries going through? So that's a good point. So the pricing that basically is reflected in this is the list pricing that you find on the internet. Basically when you look at just the standard pricing, this particular customer is at a point where they weren't large enough within AWS to really qualify or AWS have interest in providing any additional discount. I mean, they just weren't that big of a player form to do that. And your use case is valid. I mean, every company would need to do the same calculation based on different factors. And I would imagine if you're large enough that you're getting strategic pricing from AWS, you're probably getting strategic pricing from Rackspace, you're probably getting strategic pricing from Dell or EMC or whoever you're talking to is probably giving you that kind of discounted pricing tier that you're referring to for the large enterprises. So again, the calculation would just have to be done from the ground up using the pricing models that they're going to get. And then beyond that, why are so many choosing AWS? It still comes down to it's cheap, it's easy, and it's fast, right? And those things hold true in many usage scenarios, but not at all. And that's what we're driving to, is there is a place for both technologies in the world and there's definitely a need. Thank you. Thank you. Anyone else? Excuse me. What storage options do you have available with Rackspace with OpenStack? Is it just SIF or other storage options? So we support Sender, Swift, SIF, we also support NetApp and EMC storage devices as well. And in the Rackspace Data Center, we offer managed solutions around all of those technologies. Just to follow up on that, so can you do a transitional migration or gradual migration where you keep the storage in AWS but you move all your control and data over to OpenStack and Rackspace? Absolutely. Again, I would encourage, do some calculations, make sure it's the right strategy, but absolutely. And that's, I host a couple things in Rackspace as well, that I'm using S3 for my storage, so. Anyone else? All right guys. Cool. We do have people lining up for the next talk, so. Well, thanks everyone. Thanks everyone.