 Hello everybody. A lot has happened in IT during the past 15 years, so 2005 Git and Puppet were introduced. The Linux kernel was still in its 2.6 version. The kernel summit moved the first time to Europe to Cambridge. In 2006 AWS started its EC2 service 2010, OpenStack project launched. 2012 and Civil was invented. One year later, Docker in 2013, 2014, Kubernetes and Terraform started. Then terms like CI, CD became popular and everybody talked about scalability and agility. But let's face it, you're talking most of the time about the same architecture Linux started in 1991 with this Pentium 386, just faster and with more memory capacity. Many of us perform in essence the same task like all these years before, configuring hardware, sizing storage, installing operating systems and preparing networks. Once was a system administrator or even an operator has now SRE or DevOps Engineer on his business card. A lot of setups in these days are in production to this very day. So this talk is dedicated to all who are new to the so-called cloud business or want to have to get acquainted with the new terms and principles. Communication is key in our business. So I try to sort out a few commonly used important terms and talk about their background. This is not a deep dive into a specific type or brand of cloud computing or software tool. I will give some examples though and show you some demo code. This talk takes you on a ride about the principles of cloud computing and I hope you have some classic knowledge of IT management. Be it you've worked with servers for some time or be it that you've set up your own computer for home automation, a personal web server or as a gaming system. But first of all let me introduce myself. My name is Nils Wagner. I work as an architect for the OpenTelecom Cloud at T-Systems. I'm reaching out for technical communities like you and I'm working in a team called the Ecosystem Squad and as such we provide tooling for cloud consumers or cloud users. I have some expertise in IT security, consulting, I was an editor and author at Tech Magazine for several years but then I switched back again to system engineering and operations, cloud computing and server automatization. I'm a user advocate for open source for a long time. I'm a co-founder of Linux tag and from Germany and thus I'm a member of the board of the German Unix users group. But let's just dive in. Well the name of the game is cloud computing but what does this term actually mean? If you ask three people you get four different opinions usually. It's Dropbox cloud computing. It's Gmail cloud computing. Probably I've heard about the next cloud tool. It's Airbnb or Uber and cloud computing application. What about OpenStack? So we see that the label cloud is attached to very many services and there are actually dozens of definitions. One of them is the NIST one is that it's still somewhat vague but you can read that in many spaces. I won't read the whole explanation here in its full text but I'd like to break this up a little bit in smaller digestible pieces. So the obvious of cloud computing, some generic characteristics are cloud computing is ubiquitous. It's convenient and on-demand. What does this mean? Obiquitous computing means that the location of the hardware, the actual hardware and the users are decoupled. So usually they are connected over a network. So cloud computing servers usually are located in a huge data center whereas the users can be anywhere in the world. They just need to have some kind of network access. Well what does convenient mean? Convenient especially for the user. So it's not necessary to enter a cool-down data center. No sneaker administration as we used to call that but instead use automation to have your systems, your computers, your servers, your networks and your other resources API driven so you can program that. What this means, you will talk in a minute. On-demand means that you use your compute network storage resources when you need it. No time consuming order processing means that there's no forms that you have to fill. There's no hardware supplier, sorry, you have to ask for ordering and so on. So the resources are there on a single click of the mouse. If you implement that you experience two features. One is network access which is more or less direct consequence from the ubiquitous way of working with the cloud. Since the cloud is not in your computer cabinet or something like that, it's not on-premises. It is connected via the internet and to overcome this mentioned ordering process that usually takes days, if not weeks or months depending on your organization. A cloud provider keeps a pool of computers, hard drives and other resources on stock for several users, for several users at once. Those users can be different departments in your organization, say the tech department, the software development department, the marketing department or the financial department. Or it could be different customers of a public cloud service, which we are talking about in a minute as well. Once you order one of those resources from this shared pool, then they are private for your private use or your organization's private use. What this means and what is necessary for that, we will also talk during this presentation. So one of the key question is what are actually resources, which I mentioned already several times. So let's think back for 5, 10 or even 15 years. So if it was your task to configure a classic setup, that required you a lot of detail knowledge. It required to understand your servers, RAM types, how to collect the right hard disk controller that fits to your storage solution. You might have set up IRQ settings for a network interface card, deal with BIOS settings. You have to talk with the network guys about which IP address to use, about the router configuration, firewalls, and so on and so on. Time server resources, you have to install your operating system from CD-ROM or DVD. You have to provide locking information, maybe plug into a user management IAM system of your organization. You may have a configuration database where you have to enter the new server once you've installed it and so on and so on. All these subcomponents of an overall setup are resources. And many of them are very hardware specific, very specific to the specific type of resource of a specific hardware vendor, for example. And in cloud computing, resources are components that are abstracted to a certain degree. So if you take a specific brand of a hard drive, what is the actual important feature of this hard drive? It's not actually the brand name or the type of its connector like an SAS or SCSI connection or SATA or whatever, but it's more or less the size. It should be and should have a name or an ID. And you want to know where did you attach it to. And those are the three important features and attributes to a resource. First is the abstraction. So now we're talking about the hard drive as a quality volume and say, this is, I don't know, 16 gigabytes in size. We have it automatically in our central configuration database so that we can look it up how many volumes did we use so far for our setups. And we can configure it from a single place of all its features. Configuration of a volume is probably in essence to attach it to an existing server, for example. We see this in a minute. So every important device, subsystem or component can be a resource. Each resource can be, so if you're doing cloud computing, you can create, retrieve, update and delete resources. You create one, you create more or less out of the blue a new hard drive of volume from nothing. You can retrieve information about existing hard drives that you created and see its features and attributes. You can update it so you can even resize the volume or other resources, change some other of its main parameters. And obviously you can delete them if you don't need the resource any longer. And those four major operations are called the so-called CRUD operations. CRUD operations can be performed to almost every resource in cloud computing. Sometimes there are even extra activities but these are available most of the time. But most resources have IDs so that you can reference them. And you can link resources, for example, attach the volume to a server by their IDs. Here I have an example. This is the command line client for OpenStack. OpenStack is a cloud computing platform. You can think of OpenStack as kind of a cloud operating system, so software that manages all your resources. In this case I have two resources highlighted here in the boxes. And let's start here to have a mouse pointer here on the top right and I list all my volumes here. OpenStack volume list and I am just interested in two attributes, its ID and its name. I see I have four volumes listed here and they have all IDs. And I have also a list of servers with a very similar command, OpenStack server list, also with ID and name. And one of my hard drives that I created previously is here connected to the server. If you look up here, E9F3 is the ID of one of the volumes. And I look up the details of this volume, OpenStack volume show in the ID. And I format the output to some JSON format and do a little bit highlighting. And then you can see the server ID points to another resource, to a server resource and that is listed here. So what does this mean? I have previously attached this volume to this server and I just looked up the connection here. There are obviously other commands as well on this command line tool. It's not only OpenStack volume list but also OpenStack volume create, OpenStack volume delete and so on. Some more features of clouds, especially one feature that is different in cloud computing from classic computing is elasticity. In the NIST definition, this is described as resources can rapidly be provisioned and released. But the more common used term for this is scaling. So when resources are needed, you can use them and even increase them in size and also drop them if we don't need them anymore. So you can do this with a, say, a web frontend. You could use it in a command line. But it's even more efficient if you have some software that takes care of that and does that automatically. So for example, your cloud controller, your cloud scheduler could monitor your network bandwidth consumption and if that exceeds a certain level, it could just spawn another set of virtual machines, assign new IP addresses to it, maybe enter those IP addresses in the load balancer and so on so that you can on the spot scale up and scale down your resources. And that is what I meant with automation so that you have minimal management effort or direct service provider in action. So I worked as a system engineer for several years and when we had to, the demand for new servers had to fill out a lot of forms and send them to the right people, open tickets, wait for response, do some clarification and so on and so on. So all this is no longer needed in proper cloud computing. There's no need to ask for permissions and you have a programmable infrastructure and we call this infrastructure as code. And we talk about this also in a minute. Cloud computing comes in different layers and abstractions. So the NIST definition calls this the service models and there are mainly free basic layers that are very common and you'll read these terms all the time if you're into cloud computing. So first is infrastructure as a service which is more or less a one-on-one mapping of your classic server resources which we talked just about like volumes which are the equivalent of a hard drive or a server or a network or a router, something like that. This is in essence the main offering by commercial cloud providers. So they provide you an abstracted way of classic resources. What you do with that is completely up to you. You can install directly applications on top of that but you could also install some extra software that takes care of specific activities like scaling up, scaling down, monitoring your resources, its consumption and so on. If you use software like that we are talking about platform as a service. That is even more abstract that gives especially developers a nice platform that they can rely on and so they don't need to deal with the installation of operating system configuration, the details of an operation system, deal with IP addresses and so on. All this is already taken care of the platform. Usually nowadays platform as a service means most often Kubernetes because it's by far the most commonly used platform. Software service is just a complete application that are usually pre-configured and ready to use for you as a user. Which abstraction layer, which service model is the right one for your specific setup. Let's have a look here. There's a little bit about theory and practice. Managers think SAS is the right thing because they just have to pay for the service. No distraction for anyone of their own staff to set up, configure or maintain the software. So we can think for example of Gmail as a SAS service. You just order the service and you get an AS service. You get a mail client and everything behind that. The servers and the routing and the networking stuff is all abstracted from you. But you have to stick to the service that is provided from the SAS vendor SAS. So what developers usually want is platform as a service. They allow for easy deployments. Don't have any hassle with operating system. Have no discussions with system administrators because they can use containers and other pre-configured programming frameworks for say Ruby and Rails, a Java framework, some Python environments or already pre-configured. But administrators most of the time want is infrastructure as a service. Because those are familiar resources but in a more convenient way to access them. So it depends a lot what kind of applications you want to add into the cloud. The more control you need to have on your specific application, the more you want infrastructure or platform as a service. But of course you can build the higher level services always manually on the lower level services. So for example you could order infrastructure as a service from a public cloud provider and then install a Kubernetes system manually on top of that or maybe even better, automated on top of the infrastructure as a service layer. Once you have your Kubernetes in place you could also deploy applications on those Kubernetes clusters and deploy the software as a service application. I talked already a little bit about the terms private cloud and public cloud. Private cloud is more or less a synonym for something that you have on your premises in your server cabinet, in your private data center. While public cloud is hosted in a central way, usually in huge data centers which are spread out through the country, the continent or even the world, but which to pick. That is a very important question especially if you're new to cloud computing. Many users tend to prefer the private cloud first because you think you may think that you have more control over your systems and that your private data stays private. But there are also some advantages for the public cloud because in this case maintenance is not your concern but your cloud provider's concern. You can also do some resource sharing with your co-customers, with your fellow tenants of the public cloud. That can give some great advantages because you don't have to pay upfront for the resources that you manage in your private cloud. There you have to order and provision everything yourself whereas in the public cloud this is the cloud provider's activity and task. So if it comes to scaling, the public cloud has huge advantages. And if it comes to privacy and control over your data, well it's obviously very very important to have a trust relationship to your cloud provider. And this trust relationship is defined by several parameters. So what is your general trust in this specific vendor? Is it a trustworthy organization? Is it a trustworthy company that is running this service? Where does it run? And what kind of legislation is it running? So different countries may have different requirements on how and where to store and process your data. So that is different from country to country and you should check this prior to actually using the public cloud. Well they are not only private clouds and public clouds but also community clouds, hybrid clouds, multi-clouds and so on. But those are more or less all just terms for a mixture of the both concepts. So for example a hybrid cloud could be a private cloud which is hosted by a specific public cloud vendor but which is only accessible and all the physical resources are only accessible by yourself. So that is one option if you want to combine the advantages of the public cloud and the private cloud. And the multi-cloud is the situation when you use several public clouds in parallel, several public clouds provided by different vendors. So the largest public cloud vendors at the moment are AWS from Amazon web services, Microsoft with its Azure service and Google with their Google cloud platform. And usually those three market leaders are called hyperscalers. But there are also open source-based cloud installations. So for example OpenStack which we'll talk in in a minute. And there are several providers who run for example OpenStack-based public clouds. And in this case this is especially easy for you to distribute your world clouds to several of those public clouds because they speak all the same language, the same they have the same APIs. So you can use one controlling software to control several cloud providers at the same time. So let's do a short recap on how the service model and the deployment model work together and what is the kind of the evolution of something. So let's start in the lower left corner with classic server. They have no service model and they are installed on your private on-prem systems. So these are the classic servers to be used for several years. So the next step is a local cloud where you install some extra software on top of your existing servers to be able to manage your existing resources in a more convenient way. That is more or less a local cloud. That's the wrong direction. If you move those on-prem managed systems into the public cloud then we are talking about the hyperscalers or the other public cloud providers as I said like public providers of OpenStack or the like. You can also order directly and do one step ahead towards the service model and use an orchestration platform, an orchestration platform like Kubernetes and then run on top of that your applications. So some examples for that. There is for example OpenNibular which is a cloud configuration software for local resources and there's OpenStack that can be used both for local resources, so for private clouds as well as for public clouds. OpenStack especially is used also by huge organizations like CERN for example. So they have lots of computer resources like a service provider but they distribute their resources to all their departments and research groups. As I said orchestration platforms are usually Kubernetes and here are some examples for software applications like Gmail, Office 365, SAP can be run on cloud instances or you install your server next cloud. There's something that I forgot which is server hosting so there's also the situation where you order a preconfigured server but you don't have it on your own premises. So typically this is a vserver or a hosted server somewhere in a data center and this is also an alternative but in my opinion not really cloud computing because server hosting lacks the features of cloud computing with all its abstractions and APIs and automation and scalability features. So it's easy to order and provision a single host which has usually a fixed set of resources like I don't know 100 gigabytes of hard drive capacity and 16 gigabytes of RAM but it's difficult to upgrade that so that is the distinction of server hosting and cloud computing. So I talked already a little bit about OpenStack and would like to tell you a little bit about its features. The software is a software stake consisting of several SAP components so there's a sub component taking care of computing, there's a sub component taking care of networking, another one for volumes, for block storage, for other types of storage, for databases and so on and so on. So I think over 50 SAP projects of main resource groups. The SAP itself was founded in 2010, celebrated 10th anniversary last year and OpenStack has a huge community. It has more than 100,000 members who are registered at the Open Infrastructure Foundation who's also kind of a governing organization. It's pretty much the same with Linux and the Linux Foundation. There are many sponsoring companies who drive the development and the further features of the platform. OpenStack has and operates its own infrastructure called OpenDef that is taking care of the development process including quality assurance, testing, documentation and so on on a dedicated platform. There are two annual releases and they are numbered by the alphabet A, B, C and so on. We are currently at Wallaby so that means this is I don't know I think the 23rd release of OpenStack. The development model is really impressive of OpenStack. It's a big challenge to deal with that huge amounts of code. OpenStack is built in basically Python. It's the third largest open source project. I think the Linux kernel is number one and I think the Chrome browser is the second largest open source project. And as I said, there are more than 50 projects for the different components like compute, storage network and so on. If you have such a huge project with many cross-module dependencies, then testing becomes very important and therefore OpenStack facilitates Zule CI continuous integration server that checks if each and every new code contribution is fitting to everything else and makes sure that no broken code gets merged into the project. While we have a development model there of team leads, core reviewers, typical developers and they all facilitate that Zule and overall CI process that is hosted on the OpenDev platform just to let you know about the model. The Open Infrastructure Foundation also runs conferences at the moment. Obviously they are the virtual ones but I think the foundation already considers having onsite events again starting next year. Let's keep fingers crossed that we overcome this pandemic as soon as possible. Yeah, I talked a lot about different approaches, how to deal with resources and this is a screenshot of one way to deal with that. This is a bed-based console and what you can see here is in the main part, see if I can get the mouse back here, a list of the server resources. See a lot of information about systems themselves and you can start new ones and create new servers. You can start them, stop them, restart them and so on and so on and you can see some of the extra categories of other resources that can be used. Just to get a quick impression of how the UI looks like but this is not the only one. You can obviously just work on the command line and do the same thing here and include this even with some kind of scripting. So as you've seen there are interfaces to the cloud that enable it to automate your tasks. For example, you can easily code something like a feedback loop, checking for some monitoring, bend with metrics and react on that. Well, usually you have a software that does that for you but if you want to write your own you're welcome. So automation is possible with the cloud because you can control and program your resources. So system administration used to be kind of an art but it should be actually engineering because art is unpredictable and if it's real art it's also unrepeatable. But if it comes to your server you want something to be predictable and repeatable. In case something went wrong, in case you have to shut down some services and restart them, you don't want different results if you do the same activities. So that means that you don't need to perform any manual task twice and you can rely on the automation if you apply some kind of convention and use the right tools. And those conventions can be called infrastructure as code. The idea behind infrastructure as code is to write in specific domain, specific languages a description of how your infrastructure should look like and then just run this code and let the framework set up infrastructure. I have an example here. This is an example for a very commonly used tool called Teraform where I describe two network resources, a subnet and a virtual private cloud, a whole network range and you write those descriptions and just apply those and the framework finds out what kind of activities are necessary to create this description of your infrastructure and applies the necessary steps and if you don't need it anymore you can just destroy it. Another framework that can be used for that is Ansible. Ansible is used mainly as a configuration management system but it has also some infrastructure as code extensions, implemented in so-called Ansible collections and one of those collections is OpenStack cloud and this provides the resource server and if you're familiar with Ansible this is just straightforward so you have a task of creating a bastion server or some other server by facilitating this module and provide a number of attributes and Ansible takes care of creating that. Here you see a little bit more extensive example for full-fledged server instance but it's not necessary to look into the details if you want, you can look this up in the conference material that I provide and finally let me focus on some security and privacy issues. If you talk to people new on cloud computing, security is often the concern number one for most new users and they often ask how can I be sure that my resources are private to the eyes of the other tenants of the same cloud service. Here it is important to understand that the virtualization is here the key. The hypervisor separates the tenants from each other completely. It can use in in general different technologies to do so but usually what you use in cloud computing is virtual machines that get created or maintained by hypervisors like KBM which is an important part of the Linux kernel so that not one single virtual machine can access the other one and vice versa. Then there's also the shared responsibility worth mentioning for the provider of the cloud and the user. So the provider takes care that the cloud itself is up and running and is implementing its security features. It makes sure that there are enough resources for storage and for backups and so on but it's up to the user to actually leverage those services that are available. So in general a server can crash and for that you should take care and take provisions in advance and for example set up directly several servers in different regions of the world or in different availability zones so that they don't can affect each other. The cloud provider provides those availability zones to make sure that they are actually independent and the user has to use them but still authentication and authorization is obviously important so that you first know who is actually accessing the cloud resources and is the authentication authenticated person authorized to access some resources or to perform certain actions and for that there's a special protocol which I sketched out here for OpenStack use case but this is more or less the same for any public and private cloud. So usually the client starts to contact a well-known service catalog and asks for services for example list all existing volumes for my tenant. Here are my credentials, this is usually username and password and then the identity management of the cloud verifies the credentials and returns time-limited token usually a few hours or a day or something after that it gets invalid and it also returns the actual service endpoint because the endpoints can be distributed in the internet and different endpoints can maintain different types of resources. The client receives those two information pieces the token and the actual service endpoint and then in turn contacts those service and provides the token the service in turn validates the token and performs the action. Obviously the last two steps can be now repeated and repeated and you can also provide policies to all those actions those specific actions so that even an authenticated and generally authorized user can be further restricted to some specific actions so you can easily implement a role-based access control model on your cloud in this way. This is an example also for the stack you can either do this on your client side in environment variables but it's recommended to do this in a configuration file like a clouds yaml file where you provide some information about your cloud type your customer ID your domain name as we call it in an open stack a username and a password and then off you go. So summarizing everything I'd like to wrap up everything a little bit and give some recommendations before I leave you here. Cloud computing is modeled after classic computing but it's abstracting a way a lot of nitty-quitty details and what you get from that are resources so a resource if you understand the idea of a resource it's pretty easy to work with cloud computing. Cloud computing in general is kind of a mindset and there are three major ideas behind that one is the mentioned abstraction so don't waste your time for those nitty-quitty details the second is scalability you can increase the size of resources and some other attributes as well and by that you can implement real automation and that is a real time saver and makes your overall setups way more reliable because you can automatically react on specific events. Now some recommendation don't try to map everything that you did with classic computing one-on-one and try to micromanage your resources if there is a specific service for example and use it because then it's no longer your task to take care of the service but just to use it so it's then the task of your service provider to make sure that the service is actually what they are meant for so don't for example do install do-it-yourself database servers so it's not very difficult to install a MySQL server and configure it and so on but why should you if you can have readily configured servers just by calling a single API call or launching a single command line so stick to the defaults and trust and work together with your cloud provider in this and your shared responsibility so every party has to implement their specific task it's very good to use software that actually makes use of the features of the cloud so you could for example look up for the term 12-factor app that is a collection of principles that describes so-called cloud native applications and cloud native applications run in a cloud are a very stable and very resizable and elastic way of running your resources is the principle of so-called lift and shift where you just take snapshot images from your existing server setups and transfer them to the cloud but then you use a lot of features so with all that said I wish you good luck on your cloud journey and let me know if you have any questions if you don't agree with me and what I said here in any way and let me know if I can help you in any way thank you and goodbye