Welcome to this evening's next talk with the wonderfully broken title, I love it, Emoji Domains and how wonderfully broken they are by a very, very wonderful person, Genois, who is a VEP developer and you wouldn't believe it, her nickname is Unicorn, here is her Unicorn. Hi, Genois, this is, tell us everything about Emoji Domains and why they are so rotten-broken. Jörg. Yeah, thank you a lot. Exactly, I'll be speaking a bit about these wonderfully broken things and the talk will be kind of like, I start with a bit of an info dump about the history of Emoji Domains and what they actually are and then I will talk about my personal experience breaking things with them. So yeah, let's start right off with the history. So DNS was standardized in 1987 with a very limited character set. So you can see like only Roman letters and some numbers and like four non-letters. So these are definitely not sufficient for many languages and it's a very Eurocentric view or not even just Eurocentric, but it's actually very centered on the English language and it was clear that these wouldn't suffice. So in 1996, internationalized domain names were proposed which allow encoding characters that are not supported or that are not officially supported into this very small character set so that browsers could simply convert them on the fly. So sources kind of disagree when this exactly went live or when you could start it, when you were able to use it for the first time. The IDNA 2003 standard allowed the support, but the first Emoji Domains were actually registered in 2001. Interesting about this is that in 2001 Emoji weren't part of Unicode yet. So you can see these are the examples like the Hot Springs, those Dooshers Emoji, which is because they are both Emoji and Unicode pictographs. So not actually Emoji domains at the time, but right now they were kind of converted into emojis back then they were just pictographs. I couldn't really find out if those domains actually resolved if you entered the pictographs back then or if it was just someone who was hoping that they would rise in price once IDNA 2003 or whatever standard would implement went live. So there was also an IDNA 2003 normalization, but that's not too interesting for us because we just want to look at the Emoji side of things. IDNA 2008 actually banned Emoji for most major TLDs because of concerns that it would be used for phishing domains that looked very similar to actual other domains. Like every character exists as an Emoji to be able to make country flags. So that could be used for phishing and they decided to ban it for most major TLDs that comply with IDNA 2003. And just important to my little story, in 2020 the Emoji 13 standard or Emoji 13 added a transgender pride flag emoji. You will see why that's important later. So what actually is this puny code encoding? It's a non-human readable representation of puny code characters. So you can see this symbol here would be translated to xn-c8h, which obviously it doesn't make much sense to type in, but your browser would take care of this. So DNS didn't have to be changed. It's only inside your browser that these conversions happen. Compatible browsers, depending on which browser you use, will either intransparenly or semi-transparenly translate. Firefox, for example, as a mitigation to these phishing attempts does allow you to enter Emoji or other unicode characters. But as soon as you enter it, the URL bar will show this xn-dash domain. Safari, as far as I know, does not do it transparently. So you will not know what exactly the puny code representation is of what you were just entering. And different TLDs only support a specific subset. As I said, IDNA 2008 actually banned it. Oh, fun fact. I forgot on the last slide. IDNA 2008 went live in 2010, which is kind of confusing, but whatever. So, yeah, different TLDs only support specific char sets. Most don't support Emoji, but they are TLDs that have supporting Emoji as their main selling point. So TLDs that most people wouldn't want to use unless they just simply are interested in Emoji. So why did I end up breaking things with it? In early 2011, no, 2011, 2021 this year, I was unemployed and looking for interesting ways to build my portfolio. I knew that Emoji were somewhat supported, but I didn't know what, how exactly it worked. I just knew that there were some people that had Emoji domains. I was happy that there was a transgender pride Emoji added. So I decided, well, maybe it's a good idea to add some domain that contains this transgender pride Emoji to also become less interesting for bigoted potential employers. So, yeah, let's register a domain with that Emoji. Well, that seems to be a bit more difficult because these domains, even though you never really counter them, seem to be sold out. Nothing I looked up worked. And actually the web interface broke a bit, but more to that later. Well, none of these domains actually resolve to anything. .dev does not support Emoji at all, and Namecheap doesn't support Emoji even with top-level domains that do support them. So I had to go to another registrar, which was a bit annoying because I thought, well, I like having everything in one place, not specifically because I love Namecheap or anything, but whatever. A few minutes later, I now am the proud owner of transgender pride flag Purpleheart.ws. At least that's what I think. So I just set up to build a small demo page for it and deploy it on my server and test it. And wow, my server usually isn't that slow at timeouts. Well, the route looks okay inside my reverse proxy trying again. And after a long time, I end up with this wonderful error message. So we're sorry that domain is invalid. So it also doesn't show the transgender pride flag anymore. But that could be down to simply their web font, not supporting it yet because it was just added to Emoji 13. At least that's what I thought at that point. Obviously, I wasn't bit scared because well, I just spent 10 euros on something. And I didn't really know when I would have a stable income again. So I did this to find a new job in German unemployment benefits are really difficult to get. So I was a bit scared. But GoDaddy didn't sell me some invalid domain or they also definitely did not scare me. Because if you enter these exact characters that apparently are invalid, it does resolve to my server. So when I looked at the GoDaddy web interface, it also showed these three characters, the purple hard white flag and transgender symbol. It's simply not the domain that I had entered into the Emoji domain search engine. Wasn't just their web front that doesn't support it. And that is caused by the wonderful zero with join us to avoid having tons of similar emoji, each with their own code. Many emoji are created by combining others. So you have the skin tone modifiers, for example, or the country flags that are a combination of different emoji with a zero with joiner. The transgender pride flag is a combination of a white flag and the transgender symbol with a zero with join in between. And the thing is puny code does not really support them. So it was simply just dropped during conversion while I bought my domain. But that's not everything. Because I still had this project, I still wanted emoji domains. And my interest was peaked. So I kind of wanted to try out what else I could break to avoid spending even more money on this project. I chose to move to test my testing to subdomains, which was a good idea because I have way more controllable subdomains than I have over regular ones. I can register them with any registrar. So I could use just my go to registrar. I can register whatever strings I want. So even invalid puny code, I can register them until TLD that doesn't allow it because it's not a second level domain, but a third level domain. And yeah, let's see what browsers do about that. So I created the subdomain transgender pride flag dot dysphoric dot def. Firefox converts it to X and I'm not going to say all that. Chromium converts it to a different string, which if you plug any of those into a converter, it will tell you that both are invalid puny code. However, both are understood and routed. So I just simply added an all route to my reverse proxy so that both would work. If you use Dick, which is a command line tool that lets you look up domain records, first of all, it doesn't do the puny code conversion at all. So I had to use one of the strings that one of my browsers gave me. But when I use that string, it also gave me this. It's not a valid IDN8 2008 name. Disable validation using these two parameters also didn't tell me that I needed both. So I added the first and then, oh, you still need a second. But whatever. Once both were added, I was able to get correct results. And yeah, my site was reachable. The next thing I thought of was what if I moved my domain to a non-supported register because as I just talked about, namesheet does not actually allow more G domains. And I was interested to see how their web interface would handle it. Sadly, it simply did not handle it at all because they don't support WS domains. I wasn't really going to contact their support team to try and still get it because this was only a simple thing that they were probably just simply not interested in hosting that domain because it breaks their web interface if you try to or other things about emoji domains break their web interface. So I don't really see why their support team would actually be on my side here. Oops, sorry. So what about email? Because apparently email clients really enjoy breaking from my experience. At least, do they break with emoji? When trying to add an emoji domain as a sender, my mail server actually broke because validation was run after punicode to unicode conversion, which caused an uncode exception, which was surprising. It's already fixed, but the patch is not released yet. So I couldn't yet test it. But that's the local part, which I could already control, as much as I wanted to. And it led to mixed results. So Thunderbird simply ignored it and just showed the punicode and Apple Mail dropped the zero with Joiner. And also showed the punicode under the thing where it shows the exact domain. So mixed results, nothing too spectacular, no exceptions or crashing clients or anything interesting like that, sadly. What did I learn during this? Well, obviously, emoji domains are very buggy. Implementation is varied from browser to browser, so you can have the same input string and get different punicodes out of it. So testing in just one browser definitely is not enough. Well, it never is, but here, especially it isn't. And you may be able to buy a domain that won't work as you would think, which can cause quite the annoyance. But it's still not a fun to mess around with this stuff, just not for productive use. I like to end my talks by telling people to join a labor union. It doesn't have anything to do with this, but that's what I do for some reason. And I've got also a blog post about this where I've written it up and I will publish the slides under the wonderful domain, a proof emoji, code dot WS. It's just a link to my regular blog for now. Yeah, I'm sorry. I think I went a bit fast, but I still thank you for your time and I'm open to questions. I'm online. Oops, I'm sorry. I'm awfully sorry. My machine is slow. I unmuted myself about half a minute ago. Thank you for that beautiful talk, Genoa. I had to grin a couple of times because it was great and it made my day. And actually we have a question. The question is in German. I'll say it in English. Why is DNS SICK so complicated for emoji domains? Well, because no one actually really likes emoji domains except the people who sell them. At least that was my experience looking up things for that. So they are kind of disallowed in the standard, but just some top-level domains just ignore the standard and still let you register them. And it's just something that people who implement things don't want to think about at all. So I haven't actually tried DNS SICK, but it's just something that is easily forgotten because it shouldn't actually exist, which may be a bit harsh. You remember the ringtone fads when smartphones didn't exist yet? Is this just a fad like this ringtone thing and it will just disappear within the next couple of years? Or do you think emojis are here to stay? Is this serious? I think emojis are here to stay but not within domains. It was possible since 2001 kind of, but at least since 2011 when the first actual emoji domain was registered. But most domains that are popular examples already don't resolve anymore or resolve to sites that sell emoji domains. So emoji domains definitely are not much more than a fad or a nice funny thing to just look at for a bit. However emojis as a whole are such a large part of our culture. I don't think they're going to go away anytime soon because it's been more than 10 years and the downloadable annoying ringtones were popular for a bit less time I think. This is a question that I actually wanted to ask myself as well, because I run my own email server as well, and which email server software do you talk about? Do you know about supporting others? What do you use as a software on your email server? My email server is running on mail view, which is a set of Docker containers that I especially made to work together to make setting up an email server as pain as is possible for free. So I haven't actually tested any other servers. However, in theory they shouldn't actually have any issues. So the part of mail view that failed wasn't actually the mail server part. It was simply a puzzle. So in theory with another mail server it should work if they didn't also mess up parsing at some point. Somebody asked here is there a list of top level domains that support emojis and somebody posted an answer in Wikipedia. Is that correct? Wikipedia has such a list? It has, but it isn't actually correct. The list that it has is the English Wikipedia. It lists at least one domain that no longer supports emojis, which is actually some kind of big political thing where they remove support. So the Wikipedia list is not complete or it contains too much. There are however registrars that are specializing in emoji domains and those will have current lists. So I had WS as one of them. It's not the red heart emoji though because that is invalid puny code and so I don't really know what to enter in my UI. I'm about to get to them other than searching it on Google. Next question is there a difference between a single puny code and multiple emojis chained together as a second or third level domain? So it's just different puny code depending on how many emojis you have but theoretically the implementation for this which is I think the technical term was ask it to a unicode or something which is like an algorithm to convert it does handle multiple emoji similarly to or it should work without any issues if one of the two works. Are there any emoji first level domains? No, they are not. They are puny code first level domains because there are languages that that simply do not use the same letters as English does so puny code first level domains are existent but no emoji first level domains at this point. Maybe there will be but I kind of doubt it because the people in charge of this emoji domains are kind of an eyesore to them from what I could read. So talking about eyesores I always have the impression that at least to the old coders diacritical signs in themselves were considered an eyesore. You know the little funny little dots those German speaking people have on there don't talk about the check and the polls. Now my name contains such a diacritical sign my first name is André and I've been fighting with all kinds of inputs that say seven bit ASCII and nothing else here. Do diacritical signs still break domains? They should not because they are actually the reason why IDNs exist so it was actually proposed by someone who has one of those signs in his name and probably just wanted the domain with his name. So this was the actual reason why we have puny code in the first place and supporting emoji was kind of an unwanted side effect. So in theory it should work without issues but still many people don't think about it enough when implementing their own thing so you can never be too certain that it will but it should. Somebody posted here that somebody obviously runs on Windows and says in Windows 10 the emoji menu comes with the combination of the Windows and the full stop. Is that common already or is that new? I think it's common by now. It's been implemented and ever since that everybody's been using emojis and there's also a remark here that says MS Outlook adds that actually a pretty good puny code support but still don't try emojis. Yeah I remember there's the story about when the Yugoslav war especially the one in Bosnia broke out. There were about 100,000 Bosnians that fled to Switzerland and about 50,000 of them were granted citizenship but they couldn't be registered in the citizenship register because that only supported 7-bit or 8-bit ASCII but no diacritical sign of Governor Jimmich. I think they fixed it by now but that was quite a thing some years back. Yeah I see no further question. Oh yeah there's one excuse me that came in right now. Is there a uniform way to generate puny code over multiple platforms? Mobiles do not work well with entering unicode numbers as we all know. I'm not sure I understood this correctly but the easiest way that that I used during my testing was simple online converges that would work on every page and actually my system doesn't have a shortcut for emojis so I would always copy and paste the emoji from Emojipedia into an online puny code converter and just use it from there because I don't actually use emoji that much. Okay we have come to the end of our time we still we'd have another minute or two but we have no more questions and thank you in the meantime for coming and holding this talk you'll have another talk I think it's tomorrow.


All right. Good morning, everybody. Thank you for coming to our session this morning. My name is Joseph George. I'm the director of Cloud and Big Data Solutions at Dell. Thank you so much for coming out to our session today to talk specifically around OpenStack and the enterprise and how customers of ours are help proving how OpenStack is making it into the enterprise markets. Just very briefly, let me talk through what our format will be today. We've got 40 minutes to talk. I'll introduce my esteemed colleagues here that are on the panel individually in just a second. We'll talk specifically around some of the trends that we are seeing in the market today. When it comes to cloud, Dell has actually been a part of the OpenStack movement since July of 2010, since it's very beginning, and was the first to actually bring an OpenStack solution to the market, the first to bring a deployment tool like crowbar to the market. So we pride ourselves on being first there. So being first gives us a benefit to actually have the most history to see what actual customers are using and deploying, and we'll talk through some of those challenges. And then we'll get into some of the details around how our enterprise customers are getting into OpenStack and into the cloud, discussions around commercial options versus open source and some hybrid options in between. We'll talk about multi-cloud and the realization that public clouds exist, VMware, Microsoft cloud technologies exist, OpenStack exists, even multiple OpenStack clouds exist that need to be communicating with each other and managed together. And then we'll also spend some time on management and operations. And I'm gonna make sure to reserve some time toward the end to open the floor for any questions that you might have so that once you get to hear some of the wisdom from some of the folks up here, you can actually test to see if they really know what they are talking about. So let me kind of go through this first of all. Once again, my name is Joseph George. We are, I'm part of the group at Dell that runs the infrastructure solution business. I also sit on the OpenStack board of directors for representing Dell. Also with today, and I'm gonna kind of bounce around here is George Reese. He is one of our executive directors in our Dell software group. He is also one of our senior distinguished technologists at Dell in form of the CEO of, the CTO of Enstradas. If you remember that before Dell acquired and now he's a senior leader here at Dell for us. So welcome George. Also with us is Campbell McNeil, also in the software group as a senior principal engineer. Campbell has actually worked in various different parts of Dell and has seen a lot of different angles of how cloud is consumed from the infrastructure perspective, software perspective, as well as services perspective. Next to him is Kamesh Pemaraju. He is our OpenStack solution product manager, senior product manager, and has the benefit of interfacing directly with a number of customers around the world, specifically around how they are consuming cloud and how they are consuming OpenStack. And really Kamesh's job is to making sure that the package solutions from Dell have these functions and features so that customer can consume it more readily. And then finally, last but not least, is Peter Young at the very end there. Peter is in the Asia region and is our cloud and big data consulting expert and also has the benefit of interfacing with a number of customers on installing and making OpenStack successful in customer accounts. So thank you gentlemen, I appreciate you being here today. Before we get into the questions, we'll talk a little bit about what we're seeing. When we look at the OpenStack community today, we are speaking heavily to the developer community. The base source code of OpenStack continues to be evolving over time. I would say with the most recent Grizzly release this past summer and then the Havana release that just came out, it is getting more and more digestible and usable by the mainstream audiences for the workloads and use cases they want to use. So we're seeing that evolution happen. In addition to that, we're starting to see that cloud is becoming more of an enterprise option for a number of our customers on a regular basis. In fact, this data actually came, I believe this is IDC that said that in Asia in particular, we're actually seeing IaaS offerings starting to grow tremendously and that it's up to a $13.5 billion market by 2016. So for us, it's actually a really interesting time. For Dell, we have the benefit of being as a part of this early and regularly involved in how it's evolving, but we see that OpenStack in particular is able to start taking advantage of some of these trends as customers start seeing the need to use cloud. And one thing that we have learned as the last comment here is rarely are customers coming to us and saying we want cloud. They're coming to us usually saying we need to find a way to virtualize our network functions or we need to find ways to deliver content and distribute content in a scalable and a cost efficient manner. We need to build a test development environment. Those are the questions that our customers are looking to answer. And this is why cloud has now started to become a technology that they can consume. It's not about cloud. It's really about how cloud enables them to solve some of their problems. So with that, let's go ahead and jump in and talk a little bit about some of the starting points that our customers kind of engage in. Kamesh, let me start with you. And let's talk about how customers are given choices about how they want to implement cloud. They're commercial offerings. There are open source offerings. Obviously, a lot of us in this room here today are big believers in open source. What have we been hearing from our customers as when they're considering getting into cloud, what are the benefits of open source versus commercial? What are the thought processes there? So I had the benefit of talking to a number of customers. The key takeaway for me was it's never about one solution. It's a hybrid world truly. And we have seen yesterday at the keynote that hybrid is being emphasized so much. The reason why most customers think about open source is a couple of reasons. One is they want some level of independence, some freedom from vendor lock-in, and we've heard this over and over again at this conference, more importantly, flexibility. They want to have some level of control over their own destiny, especially service providers who want to get their services out there much faster than their vendors can support them. So if they want to fix for a bug and their customers are sort of stuck, now where do they go? They go to their vendor and the vendor says, yeah, wait for the next release. That's not gonna work for them. So they want to have some level of control over their own destiny. The other big one, and we have seen all the case studies yesterday at the keynotes is scale. I mean, we are talking millions of users. And the most typical customers we deal with are service providers, hosting providers, folks that are moving to large-scale cloud services for their customers in the public space. Even large enterprises, even within their own departments that want to create services for their own employees, they are facing the same issue. And lastly, cost is an important criterion, right? I mean, if you're doing a VMware implementation and you want 10,000 VMs and all of a sudden you're spending a chunk of your OPEX on license fees, and that goes away with open source, that said, open source is not free. I'm sure all of you know this. You still need the skills and you need the way to manage those things on your own. Okay, very good, thank you. So really it's about control of roadmap, flexibility of roadmap, scale and cost. And when we talk to customers, we know that cost is not free, open source is not free, but it actually gives you some, actually control over where you want to spend your dollars. So Campbell, let me ask you, as I said earlier, customers are rarely saying I want cloud. They usually have something behind it as to what they're trying to accomplish or multiple things. Maybe you can comment and actually I'd welcome some others on the panel as well. Feel free to chime in. But Campbell, why don't you start on some of the things that, some of the more common use cases we're seeing where customers are trying to use cloud to solve. What I'm seeing more from our customers in the software division is that the cloud is an enable or a cloud enables them to enable business and let the IT department get out of the way of the business consumers. So from that point of view, what our customers are looking to do is to commoditize the back end, not have specialist infrastructure there. OpenStack plays very, very well in that and allow a very flexible consumption model, whether it's public or private, about what services you're going to deploy in that cloud and effectively let the business people deploy services as and when they need them and support their business functions, very, very quickly with automation, that kind of thing. Get away from the whole legacy IT model where it might take three weeks to get a VM or something like that. Now we're seeing customers wanting to be able to provision a collaboration site or a website or something like that within minutes and we're able to do that using cloud because the infrastructure is so flexible. Great. Peter, in the Asia region, do you feel like the, it's on, the use cases are similar? Are there other ones that are more prevalent in this region or can you talk about maybe in your experience where is the Asian market looking at deploying this and what use cases? Quick answer is it depends because I'm based out of senior Australia but I cover whole AI packs. So every single destination, every single country, every single segment, all different requirements. So what I'm trying to do is at least try to be able to understand what they're trying to achieve out of the open state initiatives because typically we all, you know, engineering background, a lot of people, you know, folks in engineering background, we tend to approach it to try to solve the problem and define the problem from engineering perspective but actually cloud isn't just a technology. It's actually really business. So like a different approach and try to understand, you know, what their real problem is try to solve is actually, you know, for me to be able to make a difference. So yeah, use cases, many, many. So sometimes some people are trying to, you know, apply traditional HPC applications on top of open state. So if that's the case, performance issues, back end storage issues. So can I just deploy, you know, lost systems on top of open state that's a kind of research cloud, we call. And Australia, you know, try to have that kind of initiatives and a government funded, Japan does, Korea does, Singapore does, and also China does. And the service provider in a business that's a totally different story.  Now the domestic tech will try to evolve into cloud service provider. Now it's all about business model. You know, obviously there are core competencies with local support, local language support, marketing, et cetera. And sometimes bundling them, they're traditional network services as part of the other cloud bundling. But obviously they kind of lack of traditional lack of core capabilities like a software development, et cetera.   Okay, great, great. In fact, I will just say this, that just this week, Dell actually published a case study with the University of Alabama, where they were actually looking to build up a research cloud. They were using technologies specifically OpenStack and using CEP as a storage technology as well. I've actually got a few copies of this up here. So afterwards if you're interested in learning more, feel free to come up or stop by the Dell booth and we can let you know more. So something that we're kind of hitting on George is, you know, this notion of their, you know, customers will be using the public cloud. They will be using existing virtualization technologies that they have in their environment. As we pointed out earlier, it might make sense for different OpenStack clouds to exist for different purposes. With all these different cloud types, does this mean that OpenStack is just not good enough or how should we think about multi-cloud in that sense? Well, people want to believe that there's one cloud that fits all and it's not a shortcoming in OpenStack or any other cloud, but the reality is there is no one-size-fits-all cloud and certainly not for the next five years, at least, will there be such a thing. So, you know, if you forget just the issue of do you want all your eggs with one vendor, when it comes, especially when it comes to the public cloud, there's just the reality that, you know, I would not take, you know, Exchange, for example, and stick it on an OpenStack cloud. You know, there are a lot of legacy workloads that have been built around the way VMware packages and provides resiliency to applications that are just best suited to being in a virtualized data center or maybe a vCloud environment. And it's not a weakness in OpenStack that OpenStack doesn't serve that market well because what OpenStack does is provides, ultimately, customers what they want.   I'm getting used to that way of consuming stuff, so I want that behind the firewall. IT, on the other hand, often hears I want cloud and then gets told by their legacy vendors, hey, this thing we're already selling you is cloud. And so they end up with this checkbox. So there's this mismatch in expectations. And the reality is you need a definition of cloud that meets both needs. And OpenStack helps provide that on-demand self-service behind the firewall. And you need other technologies to support those legacy virtualized data center needs. And the same thing applies as you get out into the public cloud as well. And you need not just different technologies at the infrastructure layer, but you also need solutions for platform as a service and SaaS. Okay, very good, thank you. So on that vein, let's kind of extend it a little bit further and I'll pose this to Campbell. But again, I'd like the rest of the panels to comment. When we talk about cloud, like we've said, it is a public cloud is just going to be part of the equation for some things. And a on-premise customer-managed, user-managed cloud is going to be part of that as well for reasons like security and compliance and things like that. Then also there's a need for, in some cases, to have something on-premise that's cloud-oriented but managed externally. What I'd like to talk about is where, from our experience with our customers, where are we seeing customers make choices to say, okay, I'm going to put this sort of workload in public clouds. I'm going to put this here on-premise and I want to manage it. Or I want to have this on-premise but I'd like someone else to manage it. Those three permutations particularly, let's talk about where you're seeing what UC cases are driving, which solution. Yeah, there's a couple of reasons why customers might go down different routes. I mean, one of them that's popular, I see with a lot of customers, is the link you're getting in public cloud. It's very much an OPEX model. They can get started very, very quickly. As they become more successful, they actually will see benefit by bringing it in-house. It can be cheaper that way. They probably don't want to have the, you'll have all their risk with the vendor, that kind of thing. They want to assume that risk themselves and be able to assume the level of control they need. As you mentioned, Joseph compliance is a big one. A lot of our bigger corporate customers, public cloud just is not an option for them. They have serious compliance requirements, physical control of the hardware. They've got to vet the people that are touching it. They've got to know where everything is at any point in time. If they deprevision something, they've got to know that it has been destroyed, that kind of thing. They just need that level of control. The other thing as well, and what we're seeing from our clients is, they might need that level of control, but obviously to be successful with cloud, you need a very, very high degree of operational competency. So they might go for the managed service model, whereby they can actually leverage maybe our operational competency, get up to speed themselves and then potentially take it on themselves or just continue to let us do it for them. The other thing as well is, some of the models we see is, they might want a consumption based model and an OPEX model, but we're having the physical controls.  You know, we provide that model for them as well. That's appealing to some customers. So it's really, there's no size that fits all. Where would you say that it makes sense for someone to actually have a managed environment versus managing it themselves? Experience. Experience, okay. Yeah, I mean, I think we all know here, you don't just, it's not a turnkey solution, no cloud is a turnkey solution. It takes time for people to get up to speed, understand cloud, understand how to operate it. You know, we can help them do that. We can get them started quickly, you know, so they can give them time to value by using their operational expertise and then as in wind, if they wanna take on themselves, they're welcome to help them do that. Okay, great. Others, thoughts on that?  So it's like, you know, bi-directional communications is a buildup that holds blueprints, that's kind of a starting point to be creating solutions. Okay, very good. I guess I'd add into this conversation and I think ultimately the migration into a public cloud is inevitable. That private cloud is sort of this transitional thing and, you know, maybe that's wrong and the beauty of the multi-cloud manager product is we don't care, but my, you know, belief is that companies will move towards eventually doing most things in a public cloud environment but today it needs to be a mix and in a lot of cases it's heavily weighted towards private cloud. I guess the point I'd add into this is that it is important to have both pieces as part of your strategy today. That's very important. How important is it for each of these three options to be architected similarly? What's the value there? I'd be interested in hearing your thoughts and comments as well. You mean the underlying cloud? Yeah, actually how you build the cloud on-premise, how important is the architecture of that versus what's running the public cloud in order to be able to migrate workload. So, from a multi-cloud perspective. Well, later today I'm actually on a panel with a number of people that's focused on the question of portability applications in the cloud and, you know, one of the promises of OpenStack has been supposedly that, you know, by picking a public cloud that has OpenStack and doing OpenStack as your private cloud, you magically have workload portability. And, you know, VMware is trying to sell that nonsense to people in their hybrid cloud stuff. The reality is that the cloud platform, whether it's VMware or OpenStack or something else, doesn't give, I mean, even eucalyptus, which is built around the idea of homogeneity between private and public, doesn't give you workload portability between public and private. It really starts with how you architect your applications so that they can be agnostic of the environment that they're being deployed in. And then, you know, either you're doing it for pass or you're doing it for infrastructure service in which case, you know, in the past sense, you need a pass platform in the infrastructure sense. You need something like multi-cloud manager that is going to take that application that's agnostic to its infrastructure and do the puppeteering and moving it around to where it needs to go. So I don't know how many of you are following the big debate or big discussion that's happening within the OpenStack Foundation right now about core versus non-core. What is a core OpenStack project? How do you make sure that HP's implementation of OpenStack is similar or at least interoperable with Rackspace's implementation of OpenStack versus Dell's versus somebody else? So it's a very controversial topic because we're still trying to figure out what makes a cloud interoperable? How do you actually port, you know, applications from one to the other? Is it just API compatibility? Is it behavior compatibility? Obviously, the implementations will be different because the cloud providers want to differentiate themselves. So there are lots of moving parts and even within the OpenStack community, it's not an easy problem to solve, let alone talking about multiple clouds from different vendors. So it is an open question and please be sure to come to this panel because these topics would be debated and talked about.  In fact, the board, the OpenStack Foundation Board is taking this on as a discussion point. We've got a committee that's actually working on projects that are actually talking about it exactly on getting that to work because that is one of the promises of being able to do this at an open level. So let's kind of take that and let's kind of go to a next, one of the use cases I hear often right now is around storage. The use, the case study that I just spoke about a few minutes ago was heavily based on storage. So Kamesh, let me direct a question to you here. Because what I'm hearing, even at this conference this week, a lot of people are looking at OpenStack and SEF and other things like that as storage as the first way to really implement OpenStack heavily and production in their environments. And I know that you've been very close to storage as a service via OpenStack and SEF. Let's talk a little bit about what you've learned with what our customers have been successful on, some best practices and things like that. So storage is really, really hot in the cloud. This has become a big challenge for most customers. So we have solved the scale problem and the virtualization problem and abstraction on the compute side. That's a solved problem. But the same is not true for storage, right? So customers are looking for similar type of characteristics. How can I scale massively? How can I get the level of storage that my customers are demanding? How do I do it in a centralized location? How do I manage it efficiently? All these questions are popping up now on the storage side. So every customer that I talk to that's interested in OpenStack is also interested in scalable cloud storage. And of course, there is Swift, but it's not just about object storage, right? Object storage is great, it does, it has a use case, it has a certain uses. But now customers are asking, what about file access? I've got a whole bunch of legacy applications that I want to move into OpenStack. I don't wanna change any of those. I still want to use my file interfaces that I've used in the past. What solution do I have for that? That's scalable and that's software-driven, right? So that's one aspect. The other aspect is block storage, right? How do I get the same kind of features with block? And this is where we are finding Ceph as a very popular platform because it actually supports object, block and file in all in one single platform. And that's software-driven, that's algorithm-driven, it's highly distributed. So there are a number of considerations, right? You have to know what your use case is. Is it just the most popular ones that we see is archival, cheap and deep, as we call it at Dell, right? So you want a backup and an archival solution that's very cheap, whether it's for your objects or your full blocks. You need some level of multi-site replication built into it. These are some of the features that customers look for. And ideally, they want one solution. They don't want Swift for object and block for something else and file for something. Then all of a sudden, you have a management nightmare. So you just want one solution that works with OpenStack in a seamless manner. And that's exactly what Joseph was talking about. UAB is sort of a classic case study of this because they want it all free. And you will read more about that in the white paper, but they have researchers, over 900 researchers that are looking to basically, today it's a nightmare because they have storage in their USB sticks, they've got storage in their laptops, desktops, it's all over the place, there's risk management, and there's no single centralized way of managing it. And that's what we have solved with UAB, with OpenStack and Ceph all deployed using Crowbar, all done within three days, actually. So it's a pretty nice case study when you get a chance, check it out. Obviously, another customer case from Australia, the ANU Australian National University, they want to build the kind of cloud for traditional HPC researchers. Technical requirements from the HPC researchers is very, very demanding. So one of the first question is, is there any storage or file systems or block storage systems, software defined storage systems that supports and be able to meet the demand from the researchers? So we found a surface, a good alternative. So at the end of the day, we just figured out, try to figure out how to increase the whole performance and provide a block storage service for the researchers and eventually attach the virtual machine. So we chose CEPH, obviously ANU chose CEPH, and then we actually helped them architect CEPH-based backend storage to meet those demands. Great, I will make one more comment. Even in the storage, it's a hybrid world. So we can't get away from this hybrid concept. So it's a multi-storage world, meaning that CEPH does not necessarily address all use cases. If you have a high IOPS situation, you want to put a high performance database, CEPH is not the way to go, right? It's great for archival, it's great for backup, it's great for dev tests, researchers trying to do some applications. But if you really want high IOPS, then you're probably better off with your traditional sans. So, I mean, Cinder is great because you've got plugins for almost every major manufacturer has their plugins for their devices. So if you're looking for high-speed storage, put your database on it, and you want to do parallel processing and things of that nature, there's still a use case for that. Use Cinder, it's great, OpenStack supports all of that. Okay, very good. Now, I will say that in just a few minutes, I'm gonna ask one more question, but I'd like to open the floor as soon as we ask this question. So start thinking about questions that you might have to post to the panel. And after this next question, we'll take some questions from the audience, okay? And the first question will get a prize from me, I'll find something to give you, okay? So the last question I'll talk about is obviously applications are also driving this change, right? It's not just the need to do certain workloads, but applications are evolving, applications are changing. So let me ask two different questions here, and maybe Cam will start with you around the applications. So customers in this room that are looking at developing applications in-house for these new cloud environments are the things that you can maybe recommend? Are there things, you know, suggestions on how they should tune or architect to develop these applications? Well, from my point of view, it's really about, you know, thinking about the platform you're gonna run on. Once upon a time, we could make certain assumptions about where we put our state, you know, where we put our data, that kind of thing. To make those assumptions now, it really restricts your runtime environment. If you want your application to be flexible and where it can run, using tools like Multi-Club Manager to facilitate that, you really have to, you know, think about, you know, where you put your state, you know, don't put any state in things like your web tier, your app layer, so you can horizontally scale those and load balance between them. And, you know, basically design your application up from the start to share nothing, be generally stateless, and, you know, really think very, very carefully about what you have to put in the backend and how you're gonna actually manage the resilience of that ultimate backend data store. The previous assumption was you put Oracle or SQL Server in there or something like that, you put it on a sand, you use the sand, you spend an awful lot of money on a sand to protect that data. You can't make that assumption in the cloud. So George, in that same vein, if we know that this Multi-Cloud topology is what's going to happen, are there additional tenants that, you know, we should be thinking about when we're writing these applications, knowing it will likely be in Multi-Cloud, then we want the flexibility to be able to move it across clouds. Well, you know, the snarky answer that I give people now is often, you know, the key to building applications for cloud, for a Multi-Cloud world is to do what you're supposed to be doing in the first place, you know. There's not a lot of that happening. Yeah, and, you know, the really it is about following best practices for horizontally scalable, share-nothing distributed applications. And, you know, in the real world, your job as an architect is, where you make your money as an architect is identifying the right places for compromising when against best practices and here's my real deadlines and my real budget and all that stuff. So the challenge really, and so we make these compromises because of certain things we know about the environment, the way it is, and the way it might evolve over the future. The challenge with cloud is that all of those compromises that we're used to making intelligently come to bite us in the ass. And so the compromises we can make for cloud applications are very different and less forgiving, actually, if you want a truly cloud agnostic application architecture.  Right, that's right. One thing that happens often when I'm talking to customers is they'll say, this OpenStack thing is great. I want to move my SAP application to it or my PeopleSoft application or exchange application. The first thing I would ask is why? Why do you want to do that? What benefit are you going to get from moving to OpenStack? And they'll say, oh, I save a lot of money on that. But then you're not really getting the benefit of cloud because these applications are built or architected for scale up, not scale out. So if one of the servers goes down in the cloud world, you spin up another one and your application should be able to take advantage of that. These legacy applications don't do that. That's right. We call them evolutionary applications in Adele and versus revolutionary, which is mobile, scale out, web-based applications that are built for with those tenets in mind. Sure, that's right. Good, and it's actually a really important point as we kind of wrap up this portion. Over the last four to five years that we've been working in cloud Adele, one of the most important lessons that we've learned is when a customer approaches us and said we would like to learn about cloud, our first question is actually back to our customer. Let's understand your situation first, right? Do you have a team of developers? What commercial virtualization products do you have in your environment already today? What type of investment are you looking to make? Do you want to institute things like DevOps? Or are you looking to use certified admins already in your environment? What type of cost layouts do you have? Those are the types of questions we start asking because ultimately what Adele wants for our customers is that the customer gets the right cloud for them so that they can be maximized their chance for being successful. That is our goal. Customers come to Adele and have their maximum chance of being successful on a cloud. That is our objective. So we've only got a few minutes left. I'd like to see if there are any questions in the crowd. Let me run out there and do this. Sorry, sound guy. I'm gonna give you a mic here. And if you wouldn't mind just sharing the mic up there. Thanks, George. Could you please go more details into what kind of scale out enterprise applications that you have seen on OpenStack Cloud? We talked a lot about asking customers why they want to move, but what successful use cases that you have seen, like more than web app or very generic apps? Let me take a crack at that. The most common use cases we are seeing is service providers trying to create an infrastructure as a service for their customers. So think Amazon, but on OpenStack, right? Rackspace being a perfect example. So service providers is one target market. The other target market is what we call mainstream enterprises. Think ExxonMobil or GM or some such company. What are they trying to do? What they're trying to do is create a, the most common use case for OpenStack is a development and test environment on OpenStack. That's the most common one. The other one is content delivery, right? They want to create a collaboration software within their environment or they want to have a website for whatever internal SaaS applications. We're not seeing, I have not seen, although we have seen some case studies here at this conference where you're seeing more mainstream applications like, I wouldn't call them exchange, but sort of like Google mail type of things that are coming to the enterprise, right? Inside their enterprise. That requires a web scale. That requires scaler applications. That requires OpenStack. Yeah, I guess my team sees this from a different perspective because we're often in these multi-cloud contexts and the OpenStack user base tends to be, so we're not as heavily involved on the service provider side. So it's all about enterprises and medium-sized businesses. And OpenStack actually has a different user base than say, certainly a VMware-based cloud and to a certain degree like a cloud-stack-based cloud. It's much more developer and grassroots-driven typically. So most of the use cases that we see in the OpenStack infrastructure are around that dev-test type stuff. Obviously, mobile applications, I mean, everywhere will be like a game service providers. You know, they want to build a new mobile game and they want to test drive in a marketplace and they want to get it short and then agile and responsive quickly as possible. That's one application I can definitely say today. Some of the convergence happening in the marketplace is like a traditional tackle and a cloud. It's got two discrete kind of technologies and domains. Now try to multi-edit convergence. Tackles like tackle-initiated network function virtualization, they want to do something network function virtualization on top of the OpenStack and try to leverage it. That's another part of the application that I'm seeing. All right, let's take one more question here and before we wrap up. When you talk about SAP, you said it's a scale up and not a scale out. But have you tried to do something with OpenStack in performance testing and development environment, education, something like that with SAP? Have you experienced on that? You're talking about SAP? Yeah. Like I said, SAP and PeopleSoft, all these applications that are typically used have been designed for the legacy infrastructure environment. VMware is a great example. I can't speak specifically towards SAP but one of the engagements we've got on with a very large bank in the US is they're looking at OpenStack for their future runtime environment for all their stuff. We've got basically a performance engineering competence. We've actually got a team that has developed a workload. You might have heard of it, it's called DVD Store. It's like an interior application which we can drive a heck of a lot of load through. What we're doing with that customer basically is benchmarking that application. It's a very known state on OpenStack and competitive clouds, that kind of thing. What we're doing is right down at the level we're actually seeing which cloud consumes more power, that kind of thing, which one's going to be the cheaper to run for that. To give you that application level performance, and we've basically got a stage level of benchmarks which the customer can then say, maybe it's SAP, maybe it's an Oracle database, whatever that workload is, they have a known state. They have a reference implementation, a reference benchmark that lets them compare the requirements of that application against something they know and then they can make the decision is our OpenStack configuration capable of it? If it's not, we can either go to a different vendor or we can tune our OpenStack implementation. Instead of using SAP, we can put a Sam behind it, that kind of thing and we can get the level of IOPS required to drive that workload. But it all starts with a known benchmark. And I will say in the business that I run, OpenStack is just one part of it. When it comes to things like SAP HANA, especially in the education spaces, we're actually seeing far a lot of adoption around the Hadoop technologies as well. In fact, we have a number of customers that are actually deploying Hadoop with SAP HANA and they're actually finding quite a bit. A lot of our bigger university customers are actually doing this at large scale. And we've just actually introduced a white paper from Dell around Intel distributed Hadoop on SAP HANA. So we've actually got some information there. I think we're seeing more there when it comes to universities and education, I think we're seeing more in terms of like basic distributed storage as a service as the more prevalent use. And also benchmarking around the Hadoop stuff is the thing we're doing too. So I'm happy to answer any further questions. Now I will say this, each of these gentlemen will be here for just a little bit. I want to make sure we're respectful of the next people coming in. But they will also be at the Dell booth. So if there are questions that you didn't get to ask, feel free to ask us there. Thank you for your time, come by the booth and there's a new ping pong table out there.  Thank you very much.


Again, we bring you another chapter of Edgar Rice Burroughs' amazing history of Tarzan of the Apes. The astounding record of a superman who became the master of beasts and the mighty monarch of the African jungle.  From his natural parents, he had inherited fineness and intelligence. And from his foster mother, Kayla, and the ape tribe, he had acquired tremendous strength, amazing agility, and animal cunning. And from twenty years since his abduction, we find Tarzan swinging through the jungles. A young man splendid both in his youth and manhood. Carelessly, Tarzan's body swings from branch to branch. There's an easy grace about his perilous leaps and accurate catches as he progresses from limb to limb, which suggests both the assurance of the ape and the flowing rhythmic grace of a trained trapeze artist executing an often rehearsed feat of daring. Tarzan is off on a holiday.  A tiny hut on the shore of the great water. It has taken him many years to learn how to manipulate the odd mechanical thing which had swung open to him the door of that hut, which he would have been surprised to learn was the home of his mother and father and his birthplace. However, the door of that hut had opened to him more than the interior of the rude cabin which Lord Greystoke had built for his wife and son. It had taught him that he was an M-A-N, not an A-P-E. It had taught him to read and write after a fashion. For hour after hour, year after year, he had poured over the first primer which he found there. But perhaps more important to his physical being and survival, it had given him access to the hunting knife which hung at his side and the locket which dangled from his throat. Occasionally, Tarzan left the ape tribe and ventured to his hut near the seashore and now he's making his way there. It's late afternoon. The sun of a dying day is filtering through the dank foliage of the trees to make an intricate pattern of onyx and gold on the spongy mold on the ground beneath. The jungle is reverberant with sound. The chatter of monkeys, the singing of birds, and the occasional growling and snarling of the larger animals as they make their imperial way to the waterhole. Tarzan is happy. Happy is a schoolboy on a holiday. Swinging along is tireless of boreal way he inhaled the dank pungent smell of the jungle with poised delight. In the grim grandeur, the poisonous beauty of the jungle fills his soul with a feeling for which the ape language has no name. Meanwhile, off the West African coast, a small tramp steamer is flying her way through a placid sea. In the tiny saloon of the ship are four people. Professor Porter, an old savant who exists in the present but lives in the archeological past, his daughter Jane, a beautiful girl whose charm is not only that of beauty but of wholesome loveliness and intelligence. Of these charms, the young man of the group is fully aware. He is William Sassel Clayton, a young Englishman, typical of the blonde blue-eyed Oxford gentleman and eldest son of Lord Greystone. The other man in the salon is the captain of the ship. What are you reading, Father? Yes, of course, my dear, of course. I asked you what you were reading. Oh, sorry. A book, Jane, one of those dusty ones that you persist in believing gives me my heave fever. It's called Africa Cristana. Mochilli wrote it in 1816. Only 1816? That's rather current fiction for you, isn't it? Well, a man ought to keep up with modern literature or he's liable to become an old fogey. I suppose anything published after the flood would be considered rather modern by an archeologist. Who wouldn't it, Professor Porter? Oh, yes. No, no, no. What did you say? Oh, go on with your reading, Father. We won't disturb you anymore. We're almost there, aren't we, Captain Tracy? I beg your pardon? Well, honestly, I don't know which is the worst. You were Father.  I'm the only one aboard that seems to find me most fascinating. But you're forgetting me, aren't you? Well, one could never forget anyone so gallant. But really, Captain, a person would think that you were burdened down with all the worries of the world. Not all of them, Miss Porter, but I'm afraid I have my share. Really? What? Merely a matter of ship's discipline. Nothing really important, I hope. Thank you, Father, sir. But I'd like to see you, sir. Yeah, what kind of discipline is this, Newton? Coming in without knocking.  Yes, sir. Sorry, Milady. Yeah, well, what is it? What is it? I'm afraid, sir, it... Don't ever let them know I told you, sir.  That's what they do, sir.  That's life, sir. What are you talking about? New Guinea, sir. Down below, Dexter. They're all in the folks, sir. New Guinea? New Guinea? Isn't there some law about that? New Guinea, eh? I smelled it coming. That rotten crew we shipped it said. My compliments to Mr. Yonk, Newton. Tell him to report to me at once, here. I'll batter those decked guys down in their hats and scuttle them like rats. Pardon, sir, but it's the first day you ought to sleep in New Guinea, sir. He's down in the glory. I'll talk to him now, sir. Oh, yes, sir. Is there anything I can do, sir? I don't worry, Clayton. I'll clean this affair up in a minute. You'll keep Miss Porter and the professor from being frightened. I'm not at all frightened. Big pardon, sir. I'd better get in there, though, before they misfit me.  All right, sir. I'll remember this. Go below then and save your skin. Thank you, sir. Mr. Clayton, you'll find two automatics in the drawer of that desk. You'll take one and come with me, certainly. Well, what am I going to use? Good morning. It's Newton. Come on, Clayton. Righto! What matters?  We're barred in! Ah! While the voyagers from the world outside are at the mercy of a Newtonist crew, miles away, Tarzan is hanging from a tree branch, overlooking a clearing in the forest, and sees the beginning of a jungle tragedy. Say, poor the lioness is dozing, surrounded by her happy family. One of the cubs wanders beneath the tree that hides Ishtar, the snake, the silent, strangling horror of the jungle. Ishtar, hungry and alert, drops part of her great and snarling link down from the branch and circles the cub, draws it up into the tree to slowly force it down into a constricting being by the unrelenting, torturous contraction of those great reeling muscles. A labor of a lioness, a waste of the danger with a snarl of mingled rage and anguish, hurls herself with a terrific leap to rescue her cub. She misses. Again and again, she leaps in a panic effort to reach the snake. A roar shreds the chaotic monotone of the jungle into feathers. Say, poor Ishtar's language moves Tarzan to pity. He falls forward, giving himself a tremendous dippin' with his legs and catapults himself through the air. It's a tremendous leap, superhuman. He's leaping for the end of Ishtar's tale. If he makes it, he may not be able to cling to that slimy, lashing length and will fall to the infuriated beast below. He won't make it. He won't. He does. He slips. He slips. He holds. His weight nearly jerks his salute from the branch. Like lightning, Ishtar contrasts a lash into the ground. Tarzan lets go, drops to the branch beneath. Grasping at just in time, he falls fast. He dangles for a brief moment, but just for a moment. A snarl warns him. He's hanging close enough to the ground to be a link to St. Paul's vicious leap. He pulls himself up to the branch. The tip of one of St. Paul's claws cuts a tiny gash in his heel. He stands on the branch, gathers himself for a leap. Oh! Ishtar's seamless body slaps itself around his waist, takens. Then slowly, he mentions to draw him up to the branch of the ball where it can hold him fast against the branch and exerts a terrific pressure which will crush him. Tarzan struggles terrifically, but slowly, slowly feels himself being drawn. Tarzan's mind races. For the great effort he unwinds, the grass rope around his waist. He senses the long-hunting knife in his teeth and punches him into the narrow part of the reptile's tail. The snake rives, but doesn't lose its hold. Hasteily, Tarzan works the blade through the resisting muscular strength until the handle protrudes on end and the blade at the other. The serpent agony has caused it to lose the distance gained in drawing Tarzan to the branch on which it lies. Tarzan is on the level with the branch from which he's drawn. Curiously, he ties the rope above the knife, letting it slide down the snake's body until the knife keeps it from slipping. Then, wishing like a madman, he snubs the rope around the branch. Hister screams. The branch creaks ominously, but doesn't break. The pain of pulling against the knife in his body makes Hister slowly release its hold on Tarzan. Unable to let go of the branch above and secure to the one below, the great serpent is all but powerless. Its body is stretched up almost straight. Its dreadful leverage is gone. Tarzan climbs up the trunk of the tree, gains the upper branch. The cub is still struggling feebly. Tarzan still tees in the tree, extends his legs out, locks them around the branch and hits his neck in what is known as resting as a scissors. He applies the pressure of those powerful legs. Harder, harder, harder. Pulling the lion cub from the mouth of the reptile with one free hand. Hister's great mouth opens wider and wider. No longer eager to keep up play, only anxious to escape the pressure of those powerful legs. The cub is swinging. Tarzan swings down, drops the cub gently on the ground and up again on the branch before Zabor can furl herself upon him. Zabor, seeing the cub restored, pounces upon it, yicking it, turning it over gently, the cub recovers its breath and wimpers. Conduced as a rough spring is safe, Zabor turns her attention to the thing up in the tree. Tarzan sits panting. Streams that after his good deed, Zabor should be anxious to attract her into rhythms. Jungle gratitude. However, unbismayed, Tarzan looks down into the baleful eyes and snarling face of Zabor. There's an ominous creak, a splintering, the limb under Tarzan is hidden away. He's falling. Falling into the mess with things and furl across the Zabor. He crests the small branch. It breaks. Tarzan's lunges downward, downward, falling to the ground. He breaks the ground and he's head and shoulder. They lie still.