Welcome. And before we really start, we want to give you short numbers. So here's a little one. And this one is counting up since some time now.

So if any one of you ever work with Platform as a Service, this is what the website pathfinder org I found states there's a count number of providers for Platform as a Service, which is quite impressive. I didn't expect the number to be that high.

And I don't know if it's complete, but at least from what the website tells us, they are all active and can be used in various stages. So you can filter for alpha, beta, or production. But yeah, it's quite an impressive number. And if you look at the Google Trends,

it's constantly increasing. So we are right here now. So people have a high demand on this stuff. And this means whatever decision you make for whatever tool you choose, it is most likely the tool you really need

will appear after that decision. Yeah, that's upfront. And now to our real talk. The talk is called How to Build Your Own Cloud While Staying in Business. This sounds kind of funny. And maybe you can complete some of your bingo cards

today if you haven't already done it yesterday. Yeah, so what does it mean? First of all, it's great that you showed up that early in the morning. Hope you already had your first coffee. We did, at least one. OK, so why are we doing this talk?

First thing, we don't give this talk to make you feel bad about anything. We just want to take you on our personal journey through infrastructure and shipping software and hope you can take some of this stuff

with you for your own projects. And yeah, as you may have guessed, it's about infrastructure. And one thing that was true for the last year and it's maybe even more true this year, if you start a new product and you're

in charge of infrastructure decisions, it's really hard. The field is really, really complex and vast. You have a ton of options. It's really hard to decide which options are good for you. Most of the time, you don't have enough time to evaluate all of them or have any idea how to evaluate them.

It's not an easy task. Maybe 20 years ago or even 10 years ago, you just got your root server somewhere, put whatever Linux history you preferred on it, and you were good. And nowadays, the field looks quite differently. But it's fun, after all. So at least for us, it's fun.

And we hope you can give you the impression why it's fun for us. Because Docker, when you're talking about infrastructure, not talking about Docker, is hardly possible nowadays. And Docker's really great.

It's a great ecosystem with a lot of solutions and options how you get your stuff done. But it's all one window. And it's kind of a window lock-in. And today, we want you to present some other options how you can choose from different approaches and not only rely on Docker.

That said, we like Docker. We use Docker in production and for other stuff. And it's not to discourage usage of Docker, just to show some other options. Yeah. And there's a task for your workshop going on right now. You're not there, so you already know

that you have to get things done. And we have to get things done as well. And yeah, all of us have to create some business value in the end. It's not all about fun. You have to create something that can be shipped and that produces some value for whatever business you're running.

And the pursuit for perfection is a noble quest. And it's fun as well. But sometimes, it's not well-placed in a business environment. And pragmatic solutions are not bad at all. And yeah, as I always said, we are loving this stuff. So we are both infrastructure and software developers

by heart, and we want to give you the impression that after this talk, you can go home and don't feel bad about your software. You build yourself and don't feel bad about being 10 years behind what's going on in the rest of the world. Because yeah, the bills are always green

on the other side, but we all just start somewhere. Okay. We have some challenges or opportunities nowadays. As I said earlier, doing infrastructure nowadays is kind of hard, but yeah, we have some opportunities as well. So first off, the challenges.

There's an increasing complexity. Software stacks are getting bigger and bigger. So you put frameworks over frameworks. And yeah, you not only have backend frameworks, you have really complex stuff going on in the front end as well. All this has to be put together somehow.

A lot of abstraction layers. You have your development environment. You have something where you have to test all the stuff. You have production stacks, staging stacks, you name it. You have maybe running some of the stuff in the cloud. Some of them is dedicated hardware in an old data center.

Some may be in-house. All of this at the same time. You have different environments for your developers. It's quite options to choose from. Yeah, and still we have to innovate somehow, right? So we have to move forward and create new stuff

and make things move faster. And stay attractive to new developers is also a very crucial task for most businesses. Not running old and boring stuff, but yeah, attract new people with new fancy stuff.

It's all quite complex. But there are, as I said, some opportunities. We got infrastructure on demand nowadays. So if you imagine, you got the various cloud providers. It's not only servers, you got message queues,

you got caches, databases, everything on demand paid by the hour or by usage. So you're really flexible with this. And to use this in a flexible way most of the time comes with an API you can use to automate stuff and put together programmatically. And the hardware nowadays is really powerful.

So there's no real limit regarding the power of hardware at least for the average business, I guess. If you're Netflix, you obviously have different problems. But for most projects, the hardware out there is suited well enough for everything.

And with this comes, we have to find other ways to use this hardware. And one way to use this is virtualization and containerization. And there's even something unique kernelization which all aims to get the most out

of your powerful hardware. And at the same time, the hardware's really cheap, relatively speaking. And yeah, those are our opportunities. And that's why we're doing this talk. And I told you why we are doing this talk

and we didn't introduce ourselves yet. And that's me on the left. I'm Dirk, this is Sebastian, also known as Bascht. I'm doing mainly development and Basch is mainly doing operations. And magically, we're doing DevOps.

Okay, and Basch will take over. One second, we have to change the microphone now. Sorry about that.

So, okay. All right, and in the same way that we ruined Scrum, it only took us a couple of years to ruin DevOps. Just so you know that we are really certified.

You see, I do have a batch. It says certified DevOps. It's Comic Sans, so you know it's real. And so just to take you on our journey, the last slide said Dirk is a developer. I'm doing operations stuff. But come to think of the last few months in Jabber, Dirk mainly does operations and I'm failing with Rails.

So it's not likely we have any clear borders. And like in software engineering, infrastructure engineering is a lot about tools. So this whole conference is probably about tools. So you have like separate tracks for several different languages. So people don't start fights.

And let's have a look at those tools. I mean, it's not called infrastructure engineering for no reason. So we have like a small slide prepared and you can, yeah, I'm just confused by keynote. Sorry about that. What is going on?

Stop it, stop it. Wait a second. I got this, I got this. All right, yeah. So yeah, take a moment to appreciate the handcrafted animations that Dirk has done. So as you can see, there are a lot of tools

with all different kinds of scopes and goals. And they all do have their right to exist. And it's not about like competition there. It's more like coexistence and like integration. Either vertically or horizontally. So infrastructure and its tools are kind of moving closer to the developer. I mean, if you've been in the like operations field

for more than five years, you've probably seen a lot of trends come and go. But if you've monitored what like Docker was for operations, you see like trends evolving from the developer side of stuff. So especially since like the Ascent of Go language

developers start, like the tools start moving closer to the developer. And at the same time, you have concepts and paradigms of the developer tools that have more influence on the infrastructure tools. So we have to sort out all this mess.

I mean, if you took a look around, you probably used like at least one or two tools from that side. And the thing is, everybody likes to have the one tool. You know, that one tool that they really like to use. So be it Docker, be it Puppet, be it like another fancy new tool. And it would be really great

if there would be the one tool that solves all these problems. And the thing is, I'm gonna take you onto like a small quiz. So just think of one tool that you really, really like. So think of anything you've run your infrastructure on. Any IDE or anything that helps you ship software to production.

And then just set in that tool into the blank and read that sentence out aloud. And then think about if that would be still true. And I suppose if it helps you run software production, that sentence will still work. We're gonna resolve the quiz at the end of the slide. So, but just for the sake of the game.

And the thing is, no matter which community you come from, they'll all like, they will all look like they are the same tool, they are the one tool. And they could be the right tool for you, but they might not be the right tool for another person. So we are both from the Ruby community.

So for us, for example, Chef or Puppet are the way to go because it's code we understand. Whereas you'd probably choose Ansible if you're running a Python stack. So it's all a matter of choosing the adequate tool. Yep, that was the slide that should have come

for what I was about to say. So after all, it depends on using the adequate tool for your job. So you have to solve your problems and you have to have tools that move out of the way

of solving the problem. And so, just a small disclaimer for what we're about to talk about. I mean, you've already read it probably in the abstract. This talk isn't sponsored by HashiCorp. We are not endorsed or affiliated with HashiCorp.

We just happen to like the tools that they ship. But this is not even bound to specific customers. We both do freelance development and operations. But it all depends on getting the right tool and the right software and the right pipeline to the customer. And all you're about to hear is subjective.

So the stories we tell you might not work for you. And there's also one key thing to keep in mind. Objects at conferences appear better than they are in real life. So no matter what we tell you, no matter what other talk we'll tell you,

just take a few steps back and think about it. And whenever I want to hear stories from the old Ruby days, we gather around the campfire and then Dirk will take a whiskey and tell us what the old days of development were like. So let's go there.

Okay. Yeah, I don't know how many of you are Ruby devs or doing raid stuff. I started really early and my place to go whenever I needed to set up a new box

or install for a colleague or a friend the raid stack, I went to HiveLogic. And HiveLogic is still, it's not really active anymore. The block of Dan Benjamin, now famous for podcasting various stuffs. And yeah, he regularly updated his articles

for new OS X releases, new Rails releases, Ruby releases. And you had a really long list on how to download everything, compile, set up your compiler on OS X because it was not that easy at that time. Yeah, and eventually I put some of them in scripts

and scripts will fail on another machine because I forgot something. And yeah, it was really a brittle stuff. But then there was a vagrant and I could run a vagrant provision and had one machine to rule them all and share them and give it to Basch

and to other people and do workshops with them. And we all had the same machine and it was a heavy place after all. But the question remains, how did this provision stuff is going to happen? Still some scripting put together.

And because I'm only a developer, Basch will tell you how this provision step behind the scenes will operate. And we have to switch again, sorry. Switching part of the drawing. All right, so let's see how keynote works out for me.

So in the old days, you had like manual processes all over the place. So like Dirk said, you had some, hopefully you had some read me. You hopefully had some abandoned wiki page from like three months ago that worked then for one machine. But let's not go there. So in the same way that vagrant changed the game

for developers Puppet or Chef or Ansible or Salt or CF Engine like brought salvation to operations. Because I remember like six or seven years ago when you would like watch Puppet like magically provision and set up and deploy machines

and it was all the same with me. Like Dirk told you, you would just like run Puppet apply and it's all like butterflies and rainbows. So in the same way that Dirk experienced this change, the operation side also experienced this. Okay, we have this tooling. We have like, we have to solve stuff by automation and we're all happy.

So that was our talk, thank you. That's probably not true but you know, in the same way that vagrant brought like the app, the like developers closer to the operation side, Puppet brought the operations people closer to the developers

in the way that they had to think about source control. They had to think about versioning their software. They had to think about releasing stuff or rolling back changes. All kinds of stuff that wasn't really like any heart of the operations side. And it's all in all,

it's just like mundane infrastructure plumbing. So let's have a closer look at how development really worked then. So, let's say Dirk has an app that should be developed and deployed. Yeah, this is really better, there's two mics.

Yeah, inside my vagrant box that was set up by Puppet or whatever, I would run, I would go into my million dollar app and just run rake build, yeah.

And out will come a Debian package with my million dollar app package and ready to be deployed. Okay, so let's have a closer look at this. So I have my code, I compile it. In this case, yeah, all of you know Ruby,

there's no real compilation step, but you could argue that building a Debian package is kind of a compilation step and out of it comes an artifact. So the same is true if you're having a Java project and there's a Java file, you can move around. The key is we will get one artifact to move around, to deploy somewhere.

So forever, the same inputs, I will get the same artifact, right? And whenever I change some parameters in my code, I will get a different and a new artifact with a new version number and even if I change just a typo in a config file,

I will produce a new artifact. And so we will skip the switch back now because now it's the same coming for operations. Yeah, we're sorry about the microphone situation.

So in the same way that Dirk told you what would have happened if he'd gone into the box and just started Rake, he produced a Debian archive. And in the same way, you'd have operations writing code that would say ensure that, that's just puppet,

but think of any generic deployment or configuration management. In the same way that he did an artifact, we have the ensure latest that will make sure that the artifact of Dirk is really the latest version that's there and we will ensure that the service is running. So you now have like two different code bases

kind of like tangled together and in the end, it's the same thing. You have your puppet code, so you'll not really compile it, but you'll interpret it and in the end, you have one artifact which is your server. So kind of like what the Debian archive is for Dirk,

like the actual, be it a Docker image, be it a VM or be it like a real machine, it's kind of like an artifact because you've run code that changed state on that machine and even if you throw away the version of the machine in the end, it's kind of like an artifact.

So even if your application is a monolith or like really, really cluttered together, the infrastructure is already built of a lot of different building blocks, so even going with microservices won't help you there. If you think of like your stack,

you have a monolithic application there, so that's not a problem, but you have multiple layers of networking. You might have databases. The databases might have storage attached to them. You might need monitoring and locking and that's quite a lot of building blocks and running changes there will at some point become either like a real pain

or you just like can't be bothered to just like run Puppet anywhere where things just worked. So those are all artifacts. So no matter how you put it, it's you run software, software changes state and you have to deal with this. And I fear that we are switching back again, are we?

Not yet, we're not switching back again, so I can keep the mic. Let's see. Yeah, so your average system may look something like this and we're not even like talking real microservices here. This could be any sufficiently simple app

that has like two or three different kinds of like libraries included. Might have like runtime dependencies, might have like dependencies to different versions of a database you're using. In the end, you end up just like with a real, real mess of dependencies, of artifacts,

of code that's coming from anywhere, be it like Ruby Bems, be it Python archive and there's like no real way to put it then this is really, really finicky and there's not a real solution to this problem. So some problems got solved by configuration management,

some problems were solved by giving the developers a real good tooling, but in overall, things are like still finicky. So let's have a look at the downside. The complexity increased with giving developers more tools with like modeling infrastructure as code

because like back in the days, you'd only like throw it over the wall and the ops guys had to take care of it and the changing running systems, which is something that still happens there. I mean, I do run doctrine protection, I do know what it means to have infrastructure

that you treat as cattle versus like pets, but let's be honest, you probably haven't thrown away your production database for a new release or you still have your monitoring system upgraded so we still have to deal with running systems and bootstrapping is still a mess

so if you've seen somebody bootstrapping a puppet server with puppet, that's still not a good thing to look at. So we still have like a real mess and we're not even sure if we've covered all infrastructure components, even if we say it's infrastructure as code.

We've come to realize that more and more infrastructure is acting like software and we need different kinds of approaches there. So what we really want is like infrastructure as code, not just some of it, but let's see how we get there. So let's have a look at the real problem.

We're switching again. Okay, so every of those boxes I showed earlier, you probably will all check with any platform as a service

so at least it's sufficient enough to get this when you go to one vendor. But as we told earlier, we don't want to present one vendor, but give you a feeling of how to put this up yourself. So whether you are doing it yourself or not,

it is at least good to have an understanding of how these building blocks are coming together even if you're using a pass. And yeah, still using a pass, you got a kind of a vendor login. You have at least to be aware of or to have to know if it is there.

If it is a bad thing for you, you have to decide on your own. There's no law that says vendor login is a bad thing as itself. So we will present you a mix of tools and services you can use to make this work on its own and without relying on a pass.

Okay, so a pass checklist would be we want to have a dev production parity. So both environments, ideally they should be identical. This is kind of hard in our experience because in development you want some more information

than in production. For instance, you want to have debug log enabled and if you change this configuration, does it mean they are still the same? Even if you disable it in production and if you're talking about changing even one tiny bit in your configuration,

producing a new artifact, you're running a different artifact in development than in production. So this is a kind of a hard thing to accomplish but you want to get as close to dev production parity as it gets. Obviously you want to have repeatable builds. Whenever you get this code compiled artifact step, this should be automated as good as possible

and not depending on whether Bosch or I compiling it and the artifact will be a slightly different result. The next would be that we want to track those artifacts. So we have to have some kind of registry where we can find our artifacts and look them up.

Immutable infrastructure would be great. So what Bosch presented earlier, all these little boxes inside your entire stack would be changed upon any, even the smallest change of configuration. Again, this is kind of hard for your database.

I imagine throwing away your production database if you have to tweak a parameter. It's kind of sucks. Yeah, and you want to cover the entire stack. So from not only the web servers but you want to have a network integrated, configuring your network databases, storage, logging, monitoring, everything.

Okay, so first of all we present a tool for repeatable builds. And yeah, who knows, it's from HashiCorp. And we like to use Pucker because Pucker is a flexible tool. It can build for various platforms.

You can even build Docker images or provision bare metal machines. You can run it on all of the major cloud providers. Yeah, and that's what we talked about, having a flexible tool for different use cases. And so how does this look? It is JSON, it's not really well readable right now.

But yeah, I hope you get a glimpse of what's happening here. So we somehow define what type of machine we are building. In this case we are building a Docker machine based on Ubuntu image. We are running some post-processing

and that is to push it to the Docker registry. Yeah, whatever, build our own internal or public registry, that depends. And the parts of the provisioners block is left empty because we already showed you that. So there would be running part. And the result would be a Docker image and anyone in the team could run this command

and we'll produce the same image. Sorry, it will be a pack-up build and that's it. Okay, but that's only one tiny building block, right? That only builds one server,

be it the database server, the logging server. We still don't have it interconnected. And yeah, as I said, we need to have DNS set up somehow, databases, all the networking stuff. Yeah, and that's where Terraform comes in. It's also from HashiCorp.

It's also like Pucker, a tool that integrates well with different providers on a different scale. So AWS support is really vast for instance and other providers. All of that good coverage. But overall, you find for the major vendors out there,

you can get some kind of integration. And so we have this Docker image set up and now we need to have some kind of security groups. This is AWS specific but imagine this as a firewall rule for a database.

And we got our database and this has to be, you get a username and we are choosing Postgres for the engine. Yeah, on the plus side of this, this is already documented so you can just read it. Even if you're not familiar with AWS,

you get an idea of what's happening. And again, we can just execute it repeatedly. In this case, there are two steps but that's not really important right here. So first, we plan what changes will be applied to the infrastructure and then we actually advise them. So you have a chance to intervene

before destroying your entire stack. Yeah, and now let's continue. So as you might have noticed, no user interface or UI or graphical UI

was harmed in the making of our artifacts. All of the tools you saw are independent Unix style tools. You can just integrate into any build pipeline, CI server, you name it. I mean, think about just picking one tool and interchanging that part of your pipeline

for another tool. You could have at any point just used cloud formation for provisioning AWS. Now that you've seen the different artifacts, let's see how they are deployed, like run connect. And that's where Nomad comes in. It's like distributed highly available data center where scheduler, that's a lot of words that trigger microservice consultants.

But in the end, it's just like a software that makes sure your software will run in a way that you want it. So remember the million dollar app. We now have like the app artifact. We have like the infrastructure that the app will run on. And just now we have the same like JSON style-ish

configuration language that will make sure that this app is deployed. So to our like German, Austrian, Switzerland region is deployed to like those different data centers. And we have our front end that will spin up like another front end Docker image that we've built in another pipeline.

And say it will spin up 20 front ends of that kind. So think of like Terraform as, no think of like it as a transformation of an artifact into a running service. So like Nomad interconnects your infrastructure with your actual services that you run.

So for now, we've checked a lot of boxes. So we have like dev production parity, at least for those parts that we've modeled into our code. We also have repeatable builds. We have the real mutable infrastructure because for now we didn't touch anything like manually.

Sorry. And so maybe you've noticed there's still nowhere you don't find services covering here because that would just like terminate like the end of our talk. So we leave that part to the avid reader.

But if you remember like a few minutes ago, our little quiz. So you've just like replaced it in your mind, remember? And let's resolve the real solution.

This is SimKey we're talking about. Does anyone know what SimKey is? Does anyone remember what SimKey is? Okay. I had to look it up this morning as well because the slides are a few months old. But SimKey is a hosted JavaScript environment that went on the O'Reilly radar about 11 years ago.

Right? So in 2005. So just remember what he told you earlier. So objects at conferences maybe appear better than they are because this could have been darker. This could have been any fancy tool that if you encountered in your last like 10 years of software development. And we're talking about the tool that has gone

probably since eight years. So nobody even remembers it. So just like take everything you see with a grain of salt and also remember our little formula we gave you earlier. By the time you decide for a tool, any proper tool will definitely come after you've done

that decision. So don't even bother. In the end, it comes to a few rules. So just like don't buy anything from the one tool that has people. So even if like say Docker comes with batteries included but interchangeable. So if you put in your own batteries,

you might set your house on fire. So just like evaluate what's really good for you and what works for you. And if it works, it's probably a good solution for you. Also look out for open and like pluggable solutions. And the most important part, I forgot my T-shirt. Dirk got his T-shirt on.

Appreciate the parts of the infrastructure that really work. And so in our chat room, we had a small like, yeah, saying that it's like good we butter, like good like butter. So we have a seal of approval. And I guess do we have stickers? No, we don't have stickers with us.

Yeah, but in the end, it comes to appreciating the tools in your workflow that really work. So those are the solutions that work for us and they might not work for you. In the end, just appreciate the small tools that you already have, like evaluate stuff and yeah, have a good day. Thank you.

Yeah, we do have a few minutes left for questions or discussion. Yeah, do you have a microphone? Nope, okay. Yeah, I can repeat the question. Yeah, so the question is how do we deal

with bugs in the tools? I mean, the tools we introduced are open source software. So in the end, it comes to like reporting it or like in nine out of 10 cases, just like finding like the actual issue already open on GitHub. So in the end, it's just like keeping up

with the major updates and having a close look at the bug tracker, it's probably all I can do. I mean, what would you say? Yeah, and finding workarounds. So whenever there's a bug and you need this feature, you still want to have the tool around,

yeah, have a work around. So I, for myself, have plenty of workarounds for different bugs that will be fixed later on and you have just a work around, it's like any other software, right? So in the end, there's no silver bullet to deal with bugs. But I don't think it's a good option to just abandon the tool because it's a bug inside.

You have, yeah, see is the tool actively development and active development, other responses on the mailing list and the bug trackers and stuff like that. And if not, yeah, think about changing the tool. But if there are issues addressed, find a way to work around it till the next release,

I guess. More questions? All right, then, yeah, thank you. Bye bye.