 Let's get started. Good evening, everyone. I'm Vaidyanath. So we are going to present DevTest Ultimate OpenStack use case. So I'm Vaidyanath, so I'm working with Infosys. And we are missing Himanshu, my friend. Probably he couldn't make it today. And this is Samet. Samet, would you like to introduce yourself? Hi. Hi, this is Samet Mishra. I'm from Juniper Networks, Cloud Solutions Platform Group. Today we'll start up with the agenda. So we'll begin with the introduction. Then we'll talk about what are the challenges that we face in traditional DevTest enterprise environment. Then we'll go to see how OpenStack-based DevTest Cloud will migrate from traditional enterprise DevTest environment to OpenStack-based DevTest Cloud. Then we'll look into the cloud automation part. And we'll cover the operational flows, system support. And we'll also go over a case study, traditional versus DevTest Cloud. And then we'll summarize the closing points. Historically, DevTest environment is maintained and built at project level. So it's highly underfunded, under-resourced, and underutilized for a significant point in time. In enterprise, large number of test cases and scripts are executed for validating and verifying for business requirements, whether the product quality is ascertained based on that. Now, in traditional infrastructure, when we have a demand cycle, which is very late in the release, that time to accommodate any new resource planning is very difficult. So businesses today expect DevTest to be IT infrastructure to be agile. And when we say it's agile, we want resources to be always available on demand. So that we enable the developers and the testers to be able to develop and test based on the requirements. Time to market is key to the success of any product. And to achieve that, we'll leverage OpenStick-Best DevTest Cloud to be the successful solution in the future. Now let's look into what are the challenges that we have in traditional DevTest environments. Suppose, consider a use case where you have provisioned for 550 BMS, it will be sufficient for one release. Now in between, you decide that you need to scale up to 100. And that time, you need to provision it again. Now, it's not that simple. In traditional DevTest environment, you need to follow a process. The process is you have to first allocate budget. Then after the budget is approved, then you have to go and procure the hardware. The hardware comes, it gets stacked up. Then you have to deploy, configure. And after deploying and configuring, then you need to go and do certain configuration specific to your project. Then it gets ready. In the whole cycle, it can take weeks. And the product gets delayed. And whatever the objective that you have, you can't meet it. So the hardware is the limitation here. The hardware is limited and it's shared across the teams. Now then you need to do time sharing to achieve it. So that's the problem that we all face. The capital expenditure is always high. You cannot have all the hardware you need. And the expenditure is too high. So now even if you have the hardware, the operational cost is also very high. You need to manage, you need to have a different team to manage the operations of all this DevTest environment. You can have multiple setups, multiple Dev setups. And parallely, but you cannot leverage everything at once because there is no standard procedures and to bring up the setups. So that is one of the things that will be solved in the DevTest cloud. Again, as we know that the demand cycle is variable. Like it can be a spiky demand that comes up for resources that cannot be handled in the traditional DevTest setup. So now let's see how can we transform our traditional setup to open-seq-based DevTest clouds environment. Now you can see all the local infrastructure that you have that can be leveraged into this. Just pull out all this servers, network, networking components, and storage into under a single roof. Say you create an Austin data center and put everything under one roof. Now also you can put in licensed virtualized softwares like VMware and other softwares. Let it be there. All the resources put in under one roof. Then using open-stack orchestration, you can have a resource and planning projection layer. This resource and projection layer is used by the administrator to get a view of how many resources are available and how to plan for if it is required for any scaling or scale out that is done through the resource and projection layer. There's another layer of supply and automation layer. This is pretty critical for the success of this setup. This is the cloud automation layer where we talk about orchestration using open-stack and DevOps and automation tools to configure and provision all the setups. The delivery and service layers is the output that we get. It's kind of a pass layer where all the latest and greatest of all the builds is available. Now when we think from the user's perspective, a user will be a developer or a tester. So when a developer or a tester joins a team, they onboard the developer or a tester, then an account is created. Once an account is created, based on the manager's approval, they get a quota. So now they have a quota, they also have an account. They don't need to go through all the procedures to get the approvals and the resources. Just one click and they get it. So pretty instantly, they can satisfy the requirements and they can proceed. So this enables the developers and tester to continue and complete their tasks. Ready? Want to come down? Thank you. So we are considering two different scenarios here. One is basically bringing up the cloud from the scratch, which we are not covering in this presentation. The second thing is we already have existing customers who are using traditional or enterprise softwares. We are concentrating on those customers who are trying to migrate their existing infrastructure to a cloud environment. So OpenStack plays a key role in migrating their existing setup, so it cannot happen overnight. So customers are not willing to give up their existing environment that easily. So they have to go through a process. So the process here is DevTest. So first, make the customer believe that, yes, it is possible to migrate their existing setup from enterprise to a cloud environment with OpenStack by providing enough data to them. The second part is seamless migration. So seamless migration in the sense, so you already have an existing infrastructure. There are many tools which I would like to quote Apterra in this. Apterra have come up with their own plug-in called GUTS, which allows you to migrate your existing VMs from an enterprise, either from VMware or from Hyper-V to your OpenStack cloud. That's a very good tool. So coming back to the presentation here, right? So cloud automation. So on the left side, we are seeing the enterprise setup where we have the infrastructure, hypervisor, integration framework, and the applications which are developed on top of it. So integration framework is being provided by the hypervisor layer itself, either it could be a vCenter server or vCloud director or any management software. So on the other hand, we are looking at OpenStack, where the cloud orchestration, which is highlighted here, plays a very key role in migrating, I would say, rather it will mask all the infrastructure layered management from the end user. So all that he would require is a setup. Say, for example, a director comes to me and then says, we are forming a new team. We need so-and-so configurations of VMs, and this is the tenant you have to create. So it's very easy for me to pull out the template out of OpenStack and then just create those VMs for them. But in the enterprise, on the other hand, in the enterprise setup, if I want to bring in a new team, I'll have to consider placing the hardware requests, getting them into the lab, stacking and racking. It takes a whole set of process. On the other hand, there are different things which makes easy for on a cloud environment. One is infrastructure orchestration, the second part is DevOps or automation, configuration management, and the service platform. So the service platform is picking up in the industry. So either a pass or a database as a service. So you have a built-in solution for you, just clicks away. So moving to the operational flow. So we have considered an enterprise customer who is willing to move from. So all the components which we have mentioned here sort of enterprise could be puppet or chef, in this case. So once the source code is, the source code management has been pushed into Jenkins. Jenkins takes a build, push it into TIFFE, and from TIFFE, it gets into the server. The infrastructure provisioning gets done, and the VMs gets provisioned. So all these things happen. So the one thing which we need to look at here is the monitoring tools. So we are not keeping the monitoring tools within the ecosystem. So the complete cloud ecosystem is separate, and we are keeping the monitoring tools as separate because we would like. So it cannot be a failure prone in case the whole cloud goes down. So the same workflow explained in a much depth. So the first part here comes into build. So where we check in the code, a developer or a test engineer checks in his code to the source code. It could be a GitHub or any other source code management tool. It gets into the triggers of build through Jenkins. And the third part is, if the build is failed, then it needs to get back to the cycle. It should be an auto-requerable process, and there should not be any intervene in between. So once the code is accepted, say it's passed the build, moves on to the next stage where the deployment happens. The deployment happens through the configuration management, either through Puppet or Chef or even Ansible. So the components which we have mentioned here are just for reference. It could be anything. It can be configurable, basically. And the deployment process starts. The deployment could be either on a DevTest environment or it could be staging or it could be on a production environment. So the process should be seamless. So I use the same pipeline. Just the configuration for DevTest environment should be separate. The configuration for a staging environment should be separate, and the production should be separate. Have a different pipeline. That's it. The process remains the same. And testing. So once the deployment is completed, how would I ensure that my setup is proper, my configuration is fine? So there are two levels of testing. One is testing the setup itself by ensuring all the services are up and running. The second part is having our application deployed. So that could be either through if I'm using a web application, I would do it through a Selenium or any other web application automation tool. Trigger those tests, confirm that everything is passed. So if it is not, it will fail there. Come back to the starting phase. System support. So this is the monitoring part which I was talking about. So we use Nagios, SIEM, and it's not. So Nagios for our data analysis and SIEM for the event management and it's not for network-related tracings. So the complete application or system or network can be monitored through different tools and can be logged and can be traced. So the complete event management has been, so the complete ecosystem is out of our cloud environment. So if you see this previous slide here, the monitoring tool is kept separate and all the other components are integrated together. So this gives us an opportunity if, in case if the complete cloud goes down or the integration goes down, my notification is still intact. So coming back to the case study. So the case study for an enterprise setup would be like this. So you have a service request created for a procurement. It goes through all the approvals. Then a new team gets formed. So in case if I want a new box there, all these processes has to go through and it takes quite some time to get it up. So considering the DevTest environment with OpenStack, it's pretty easy because we are orchestrating everything at the layer till the user integration. So all that we give to the user is just a web UI where you can just go ahead and click select few options and then provision is a VM. So on the closing thoughts, I'd like to submit. So what we achieve at the end is what we started. We want greater time, less time to market as possible for a product to be successful. And if you enable the developers and the testers to complete their task and effectively manage their tests and development cycle, then there won't be any delivery delays to do any resource crunch. So time to market is what you achieve. Then the whole lifecycle of getting an approval and other statutory approvals and getting the procurement and everything takes time. And that itself is taken away through by enabling the user itself to request for the through templates based mechanism request for whatever resources it needs. Just that in future, if needs they need more, they can just increase the quota based on a simple approval of a manager. Now we have observed that as the hardware resources in any traditional DevTest setup increases, it's very difficult to manage the passwords and username. So what normally we do is we put a simple username and password across all the infrastructures. And it starts creeping across projects. And it becomes like a uniform password, universal password, like say welcome one or EMB 1 MPLS. It's like as a common password across all. So that itself is a security violation that we ourselves do and we don't realize it's a grave problem because we have sensitive data in all those servers. And all this will be overcome as user has his own account and authorization is there. We can authorize using LDAP or Keystone, whichever mechanism is suitable. So this is the security level increases and without any hindrance to the user. Now as you would have faced problems in convincing your management that you need more resources, that's because it's difficult to make them understand that you really need a resource because they don't have the ability to view those utilization of resources. Now through monitoring, one can easily analyze the utilization of the resource. And administrators also can take a decision on scaling in and scaling out based on that. So I don't think there won't be any problem in future convincing higher management about utilization of resources. If it is utilized, it's there in the report. So with all these benefits, I think it's high time that all the traditional DevTest setup should migrate to any DevTest cloud setup. And we prefer OpenStack should be the base of it. Thank you. Any questions? Thank you.