 Welcome everybody for the second talk on the evaluating OpenStack session. So we have a trio of people from Ericsson who will talk about evaluating OpenStack yourself versus waiting for the help from the foundation or from the third parties to do it. So you will evaluate it exactly on the features and technology which you wanted, not what somebody else does for you. Thanks a lot. Welcome everyone. Welcome to the last session of the first day at OpenStack Summit. We are here to talk about various cloud options and some quick steps to evaluate those options for enterprises which are ready to implement their cloud strategy into action. Let me start with introduction of the team here. We are from Ericsson, cloud solutions team, and would like to introduce the speakers here, myself Nikethu Parekh, I'm a cloud solution architect. With me I have Sudeep Bhattra and Rani Haddad. We are all part of the same cloud solution team at Ericsson. And in today's topic, the things we will be discussing are primarily looking at the situation that every single enterprise is going to face. Either they have already addressed this situation or they are ready to look into the next logical step of evaluating the cloud options. Then we look at various approaches. And as part of the approach, we will touch upon step-by-step process of evaluating various options. We have tried to broadly capture them as three different phases. First one is to know the options available. Second one is to talk about the evaluation framework itself. And then last step is basically decision-making and planning exercise. And we'll conclude with the summary. So with that, I would like to hand over to Rani to kick off the discussion. Rani? Okay. Thank you, Nikethu. So as Nikethu just mentioned, this is today's problem for large enterprises. So the enterprise is realizing that we're trying to make the shift, the digital transformation or the cloud transformation, and adopt some kind of cloud strategy. So we're starting with this funny Dilbert cartoon. Employees got the directive that they need to do something. They need to fix the large enterprise problem and adopt cloud somehow. And they're just discussing cloud computing. How to adopt it? How do we go about it? And they really have no idea what to do. In fact, I mean, today I was actually surprised, pleasantly surprised. There's a lot of first timers here at the summit. And this indicates that the adoption is still ongoing. So we have a lot of enterprises that are still trying to make the move to cloud. So how do we go about this? Or what is the current problem? So a given enterprise has several departments. And all these departments have different business drivers and different goals. Like a finance department or a marketing department, IT operations, different businesses, R&D, security, etc. Everyone wants to achieve some sort of agility, some sort of quick time to market. Proximity towards end users, faster, quicker services, quicker delivery, flexibility, faster deployment of production or lab test environments, etc. Adopting or conforming to regulatory requirements. So how do they go about this in which cloud to adopt? That's the big question. So what we've done is we've come up with an approach to try to do that as an exercise within the enterprise. So we have a five-step approach. The first step or the first two steps are really to know your options. So what are the options out there? What is the deployment model? We'll talk more about the deployment model in a little bit. What is the service model? Do we want to adopt for a deployment model? We want to adopt a private, public cloud, hybrid, community. Today we even heard about another one, private cloud as a service. So what are the options out there? We'll know some details about all these options and the different components. So even if you adopt a specific service model, then what components do you need to worry about? Then after we look at all the options available, we try to come up with an evaluation framework. So we look at the different apps, different businesses, their requirements from several dimensions, technical, architectural, business requirement, etc. Then once we look at these requirements, then we look at the cost. We have a cost analysis that needs to happen. And once we narrow down the options based on these requirements, as well as some sort of financial analysis, we try to make some decisions and come up with a migration strategy in order to make that move to the cloud. So we talked about knowing your options. What are the different options? What are the different cloud deployment models? Something most of you know, we have public clouds. In fact, we heard today there's over 50 public clouds running on OpenStack around the world. And you can go to the OpenStack marketplace and look at these. And there's obviously AWS, there's Google Cloud, Brackspace, other public clouds that we all know about. And on the other hand, there's the private clouds. And enterprises are trying to deploy their private clouds. Some of them are struggling. And we've heard some of them are starting with private clouds, running it for several years, then switching. And we've heard also the other case where people have gone to the public cloud and then decided, okay, well, I've got so many problems doing this. And let me switch to try to do this with a different model, either hosted, managed service, on premise, et cetera. And then there's obviously the hybrid cloud case where we want to start with public or private. And let's say we start with a private cloud and we want to be able to be a little bit more flexible and extend to private cloud. And we connect to one or more public clouds from our private clouds. So these are our cloud deployment models. Then the service models are also something you guys, maybe most of you are familiar with. But let's refresh your memory a little bit here. So we have infrastructure as a service, platform as a service, and software as a service. So infrastructure as a service obviously provides infrastructure as a service to the users. Platform as a service where I guess the users have to worry less about one part of the stack. And so we can provide the underlying OS in middleware and runtime and then have the users only worry about their applications and data. So deploying their applications and worrying about their data. And lastly, your software as a service where the whole stack is provided to the users and the users have to basically use their applications. So we talked about the deployment models, the different service models, and whichever one you adopt. There's a set of components that you kind of need to consider when you're trying to make the move to the cloud. So what are these essential components? It's a big dinosaur obviously. And the different parts of it are the infrastructure we just talked about. So IAS where you have your compute storage and networking. And then the next level, which is platform as a service, PAS, where we provide the platform for the developers to deploy their applications. And one thing we all need to do is option management, right? One way or the other, we have to manage either the infrastructure or the platform or sometimes the applications running around it. And of course the layer that sometimes we ignore but we cannot, which is security. So security is an important part of this where we have to consider security at all levels, whether it's physical, network, infrastructure, etc. So I'm going to hand over to my colleague, Sudip here, who's going to go in a little bit more detail about the different options when it comes to infrastructure and PAS and tools for option management. So I'll throw more light on the infrastructure components that are involved that we need to decide upon. So the first criteria, of course, is to decide the Linux distribution and the three major Linux distribution that we have is the Ubuntu, OpenSUSE and CentOS. And then there are various vendors who are providing this OpenStack distributions. So that also needs to be decided. Now, when we look at this infrastructure component from the IAS, we have like three broad categories which we know, network, compute and storage. So we need to decide on those factors. So when we look at network, then there is an aspect of network segmentation which is like deciding what type of network like private network or the tenant network, the provider network or the storage network. So those aspects need to be decided. And then is, of course, the SDN software defined networking, which needs to be decided depending on your workload, characteristics, service chaining requirement or SRIOV requirement for your workloads. So that needs to be decided. And then the underlay, which is really the switching fabric, the leaf spine architecture, as well as the connectivity to the gateway router. So those aspects need to be planned out. And then we have to look at the compute aspects like selection of the hypervisor. If there is already a hypervisor being used in the organization like VMware, maybe you would need to select that. Otherwise KVM is the default choice that mostly it has been used now. The next aspect in the compute is the selection of the hardware. And for the selection of the hardware, you have to really look at the various aspect of over commit ratio or the instant size for the hypervisor. And then the workload requirements are really depending on your application requirement. If there is specific application requirement, that needs to be taken care of. So that also needs to be considered. And then we look at the storage, planning out for the FMRL storage, which is for the VM onboarding. The VM needs to be done. So that needs to be planned out and the block storage and the object storage for the files and stores. Okay. So this is, again, in case the decision is toward the public cloud, then also you have to select on the various components on the network compute storage. And again, there are various factors that need to be considered. Now, the other big area is really the operations and management components. And here again, the two broad categories, the deployment, orchestration, configuration, management, this aspect, and the logging, monitoring, and alerting. So deployment is the selection of the tool. And we have various tools like fuel, triple O, which will help in doing the production deployment. Of course, for the learning, we had been using back stack or desk stack deployment tools. But that selection needs to be considered when the deployment for production workload has to be planned out, production open stack deployment. And then there is a selection of the orchestration platform. And there are various orchestration platform. Ericsson has an orchestration platform like Ericsson Cloud Manager, which can be used for deploying the various virtual applications. With respect to whichever underlying open stack platform you have, it can be used to deploy your virtual applications. And also there is another own app that is open network automation platform based on OpenEcom, which can be used and it's really to address the telecom network orchestration. And the underlying, these tools will of course talk to the HEAT API to be able to orchestrate the VM onboardings. And we have the configuration management for our platform, which can be done using various tools like puppet, foreman, or also other tools like Ansible or Chef can be used for doing that. Then the important aspect is the logging, monitoring. Monitoring, we are considering operational monitoring, but there is also tenant monitoring, which needs to be planned out. And then for this, the initial step will be to identify the metrics that you want to monitor for your environment. And the services, the open stack services or the underlying operating system services that you want to monitor. So those aspects need to be decided. And thereafter, there is a need to plan out the various tools like logging, monitoring, alerting. Typically there's a tool like StackLite by Mirantis, which can be planned out. And if you already have an existing tool like Nagios, then there is a need to decide on the integration between that Nagios tool. And of course we have the open stack telemetry, which can be used for doing. The next big aspect is the security. Now security is really a very big factor and it really needs to have a consulting to decide on how we can do security for the entire organization and apply to the open stack distribution. Now here what we are looking at is really what are the security concerns that is there for an organization. So broadly there are six categories, cloud infrastructure, cloud security controls, multi-tenancy, cloud management, hypervisor and data protection. So the security concerns can come from the various areas. And in order to ensure that all these security concerns are addressed, we have to really apply a proper mechanism. So here we are presenting like a six-stage mechanism. So each of these needs to be applied and there are various aspects like when you talk about compliance and gap assessment. So there is a need to apply some security standards, certification. And then when it's the risk assessment, you have to really look at the multi-tenance, those aspects. And security assessment and auditing for the hypervisor and applying various security mechanisms like, you know, SELinux or we are more those kind of security aspects. So each of these need to be looked at in detail when planning out the security. When we come to pass, really these are the driving factors and the deciding factors which lead to the selection of a pass. And the components are these are the components which really need to be looked at when deciding the pass components. So with that I will hand over to my colleague Nikithu to talk about the next stage of evaluation framework. We have looked at all the options available for evaluation purpose. Next logical step is basically to look into the evaluation framework. And looking at the evaluation framework that we can see in the slide, the approach that we have adopted is basically to come up with a very simple framework that is modular enough that it can be easily applied to any situation. And along with that it needs to be generic enough so that it can be applied to any kind of deployment model whether it is public versus private cloud or a hybrid cloud option being evaluated as well as any type of service model or consumption model. We wanted to make sure that the framework remains consistent across all the applicable scenarios. So along with that in terms of applicability and overall framework components what we have is basically starting with the step by step process and the first step is basically looking at the application requirement analysis where major input is based on various applications requirements. So as an output of that first step is basically looking at various feasibility options meaning that when you perform the requirement analysis the outcome of that analysis is that you have shortlisted options in terms of what cloud options need to be further evaluated down the road. And along with that you come up with a list of features which are mandatory in terms of fulfilling your cloud strategy. And the next logical step is basically to dimension the whole cloud solution that includes infrastructure dimensioning as well as various features which requires a specific dimensioning based on the situation. So as output of the cloud dimensioning is basically your overall cloud size and I guess everybody will be familiar with what the cloud size is. If you refer to the latest OpenStack Survey report you can see that there is a whole dedicated section about the cloud size which consists of various line items that need to be evaluated individually. So we'll look into that later on when we discuss the framework. And then once we have the cloud size identified the next step is basically to look into the total cost of ownership or return of investment analysis. So there are two different inputs. One of them is the cloud size and the second input to this particular step is all the cost factors. So as you can imagine for any kind of cost analysis there are various different aspects that influence the overall cost analysis. So we'll look into that further down the road. So this is basically the overall structure of the framework. Now let's look at individual components. So let's start with the requirements analysis phase. And the requirement analysis phase is basically a multi-dimensional analysis. And the typical structure you can see here is that for any given enterprise environment they must be following some kind of requirement analysis process or a model. And if we have to basically categorize various requirements independent of what application it is or what organization it belongs to you can categorize those requirements into these six broad categories. Functional, non-functional, architectural, O&M-related requirements, security-related requirements, and performance and workload-profiled requirements. And when we are doing the analysis we are not talking about reinventing the wheel here. We are trying to follow the same methodologies that are being followed for requirement analysis phase at enterprises. But what we are looking at is various business drivers. So the requirements are being evaluated against various business drivers. Some requirements may be positively or negatively impacting one business driver whereas it is completely independent or not applicable for other business drivers. So the heat map that we have shown here represents the same thing. In reality the framework itself has a positive or negative or not applicable as a scoring mechanism against these requirements that can help evaluate the requirements against business drivers for adopting the cloud strategy. And again, another dimension to that we can apply this. We can evaluate those requirements against various deployment models as well as various service models. So let's look at an example. Here we are looking at a few sample examples that enterprise has readily available meaning that these applications are cloud ready. Means architecture wise in all aspects, they are completely suitable for migration to cloud. So then when we do the requirement analysis of these applications, cloud ready applications, we can come up with a consolidated super set of requirements that basically needs to be fulfilled in order to migrate those applications successfully to the cloud. So when we have this super set readily available, what we can look at is which application requirements are not being fulfilled by a specific cloud option. And that helps us to apply the process of elimination and reduce our options which needs further evaluation. So looking at the second phase of the framework, which is cloud dimensioning. And here as I mentioned earlier, the main categories of the cloud dimensioning that we are considering here are looking at what is the size of your cloud in terms of number of computes. You need to know that primarily it's going to be a homogeneous infrastructure that you are going to deploy, you need to know the processors and number of course, et cetera, needed for the compute nodes. You need to know the infrastructure needs for the whole networking aspect. And you also need to know what type of instances that you are going to need as well as how many of those instances. You need to know the whole size of the network that needs to be deployed as underlay as well as overlay to handle the application related networking needs. And along with that, the storage aspect also needs a more detailed evaluation from dimensioning perspective. So what we have done here in this particular case, we are just trying to demonstrate that out of all these different items that are applicable for cloud dimensioning, some of them apply to public cloud and some of them apply to private cloud. So we need to very clearly identify which of this dimensioning aspect is applicable for what deployment model. Moving on to the next, as an example, what we have tried to demonstrate here is that out of those requirement analysis phase where we looked at the whole bunch of requirements, specifically talking about the performance characteristics of individual application. That application performance characteristics are primarily related to either the capacity needs of the application or performance-specific needs of that application. And on top of that, there could be virtualization-related requirements that needs to be appropriately analyzed and applied to the cloud dimensioning model. And again here, the model that we are looking at is kind of generic enough so that it can be applied to every single application that is being evaluated and dimensioned for cloud migration. And the resource requirement summarization tool that we are looking at is basically trying to summarize the overall requirement of all the applications which are ready for being migrated over to cloud. And at the end, what you have is basically a bill of material that consists of what type of hosts are needed, how many of them are needed, what kind of flavors we need, how many of those flavors are needed, what storage requirements are, as well as networking requirements, et cetera. Moving on to the next phase, which is primarily the cost of ownership and return on investment analysis. Again, as mentioned earlier, there are many different aspects and factors that influence the cost of ownership. We have given a sample of those factors, such as hardware infrastructure. Primarily that applies only to the private cloud deployment scenario because when it comes to public cloud, you are not deploying any cloud on your own. You have everything readily available from any public cloud service provider. In terms of software licensing as well, more than likely it is applicable for the private cloud deployment unless there is a specific scenario where the application virtual machines also need to carry along the license over to the public cloud deployment. Along with that, other considerations are LCM and operations aspects, both from the infrastructure perspective as well as for applications perspective that needs proper cost analysis. And one big factor is the data center cost. And here we are talking about every single data center that basically is part of the cloud strategy and applications are being migrated over to various data centers and costs such as renting the data center premise as well as all the operational aspects of powering it and HVAC and many other aspects. So again, the whole data center cost aspect is applicable only for the private cloud scenario whereas for public, we don't need to worry about that. And another big piece is the pay-per-use case where in the case of private cloud deployment, it is primarily not applicable. Whereas in case of public cloud, the whole fundamental pricing of a public cloud is based on a pay-per-use model which means that has very heavy influence on your overall cost analysis for your assessment. And last but not least, it's a training and competence building which is applicable for both public and private cloud. So let's take a quick look at how we are trying to address the total cost of ownership and return investment analysis. So here what we have shown here in this graph is basically we have picked only the material cost of the virtual machines in case of public cloud or the equivalent of number of computes that we need to deploy to match the same amount of virtualized resource requirements. So what you can see here is that we are looking at a specific configuration set of the virtualized resource requirement which is basically total 160 virtual machines on different public cloud options and then comparing the same towards private cloud where we are looking at how many number of servers are needed to provide the same number of virtual machines. So based on this specific line item as one of the factors of overall cost analysis what we have tried to show in this graph is that the cost of ownership basically between private cloud which is the blue line versus all the other public cloud options. And as you apply other cost factors into the equation you will see that the graph or the difference between the private cloud and public cloud changes. So that's the whole total cost of ownership analysis that the tool is able to accommodate. Moving forward beyond the framework then once we have the outcome of the evaluation framework which could be one or maybe maximum of two cloud options we need to go through the rest of the process of the planning various activities beyond selection. So beyond selection what we are looking at is we need to make sure that we are going through the whole formal proof of concept activity so that the team who are actually going to work on the deployment or cloud adoption they are well familiar with the cloud architecture and the cloud solution being adopted. Along with that another critical planning activity is to carry out the whole performance testing activity and last but not least is basically establishing overall cloud adoption timeline. So let's look at the proof of concept. So the main purpose we need to conduct the proof of concept is to help understand the architecture of the cloud solution being adopted and understand the nitty-gritty details of how pricing is going to work if it's a private cloud or if it's a public cloud or various other considerations. Also along with architecture, operational aspects and hands-on experience is vital for team to build the competence needed as well as feasibility of various automation aspects. So these are very typical items that we carry out during the proof of concept activity so that we are kind of taking the first necessary step to come up with high-level design for the solution and also identify various deployment tools that we are going to need as well as some high-level deployment guideline that can help us with more robust solution for deployment. So that was about the proof of concept. Let's look at performance characteristics. Again, performance characteristics testing is vital and crucial. It's not an optional activity because of the fact that performance of application is basically going to dictate whether your cloud strategy will be successful or not because we have witnessed so many cases where the deployment was successful but it was not able to fulfill the performance needs of various applications. So then it's a complete different exercise of tuning your application performances and whole nine yards related to that aspect. So before we take the final step of migrating applications, performance testing is a must step. Moving on to the next last item in this section which is about the cloud adoption timeline. And here, again, various factors influence the timeline. Just like we saw previously, the cost analysis also had various factors that can positively or negatively influence the total cost of ownership. Some of those factors also influence the overall timeline of your project timeline of your cloud adoption strategy. I won't go through the whole list here, but one important factor that is mentioned here is about the migration. And Edison has a tool that helps plan out the entire migration and I'd like to invite Ronnie to talk about the migration tool. We're running almost out of time here. So we'll go just real quickly through this. Basically, we've gone over the options and we presented the framework in order to evaluate which options to go with. And essentially, once you figure that out, you narrow it down one or two options, you need to kind of walk the walk. And there are several tools to do that. So one of them is this Ericsson Transmigration Engine, which is a tool that would help you collect all of your enterprise applications and put together a schedule and a timeline in order to basically walk the walk, like we said. And this is just various screenshots from the tool where you list your apps, list different characteristics of each app and kind of put together a timeline in order to execute this migration to your favorite cloud option. So really, in summary here, what we need to know is we look at the business requirement first and it's needed to make the shift to the cloud. So we got to know our options, evaluate our options, look at our TCO, and at the end we need to do some sort of proof of concept and benchmarking and then basically do the migration, go through the migration process. So thank you very much and we'll take any questions.