 Hi. How are you doing? My name is Kerr Kim. I'm working for Samsung SDS. And hopefully everybody is enjoying this summit. Today I want to talk to you about the Samsung SDS personal cloud. Yesterday I was doing a duty at the booth and a lot of people come by and ask me what is a personal means. Well, in this case a personal means B2C. As you know, we are providing a lot of different services through the devices. So today we're going to talk about that and what we did and what we're going to do in the future as well. So before we actually start, I'd like to do some quick introduction of our company. Basically, Samsung SDS is number one IT Korean in Korea. And we have about 14,000 people and 5.7 billion. One thing particular about the Samsung SDS is providing a infrastructure to Samsung groups such as a data center, the also cloud infrastructures and so forth. So SDS has been working on this cloud based on OpenStack for a couple years. Actually, I was here in U.S. a couple years ago in San Francisco 2011. That was probably the second OpenStack summit. And at the time, I wasn't really sure about the OpenStack. Is it really going to take off? Actually, I was looking at some other solutions at the time. For example, as you well know, CloudStack is one of them. And VMware is another. So why do we choose OpenStack at the time? I'll tell you a little bit later. So today essentially what we're going to talk about is ecosystem, how our cloud fits into the P2C ecosystem. And also we're going to talk about details of SBCS in terms of features and history. And then we're going to talk about the global infrastructure rollout based on the hybrid. Because I think that's the key differentiation between how we want to build the global infrastructure compared to what's been doing in the other ways. And the last thing is we're going to talk about what we learned from all this. So first, I'd like to tell you what we think of a P2C cloud service looks like. Obviously, if you look at the infrastructure here, it's a consist of public cloud and the private cloud that we are building, plus global management and operations. Well, I will tell you a little bit later why we are looking at all three options. Because if you look at the, just looking at private cloud, maybe it's a go for certain things. But in order to build a really large scale global infrastructure, we really need private cloud as a part of the solution. And on top of that, we are building a different type of services, message type, content, storage type. Well, we made a very generic services because we really like to focus on the infrastructure today rather than service. But the capability of supporting 100 million points or devices. And obviously, we are trying to also roll out globally, meaning that in America's and EMEA and Asia, maybe a couple of locations each. So this is what we are thinking of the ecosystem looks like. Next. If you look at the why we build our cloud the way we did is because it's driven by the business really. First, business is divided into three different categories. One is predictable high performance. Well, as you know, a lot of times when we are building a catalog, you need high performance storage or even CPUs. And predictable is very important. And then Samsung has a very special requirements for the security policy, which is something that I will tell you a little bit later. And then low and cost flexible infrastructure. In this case, flexible means customized. So these are the things that we need. The answer was, well, we need a private cloud for doing this. And because of the low cost and the flexibility, we need open stack. And we need a dedicated infrastructure. What this means is more like a pair of metal where we can be using it for Hadoop or even for Cassandra. And then the other requirement that we had was unpredictable demand or a low upfront investment. Well, as you know, this is a huge infrastructure. So it will cost a lot of money. Some numbers we see in the market. If you look at the Apple, they said they spend $7 billion or some other companies spend so much money. Samsung is a very frugal or they're very conservative. So they don't like to spend a lot of money upfront. They like to understand what we need to do in order to build the infrastructure step by step. So we decided to actually using a private cloud plus public cloud in combination. Okay. In order to do that, we need a cloud controller and cloud busting or DR. Now, the key is the scalability and the cost. This is the key to success of building a large global scale. And then on top of that, in order to build a different type of a public cloud and hybrid, which is a very complex operation problem, we need to unify the cloud management system in order to operate that. And then also we need a global deployment that meets the user's performance. What they mean is if you're using a device one place and then go to another place, if our infrastructure is now nearby, then performance is not going to be as good. So sometimes we use actually CDN, ADN type of a technology in order to compensate that. So these are the our requirements and these are the directions that we are actually taking. So if you look at it in nutshell, the private cloud, hybrid, and the global operation, these are the things we are looking at to build a right type of a cloud. Now, let's look at the more deeper into our SPCS further. Actually, this is, I'd like to tell you about the history a little bit. I already told you that we are looking at the open stack based cloud two years ago. And at the time, we are really concerned because the Abula was very unstable and they didn't have a lot of features that we need. So we have to build our own, customize the solutions on top of it. Although it's not actually going into the contribution, but we have to build it our own in order to actually prove that the private cloud is right for our solution. So essentially, we built it based on the Nova Swift Glance and Keystone, but we customize a few things along the way, which probably could be thrown away in the future, but this is what we did. Auto boot volume from sand. Well, the boot can be done either through the local disk or from the sand. And we decided to put it from the sand because of a more reliable, like enterprise solutions. We also did a Nova backup service, but there are several reasons to why we did this at the beginning because in order to build a backup for the images, we could have a Swift like the Amazon or we could build our own local storage. That's what we did. So we did a Nova backup service. And then network metering using IP tables. Well, again, we have to build our own special IP tables, differentiates between the public IPs and the private IP so that we can measure the public IPs. And then obviously, most of the people build their own scheduler like we did. So these are the common open stack that we built. And based on this, we actually add a few other additional stacks. Obviously, in order to build right type of solutions so that we can provide a service to the customer, you cannot just build a based on open stack only. You have to build additional things. These are the things that we actually did. So we built our own service portal for the users. And then for the operator, we built our own management portal, BSS, and then automation. We did it based on the Chef. Again, this is something that we are continuously building and make sure that the AI will help us to build a automation such a way that less number of people can operate the cloud. The monitoring, we use and not use. Again, there are three different type of monitoring. We are actually looking into one is infrastructure level. The other one is VM level. And the other one is application level. But obviously, when we are providing a service to our customer, we are looking at all three different monitoring, even though we are only talking about cloud here today. And then next one is network. Hardware load balancer. Well, we use a HA proxy for the software load balancer as well. But the key differentiation at the beginning was we are trying to use a hardware load balancer, which can be shared between the services because of a performance. We are looking at the 100,000 plus transactions per second is a type of transaction we need in order to meet the hour requirements. So that's why we built it. And then last one, the Samsung has a very particular about the security. So they require a physical firewall, not only at the front of the network, but also behind, such as a DV side. So that's another thing that we have to put it in. And then DDoS and IPS is something that we are putting in some locations and some locations that we didn't. So these are the things that we did, and we are going, we are doing. But in the future, we are also doing in these areas. Well, bell metal provisioning. The cloud is mostly based on VM, like Amazon. However, if you are running into Hadoop or a lot of other particular applications, sometimes you need bell metal. So we decided to integrate it as a part of our solution as well. Now, if you are growing the services very big, then what you need is a virtual network. If you are building a very small network, one zone with a very small number of computers, but then you might not need the virtual network. But if you start to scale it, then you do need it. And then top of that, we need a VPC. Why do we need a VPC? Because we want to isolate the certain services from the others. Even though we are using it for most of customers, they are very dear to us. But still, they like to be separated. And so we need a VPC in order to expand our network in the future. So basically what we did is December 11, we actually stand up a Swift based on the Diablo. And April 12, we stand up access version of a Nova and Swift. And then September 12, we actually deploy and stand up in China access version of a Nova. And then now we are actually the in test and ready to deploy based on the force of Nova. And then end of July, we expect to bring it up to hybrid. We are closely working with the rice scale at the moment and then try to make that happen by July. So that's what we are today. So this is something that I'd like to go over one more time, even though I mentioned it, why hybrid is so important for the Clover infrastructure. There are additional reasons why. And also I'd like to use this opportunity to define what is a hybrid. There are so many different versions of hybrid, but if you look at the Wikipedia, then obviously, one definition stands out, which is based on the private cloud and the public cloud. And they are joined. And they are based on the some type of a controller. Now, there is a we added a couple of additional elements or parameters to this low latency and private network so that the you will give you a very strong, the hybrid environment for deploy many different ways, which I will explain to you later time. So in this type of hybrid environment, there are certain advantages we can see. One is the we can build a very agile infrastructure allow to meet the time to market. Obviously, everybody, when they don't have any infrastructure, the best way to provide a service is using a public cloud. Amazon, for example. However, the you can do so much. And then you like to have a high performance or you need an additional reasons such as you like to protect your data internally as opposed to exposed to the public side, for example. So you like to build your private cloud. But you don't like to build a huge private cloud at the beginning because you don't know how big it would be. To see services self is very difficult to predict. Facebook is growing very fast. Last few years. That's very successful. But there are so many services out there. Not successful, or they fail. So what are you going to do after build it? And then are you going to just throw your infrastructure away? Or are you going to use a cloud to. The control the your resources. So at the beginning, you want to start with the very small private cloud based on the one zone. And then using a public cloud as a secondary available zone. Then as you grow, size of private cloud will grow. And then probably will grow. Obviously, we like to use mostly for the cloud busting, which is something that helps us to demand control. But at the same time, this model is not just for one region, but it can be duplicated the other regions. So wherever there is a public cloud, we like to be right next to it and then build it very similar way, which it gives a very robust resource control and the utility or utilization. And the next one is leveraging the public cloud services. Well, the reason why the using a public cloud is that they have a lot of other additional services that private cloud might not able to provide a right away. For example, email at the message queue type of services that we can take advantage of. And then also we can use a public cloud as a DR backup for non sensitive data. In our case, what is non sensitive data? Well, personal data could be. However, if we want to have a log, that's sensitive to us. So that we'd like to protect that information internal to the private side, for example. If we want to look at the hydration rate of a private cloud, yes. Well, typically, when you are rolling out the private cloud, maybe 70% utilization. But if you start using a hybrid, you could probably push it to the 90% so that the I would give you higher of the utilization. Now, there is some drawback as well. That is that you need additional connections to private cloud, public cloud, which is additional cost to the network. And then there is additional complexity that comes with the private and public cloud as a hybrid. The last one is the predictable investment. Well, you want to control at the end. This is all about money, right? I mean, we are building a cloud because of we want to protect our investment. And then we were able to control the our the rollout. And I think that this is probably the best way to do it as far as we can tell. So these are the reasons why we think why we are started looking at the hybrid very closely. So in order to build a good hybrid, we were considering five elements. So first one is a data center, which is we are looking at the very close to the private cloud. In this case, we decided to build it when Virginia because Virginia is a well known for good ISPs and then connections to the public cloud. We are trying to have a latency less than two to three milliseconds. And then for network, there are several ways of connecting it, but we decided to use a data key line. Another way of saying it is a direct connect. And then we decided to use a hybrid controller. There are many, you know, solutions out there. One is obviously a rice scale. And then I don't want to mention others that we evaluated at the at this morning because they might offend some of and that besides the point of the this design consideration is trying to tell you how we are looking at the solutions, not just a vendor. The next one is high availability and the DR. This is a very important because HA gives the looking at the problem as another availability zone, which means the look at the architecture of a public cloud. They have multiple zones. Imagine that if you make another availability zone, which has the same type of performance, then you don't have to build such infrastructure. Not only that, you can take advantage of their storage. Storage is very expensive when you start to building a larger scale because you have to have redundancy built in and you want to have regional backup. For example, Swift requires a three copies minimum in order to have a good SLA's. So why don't you why don't we take advantage of the public cloud storage until you are comfortable and ready to build it? And also the key to having a good application. The three tier type of application is something that everybody is looking at. In this case, we are looking at the MySQL. And for that, we are looking at the active standby and like the master and slave so that in case the master goes, then we like to use a public cloud, the slave to promote to the master, for example. That is one way of looking at the problem. The next one is operation and management. Now, this is not that easy. When you start to looking at the multi-cloud, one has different APIs and then you have a different way of monitoring. So if you have tools like the MySQL, it's very easy to manage. At least, that's something that we don't have expertise. So we decided to rely on the MySQL's expertise on the monitoring as well as operating and deployments. And that really worked out well so that we are trying to have a POC by end of July. That's our goal at the moment. This is something that we like to share because this is actually the key to how putting it together between the public and the private cloud. The network is very, first time, if you look at it, it's very complex. But if we start to looking at it very closely, then it's not that difficult. Now, if you are, if you look at this diagram, this is the private side. This is the public side. And we are creating a VMs that has private and public. This is something that we are using in NOVA, which is essentially flat DHCP architecture. And then we are actually talking to internet through the router. In this case, we have BGP public router. And then when we are connecting to public cloud, we are using a private BGP router, which is recommended by public cloud solution. And if you look at it, we can not only talk to object storage or their compute resources, and using particularly their public IP addresses, it can be going through our firewall so that they are secured, which is an advantage of this architecture. And the second one is that we can also talk to through the internet. Well, in this case, it does not have to be in the same region. It could be different regions so that we can communicate. So one is creating a network very approximate so that they have a very low latency. And you can access to their public storage as well as their compute, as well as the private VPC resources that you can create. So this is the basic underlying architecture of hybrid that we are trying to build. This is another way of looking at how we are deploying the application. But the interesting thing about this is, as I said, at the beginning, we just have two zones, but this can be extended to many zones. For example, if you're using FEPC, this available zone can be extended to multiple zones. So that if our application engineers are building a very, very high reliable applications, then probably this is one way of making it happen. So this is just a typical two-tier application and the DB model. But this can be interestingly expanded to a very interesting architecture model. Hybrid controller. There are many different way of looking at it, but obviously it's good for the deployment and monitoring. And then the auto scaling and cloud busting. This is something that we can talk about it probably tomorrow at the rice scale session 3040. So I don't want to get into the details on this. So after all this, what do we learned? Last two years, we definitely learned a lot. But I just want to point out a couple of things that we learned. One is for hybrid. Is it not something that we can build ourselves and then deploy it reliably? So having a good tools is very important. And without tools, it's very difficult to manage inconsistent APIs. So we are using a rice scale to deploy and operate the hybrid cloud. The second one is something that we've been doing the last couple years. Obviously OpenStack is a very highly flexible and configurable, especially early days. And as you know, Diablo also did not have enough features, but also a lot of arrow. So that we didn't have a lack of a capacity planning or performance tuning and the network design guide. But this is just a few things that we learned over the years. But one thing that we really had a difficulty is longer cycle to upgrade. In fact, it's very difficult to upgrade from the Diablo to access to the foursome. Because there is no good way of just upgrading it. So we really re-architect and rebuilding the components every time that we upgrade to the new major cycles. So that's what we learned. Obviously we can share more, but these are the things that we learned so far. And hopefully it helps to understand and what we can offer to you guys today. Any questions? Actually those are confidential information that I don't like to. It's thousands. This is more for the just a non-OpenStack. Let me put it that way. This particular architecture. In this particular case we only looked at the I repeat the question for the gentleman. Actually you can stand up over there and then you can repeat yourself. But let me repeat for him. The hybrid that we are considering is both sides was OpenStack based. And so was no. It was one side. Private side was OpenStack. The other one was not. But we are looking at the considering another public cloud company who can do this but we haven't done it yet. Well because number one was the low cost and the flexibility. Oh repeat the question. Why do we choose OpenStack even though we had so many problems? And I think I answered that earlier that the even the time in two years ago there was so many solutions out there. CloudStack was one of them. And VMware which was a very expensive which could not be part of our budget. So we decided to take it at risk. So I'm glad we did and that's what we are at today. Yes unfortunately I cannot because the today I have been told that just to talk about the infrastructure not application. There was an instruction that I've given by my legal team. We have all that information but unfortunately I cannot share the information today. Right I have to respect the because I just want to make sure that everybody understands SDS is building infrastructure not the applications. Yes absolutely. Repeat the question he said. Are we planning to operate to Grizzly or force to Havana? The answer is yes. But right now we have some customization code so we have to take a bold move in the future that we're going to take a trunk based on the Grizzly or Havana so that the will be in line with OpenStack community. Absolutely. However there are certain things I can share certain things I cannot based on the for example OpenStack can share with you any way I can. However applications and related to the customer requirements I cannot. Yes the question was back in two years ago what was it why we decided to choose over choose OpenStack over CloudStack. At the time the main reason was the scalability. We thought that the CloudStack scalability is going to be limited so that was the main reason why we decided to go with OpenStack at the time. But given the situation today I think that need to be looked at it again. Yes. Appreciate it. Thank you. Yes. Okay that's the that question is not that easy to repeat. Let me go back to that drawing. Here. How do we choose this a low balancer? This one. Would you repeat the question one more time? Okay. I don't want to get into the details of how we did it with application side but for the generic purpose like this that I can talk about it. Without revealing the actual application detail our general tendency is to move keep normal workload in the private cloud and move the excess workload in the public cloud. So as a result you know when the normal workload mySQL masters which is critical for right operations stays in the private cloud or excess load you know when it scales out in the public cloud still the rights will come to the private cloud and we'll do the right operations but all the read operations will happen out of the public cloud that way we can shed the load out of that. That's the rationale behind it. Okay. Sentil you want to stay? Yes we do encounter the problem if you if you move away from say open stack if you use any other public cloud right yes there is an image incompatibility so that's where the he mentioned the cloud management tools is very important where our applications our deployment plan is agnostic of that image right and you know we can deploy across various clouds and so that application runs smoothly. Yeah so I'm with right skill I'm giving a presentation and exactly that tomorrow if you're more if you're interested in further details of that when exactly your question how that works. Okay one more actually answer to that is the we're not allowed to talk about mobile today unfortunately sorry hopefully that answer most of questions and thank you for coming by and enjoy the lunch.