 Is your mic on? Now we can get started. It's been a long two weeks for Rick and I. We went from Orlando to here in our two week stretch, one week in Orlando and then here. And so we've been, I think we're kind of exhausted. So hopefully we can have a little fun today. We're slightly happy at this point. Yeah. So I'm Cameron Cedar. We're both systems engineers. And I've been with SUSE for 10 years. And I've been with SUSE for about six and a half. Coming up on seven actually. I'm actually surprised by the numbers that are in the room because of the name on the session. Does anybody know what Jankings is? OK, that's good. I'm glad you don't. Yeah, we know that there's no G in there. Yeah, thanks. Just for your pure amusement. We found this picture the other day on the internet. And there's so much awesome rocked up into one picture. We had to share it. That's right. That is OpenStack, a Rambo cat with a laser gun riding a unicorn, a fire breathing unicorn in front of a rainbow. Did I miss anything? With red eyes. No, I think that's the Rambo, like the headband. Tied back. Oh, yeah, that would be cool. Or if you had a katana or something like that. I'm not sure what about this little cat that's going down here, too. If you Google unicorns and cats and rainbows, you get some really interesting pictures. Anyways, we had fun last night. Can you tell them we've been slap happy? Let's move on. So we're going to talk about development and operations. Just a little overview on that. And then the SUSE approach, really the SUSE story around DevOps. And then a lot of the tools that are involved with that. And the architecture, the setup of the architecture, what the workflow is, and how we can help if you want to have this kind of environment here that we're going to show you today. So there's a split today between developers and IT operations. And who has this in their organization today? Oh, come on, don't be shy. And you might not have the split. Maybe you're going to this DevOps approach and you're here today to look at more tools that you might possibly want to use. And if that is the case, that's great, because we'll show you those. But most people have this kind of thing. And usually there's through that fight. You've got the developers that want the latest and greatest bright shiny object. Let's roll everything. Continuous integration is straight from source. And just throw it into production. And I want to use the latest Ruby stack and the latest whatever. And then you have the operations guy that say, please, for the love of God, it's working. Don't touch it. Just leave it alone. And so it's right. You've got to balance those. I want stability. And so this is kind of where it comes from. Development was coded. And they were set aside in this group in the back room. They just had the lights off. And they were just, if you don't know, doing Doritos. And the ops guys were in control of the apps, the OS, the hardware, and the stack that runs the code. And the operation's just waiting for that next release cycle. Waiting for those developers to kick that out. The new approach is basically stressing the collaboration between and communication between IT operations and your developers. Making sure that you guys can work together, integrate together, and have a very successful solution. The guy in the front row just started laughing when he saw that. Apparently he's met some software developers before. And IT guys. Exactly. So the DevOps way, we're having this marriage between the development and the operations. And three tiers, Q and A, development, and the IT operations. And then the center of those three tiers is now the DevOps. Some of the problem statements that we have or come across today in our travels. Battery is critically low. Is that not even plugged in under this table? Cause it's on the little, okay. Is the switch on? All right. That actually happened to Sage Will, the guy that wrote stuff. I was in his presentation yesterday and his screen just went black all of a sudden cause he'd forgotten to plug it in. That's just fabulous. So some of the problem statements, when we come to software packaging and image creation, customized scripts for configuring services via config file templates is difficult to manage. When consolidated to a single RPM, changes to a service require an RPM rebuild. You ever come across that? All the time. Yeah. Standards are not always followed with no enforcement controls for them. Yeah, let me come across that all the time. Kernel dependent components are impacted with every single upgrade. Typical deployments of apps or middleware components are complex. You ever had that problem? Complex middleware applications. Kind of hard to deploy. Take a little while sometimes. So when it comes to, okay, some more problem statements here. Patching and upgrades, imaging. Difficulties decoupling middleware and application upgrades from OS related upgrades. That's pretty common. Especially when you have a middleware application that may be Java based, decoupling that can be very difficult. And then when you update the JVM, there's about a thousand dependencies to get updated to. Yeah, even compiling Tomcat can be kind of a nightmare. Building new images for new OS versions is usually approached by building and rebuilding from scratch. This typically requires project initiation and implementation every time with significant overhead costs. So yeah, it's absolutely time consuming, takes up your resources. So a DevOps environment, you really want to be able to reduce that. You don't wanna save time there. The SUSE approach. So this is really exciting because I really like the way that SUSE does it. And it really comes back to our development model and how we've evolved over time. So our approach for the creation of our Linux distribution. We create the software to quickly adapt to the business needs of the industry, industry changes, whether it be hardware, whether it be software that we were working with, with ISVs. We're founded on the approach of development. And we want high quality engineering. That's really where the SUSE's roots came from. And this is going back 23 plus years now. And that's really kind of the key differentiator that SUSE is in the marketplace today. We were engineered off of this continuous delivery model to meet those demands. In fact, SUSE, a long time ago, stood for, and it still does, software, and I'm going to butcher this because I'm not a German. But it stands for Software and Systems Development. Software und System ent Weglung. I think that's how you pronounce it. But that's really what we stand for as a company, Systems Development Company. It's a very engineering oriented process. And if you've ever met some of our engineers at SUSECon or even at the conference here, we have a lot of them here today. We are very much a development focused engineering organization. So some of our design principles, our approach has been around some of the standards and tools that we use. We believe in open source. We believe in open development. We contribute to communities, lots of communities. OpenStack is not the only one. And we believe in open APIs. It gives our customers choice. It gives them flexibility in the organizations. It gives them the ability to expand some of the applications that they use. And those applications don't have to be open source applications. They can still plug in to an API oriented environment. We believe in standards based protocols, languages and standards based tools. We have an enterprise focus. And we build tools for the enterprise to help you make things easier for a DevOps approach and also outside of DevOps. These are just a lot of the photos that kind of go along with some of our products there. We'll go into detail on some of those. So the concept around the SUSE approach. Now, there's a couple of things on this slide. When we talk about the development of our Linux distribution, we start out with a lot of the open source projects that are being developed using things like Git or SVN, some of them. We'll see a lot of the projects moving today using a Git back end. Whether it's coming from GitHub or some of the other variants out there, Git Torious, I think some of them actually have merged just recently. And then we use Jenkins as a tool to automate some of these and grab the newest and latest version. He's always constantly looking out for that newest version. When it's available, we use a tool called the open build service. Has anybody heard of the open build service before? A couple of hands, awesome. Okay, now the open build service used to be called the open SUSE build service. And then we thought, okay, well, it'd be nice for other people to use it. And when people started using it, we thought, well, it doesn't make sense for it to be the open SUSE build service because we do package Red Hat and Ubuntu and Debian and we can arch. Arch, we can build packages for multiple distributions from this build tool. And so we changed the name to the open build service and there are actually other companies that use the build service either internally for their processes, for building out their environments. Even the Linux Foundation themselves has an open build server there. And it's worth pointing out that it's not a product. It is a project that we've contributed back to the community so it's open source, go grab it. Yep, absolutely. Yep, no cost. And then once we have Jenkins picking up a new version of say Apache as a new version of Apache, he alerts the build service that there is a new package there and waiting. The build service will go out and grab that from Git and he will start building that new version of the package. And then that package will be created and sent into a repository where it can be easily consumed by either creating the distribution with that package or being downloaded by somebody else that might need that newer version and incorporating it into their distribution. Jenkins is also used on the backend to say, hey, I have a new package or packages and I want to build a new image of this distribution. And I wanna make it available in all these different formats from Docker to Hyper-V to KVM, Zen, many different formats. These formats can then be consumed by OpenStack. They can be consumed by Windows Azure, Google Compute Cloud, Amazon, the very big one. So various formats, it's very convenient. So having this build tool with all these other open source tools put together can allow you to have this nice concept of moving through the stack and creating an end-all image that can be consumed by your operations. Another thing to note, at the very top, we have SLEZ12 machinery. And I'll get into a little bit detail on what machinery is. This is a new tool that actually comes with SLEZ12. So it comes with your subscription of SLEZ. Essentially machinery, it comes with Kiwi and it allows you to build things and inspect systems. So openbuildservice.org. So if you're not familiar with it, that's where you go out and grab the code if you want to download it and install it. They also have appliance versions of it as well. So instead of installing VRPMs, you can grab the appliance and quickly deploy it. We also have SUSE Studio. So if we go back here in the build part here using Kiwi, SUSE Studio's underlying technology is Kiwi. So there's been a minimal amount of options that have been thrown as available to the SUSE Studio UI. You can't do everything that Kiwi can, but there is quite a few things that you can do. But it's a really nice UI that allows you to create images for the various clouds that you can actually deploy. It's a great tool and you can build images in a matter of minutes. But it is only SUSE capable. SUSE Studio is only SUSE capable. Kiwi can build multiple distributions. That's one of the features that's not exposed to the interface. That's right. And then we have for management and monitoring, we also use Nagios to do a lot of our monitoring of the infrastructure. And we have SUSE Manager as far as an update mechanism for the management of the compliance and doing some auditing in the infrastructure. So some other tools. Let's kind of go through some of these things in detail. If you're not familiar with the open build service, it does have a quite extensive CLI called OSC. And you can actually use it to do local builds. You can check in and check out packages. You can check in and check out the tar balls, patches to those tar balls for package building. You can check in and check out your spec files, a number of things, specifically relating to package building. It's a really, really powerful tool. And if you don't have access to building it over the internet and checking those things in and having our build servers go out and build them, then you can run a local build of it and it will actually go out and grab those packages required for the build and it will build it in a nice contained environment. It also has quite an extensive reporting utility. You can actually go out and see what packages are being built on the many different build servers that are available. And we actually have, internally at SUSE, we have part of those components running in our cloud on OpenStack. And we're actually building packages on OpenStack. So it's nice to be able to spin those up and utilize those on the OpenStack infrastructure. One thing that's not in here, but is really, really nice is it does also have integrated testing and code checking for you. So as you're building your stuff, it'll actually throw back feedback as far as, what all is it check on there? It's got an integrated testing suite. I can't remember the exact pieces of it, but it has an integrated testing suite so you can maintain this quality of your code. And this is actually basically what we use to be able to build the SUSE Linux Enterprise Server. So a lot of the automated testing that we have that we're doing for the enterprise distribution is integrated into the OpenBuild service. Right. And some of that we push into, as far as, when we do the version testing, the version testing is specific to certain versions of packages that we have deployed for the distribution itself. And when it does a version test, it makes sure that it has all the right dependencies and things that are required to build that for that distribution. So it'll do several different checks before it actually does the build. It makes sure that all those requirements are put in place before you actually build the package. And so it will do that if you actually are building your own code and creating it for your own applications, it will do those kinds of checks for you to make sure that it's actually going to actually run on that distribution you're building it for. Something that's also nice is it will push out through Jenkins. Once the builds are complete, Jenkins will pick that up and say, hey, I'm done. And he will take those finished packages and then throw them into OpenQA. OpenQA is another project that we contribute to quite heavily. And it does a lot of our testing and QA for our distribution. In fact, if you run the tumbleweed version of SUSE Linux, that's constantly doing QA checks about every two weeks. Running all of our packages through OpenQA. Which is kind of interesting. It makes tumbleweed a little bit more stable. I run tumbleweed on my laptop and I come across problems now and again, but rarely. But for the most part, you can get the newest, the latest and greatest shiny objects without having to break too much. So try it out, open build service. Great tool, can integrate well with many different development tools out there. And if you wanna see it online, you can go to build.openSUSA.org. That's right. And that's our online version of it and you can go create yourself an account there for free and start using it. It'll build for multiple hardware platforms as well as well as the multiple distributions. So from a single check-in of your code, you can then spit out packages for SUSE, for Red Hat, for Ubuntu, for X8664, for the mainframe, for PowerPC, for ARM. You can go a wide variety, the list of hardware architectures is really long on that thing, that's right. Yeah. So if you have a Raspberry Pi, you wanna play around, there you go. Okay, so we touched on SUSE Studio a little bit. This is really the fastest and easy way to just point and click and build. You hit the build button and you're done. And you get different outputs and it will actually publish. It's got a feature to publish that image to Amazon and also to Windows Azure. Who here has had the joy and the pleasure of building a Linux image for your production use before? Couple of hands, not very enthusiastic. It was not a fun process. If you go look and Google for how do I build a Linux image? Usually the shortest thing that I ever found was like 20 pages long worth of DD commands or your mountain apple blob and then doing a tree to install into the thing and it was not fun. It's so cumbersome and that's one of the reasons why you typically just have that one gold master image and then you have your list of applications and you have a whole compatibility matrix between all the different versions and all that kind of stuff. And Studio makes it so easy to create those baseline images that at that point it's just easy to just take the application and merge that directly into the build and then you can version control that as an integrated whole that you're distributing and from a DevOps perspective where you're trying to get automation and you're trying to get efficiency in your processes, having it being able to throw down an image is going to be much more consistent in terms of its application as well. And it's also gonna be faster to do quite frankly than if you're using a management platform like Puppet or Chef or something like that to set things up. The image-based building is much more consistent in that process and Studio makes it so, I mean literally you can go, I've had my son when he was four years old, I had him go through and create an image for me just so I could tell people that he did and it took him about two minutes. And most of that was, no, stop playing with the dog, come over here and work on it for a second. How many of you guys have used CoreOS? Oh wow, we've got quite a few. So CoreOS is, it's an image, right? It's an image OS, it's very tiny and you can make what we call a juice image, just enough operating system with SUSE Studio. Now a similar concept really kind of applies if you're using the DevOps approach to using some of these tools, the open build service and Kiwi to create your images, you can really have a similar CoreOS type environment but you get an integrated solution that you're gonna be able to do the patches and updates really quickly and easily with the whole flow, the whole workflow. So this is something new with SLEZ 12. And we wanna talk about this because we feel like it makes things easier for everybody. Do you remember when I was talking earlier about the fight between IT versus the developers and the conflict? So the modules here is our way of kind of bridging that gap and solving that process for them. The idea being that, does anybody know what the lifecycle is for SUSE Linux Enterprise? Anybody, nobody? Okay, it's 13 years. There's 10 years of general support and then you can purchase up to another three years additional support beyond that. If you're running on 13 year old codes that would be from here would be like 2002. If you're running on 2002 code and you're expected to write a web app that's gonna be fun and exciting and get you lots of traffic and all that kind of stuff, as a developer that is not going to excite you. So what we're doing with modules is we've taken a couple of key packages that are areas and we've decoupled them from the lifecycle of the overall distribution. With the benefit then being that we can then version control those much more rapidly within the context of that module, whereas the baseline distribution can still maintain that stable and consistent path if you want to just stay on the single version of code. And so it gives you a nice balance between the two of those. Absolutely. And it's no additional cost. On top of that, we're actually providing five different modules. So let's take a look at those. So we have the web and scripting module. So this guy is gonna get a three year with an 18 month overlap lifecycle. So some of the content in there, you've got your Python, your Ruby, your PHP, those kinds of scripting tools. All of your web 3.0 or whatever version we're on now. Yeah, tools. Exactly. And then we've got a legacy module. This one's not so exciting. But if you do have that one application that still requires like an old Java one, four, two, and nobody's shipping that with the kernel with the mainline distribution anymore, you can take advantage of that through the module here to get that older version if your application requires it. And then public cloud module. This one's great because it's on a continuous integration. And if you're familiar with cloud and it, that is part of this. And we're doing some things. We're contributing to upstream on the cloud and it package. And there's some really neat things we're actually enhancing in that particular tool. And that's why we put this on a continuous integration because things in public cloud spaces are always changing. There's still evolving and they're still developing things. And so cloud and it changes too with that. So we have to adapt and we have to be able to make sure that ROS is going to be able to fit into that platform well. And cloud and it's part of that. The tool chain is on a yearly delivery now. GCC you'll get a new version every single year in the distribution. And then really neat tool, advanced systems management module. This is kind of neat because we do have now on a continuous integration lifecycle, we have puppet. So we're supporting puppet on a continuous integration lifecycle. We have also CF engine and we have a new tool called machinery, which is on the next slide. Look at that, I was right. So this is some new shiny object that we like to talk about. Now, being that it's new and shiny, it also leads to the fact that it's new and it's still growing. And the things in blue, or I guess it's the greens or it goes there, those are the things that it can do now. In the gray, that's kind of what we want it to, we want to see it doing in the future. So it's still young, it's still working on it. So what machinery does is enables you to inspect a system and when it'll inspect it, it'll tell you all the packages that are installed on that system. So it'll be looking through the RPM database and saying, okay, these are all the RPMs that are installed on this system. But it can go further than that, it can say what files have been changed from those RPMs from their original state. So you can get an idea of what configurations, custom configurations you've made to that. And then in addition, it will find all of the packages or files on your system that are not managed by RPM. And so if you have a custom tar ball application or anything like that, it's outside of the scope of the packages, you can do that. And so with this, the machinery gets a complete integrated view of what exactly is going on with your system. And enables you to do things like the validation bit is where you can actually compare a system to a previous machinery profile and find out what happened, what's changed, why is this not working anymore. You can use it for migrations. So say you want to move a workload to the cloud instead of having to reinstall the entire thing from scratch, you can take a machinery profile on one system and apply that machinery profile to the system in the cloud. And in theory, we'll go through and rearrange and install it, set everything all up so that the two systems are identical to them. Really cool stuff. And so you can see, sorry, I'm not trying to step on you. Under the inspect right here, you can see we've got a wide range of systems that are not all our operating systems. So we've got SLS 11 and 12, OpenSUSA. We've also added in support for RHEL 6. So if you wanted to inspect a RHEL system because you wanted to move it to SUSE, which I think would be an awesome project for all of you to do, then this can help you do that. It'll give you that complete sense of what is on that system. I don't think the engineers have finished yet doing all the code, so you can just take that RHEL 6 and apply it directly to a SUSE system, but it will give you all the information you need to be able to make that transition process. Really powerful tool. So SUSE Studio has a lot of functionality in that UI, so you're gonna see these other things on the outside here. Some of those tools, like this Run tool, SUSE Studio can do now. You'll see us kind of split some of that out with this machinery tool. And so it's going to evolve. So kind of watch what's going on in this particular community. Machinery-project.org is where you can find some code there. And from a DevOps perspective, how this ties into DevOps is you can use this, for example, if you have a few devs who want to run stuff from dev to QA and they don't want to have to sit there and itemize out all the pieces that they made, changes they made to the system and get it over, they have a tendency to forget, not that that ever happens. But you can automate the process of taking the dev system, hitting a button and have it pull the profile and then apply that profile to a QA machine so that you get an exact duplicate and that helps you move through the process. Yeah, absolutely. Okay, so a little bit of a switch here. So platform for your data center evolution. When we talk about our cloud, SUSE OpenStack Cloud, we are an enterprise OpenStack distribution today. And so we actually are one of the first, first ones actually ever delivered for OpenStack. We actually, yeah, we were the first. We have full integration with Ceph. And as far as Ceph is concerned, we are supporting the block and object storage there. You can use Glance for the image store. And we're enhancing that now because we do have a product, SUSE Enterprise Storage. So it's gonna be on its own life cycle now but we'll be able to integrate into SUSE OpenStack Cloud. And the key thing on here, at least to me, is the award-winning worldwide support. How much does Linux cost, right? Anybody? How much does Linux cost? It's, right, big fat zero, right? My dad always used to tell me, and I'm not making this up, he used to tell me that Linux is free as long as your time is worth nothing to you, right? So you're always paying for it in one way or another. You had the freedom of speech versus freedom of beer. I say it's freedom as a puppy. The point being that when you're paying money for Linux, you're going to be paying for it one way or the other and the supplies for Linux, OpenStack or what not, by leverage, what you're paying for is support when you pay an organization to help you with it. And so by having the, we feel, and it's been validated in the industry, we have the best support structure in the enterprise Linux space and that translates down into OpenStack and so that gives you the best value for your money when things do go wrong because they always do. We'll be there at the other end of the phone to help you out. Yep, that's great. Sorry, that's my little plug for, I get excited about this kind of stuff, I'm sorry. I mean, this really comes down to the ruler of the stack. I don't know if you, we talked about this earlier. We have been the ruler of the stack winners for the past few OpenStack summits. Ever since they started it, we never lost. And we're the fastest and the most simplified management for deploying your OpenStack cloud, including being able to automate having your high availability. So if you can drag and drop, you can build a cluster in just a couple of minutes and have all your control plane services all be clustered. We can also take advantage of your entire ecosystem and the skills. And so we can handle multiple hypervisors from KVM Zen, Hyper-V, VMWare, all pluggable into SUSE OpenStack cloud. And of course the APIs, you can integrate those into the DevOps model. So those become really convenient working with the open source tools that we just talked about. And being able to automate and instantiate instances in your cloud from the images that you build using some of those tools. SUSE Manager is there to take care of your environment for compliance, your security, and monitoring the overall health of your environment there. And then of course some non SUSE components that we've used, we still contribute back to their community. Jenkins of course is a key component for automating some of this. Our open build service and then of course Subversion, Git, and there's many other types of versioning tools out there that could be plugged into this. But we are here to help. If this is something that's interesting to you to deploy in your own environment, we've said earlier to go out and try the open build service. Try out some of those open source tools to integrate a true DevOps environment for your infrastructure. We have a very vast knowledge base in our consulting organization that can help you out there. And we have a very large portfolio when it comes to our solutions. So you can pick and choose there from our SUSE start to our SUSE assist clear down to our core implementations. So just to make sure that this is not purely like a product placement ad or something like that. So the open build service that again that's free, you can go build open, if I can't even talk. Build.openSUSE.org, start checking that out for free. SUSEStudio.com again free online, go check it out, take a look. SUSE Enterprise, unfortunately it's not, well, fortunately for us, it's not free because we need to eat. But we do have open SUSE, it does have all these packages as well. So if you wanna leverage our community distribution, Kiwi is part of that distribution. And as we said, you can build that for anything and everything under the sun, so we'll get you covered. Very important, come by our booth and grab one of these little thumb drives because it's not just a thumb drive, it is also bootable, and you can have your own cloud deployed from this, okay? So, come and grab one. Be careful though, because it will image whatever you boot off of it. It will. So, exercise caution. All right, thank you very much.