 So, hello and welcome. I'm Daniel. Before I start with my talk about how Tarlangs went to Cloud Foundry, I want to ask you, who's here and has not just implemented Cloud Foundry? Who's here just at the very beginning of this journey? Is there anyone? Awesome. Exactly one year ago, I was here as an attendee together with a few colleagues from Tarlangs. And we were like, oh, this is Cloud Foundry. That must be amazing. Or can we even handle that? And now I'm here. So the good news is, yes, it works like all the promises, like all the ambitious promises. You can bring it to your enterprise. It will change everything. And you will just deploy, deploy, deploy. Yeah, that's true. So about Tarlangs Group. Tarlangs Group is an international insurance company. We have a strong Germans route. Our headquarters is located in Hanover, Germany. There are a lot of interesting facts and figures about Tarlangs. I don't want to show you in detail because we are actually here for Cloud Foundry. Myself, I'm employed at Tarlangs at the Digital Lab. That's a small branch of Tarlangs within a subsidiary. We do all the new agile stuff, bringing new methodologies to the enterprise, using new technology, stuff like this. OK, about me. I'm in IT industry now for quite a few years. My first computer was a C64. This was like deploying with floppy disks and stuff like this and took several hours to copy one. I work at Tarlangs not that long ago. Actually, I started also in 2017 at Tarlangs just to begin this great journey with Cloud Foundry. You can find me on LinkedIn, GitHub, and Xing and all this social media stuff you already know. One interesting fact is this is actually our headquarter in Hanover. And the amazing thing about Tarlangs is right behind the headquarter, there's an actual pony farm. Yes, you can look out the window and there are ponies. So what an amazing place. OK, so that's basically how an insurance company sees software development, a large, majestic waterfall. They are very good at waterfall software development because they can make choices, make decisions based on well-known facts. They can plan ahead for years like software application, lifecycle management, and all these fancy things, and enterprise architecture management. Oh, god, we got so many enterprise architecture management. And it worked for some decades quite well for Tarlangs and also for an insurance industry. Or actually for the most industries was waterfall development and planning years ahead. It was quite good. But now things change, markets change, economies change. We are about what if we actually don't know what new products we can bring on the market and what will our customers accept for products? Can we just develop three years and then see, oh, the market does not accept a product and we dump it? That would a waste of money. So we have to transition. Transition to something more like this one. And yeah, it looks a bit fancy, but actually these loops, these close feedback loops, that's something quite new to the software industry. But for some big companies, it's still uncommon to go this way to say, OK, let's do not plan the whole process, the whole software applications. They could just say, bring out an MVP. Bring some small pieces out of the market. Let's see how the market reacts on this product. Maybe you don't have all the fancy buttons and functionalities, but you at least get a glimpse of the general, the very basic idea of your product is a success. And then you can advance over from this. You can start, OK, take the learnings of it. What was good, what was bad? To be a bit more formal on this and go to my beloved Talang's PowerPoint master slides. Yes, basically it's all about build, measure, and learn. Build some small piece of software. Measure how your customers interact with it. Take some learnings and build again. And don't do this in like, OK, this year we will build software, and next year we will learn from it. And maybe in 2025, we will build the version two of the software. But just to go for weeks, for months, that's quite an achievement for some big companies. And as a digital lab of Talang's, there were some prerequisites we needed. Like, what do we need to get into these small feedback loops? And OK, it's a bit overambitious, or three counterstones of success. But basically, two important pieces mattered. Some agile methodology, some software stack we can use for rapid development, and also some flexible infrastructure that can handle our changing requirements for the software. So because we did not plan, OK, we will use this and this and that framework, and we will need a caching layer or something. Because at the beginning of our product, we didn't even know that we need caching, because at the beginning, no one was buying it. So we had to change our product. And then we say, oh, no, no, it goes like a rocket. Sky high. And I want to give you some insights on these three parts that we established at Talang's. And a spoiler head, the flexible infrastructure one that will be the one where CloudFirmary comes into account. So we decided actually to go for Scrum, classic Scrum. Can you say classic Scrum today already? Can you say that Scrum is already a classic one? But besides that, yeah, we get to buy weekly iterations. We did plannings. We did reviews. We did retrospectives. We did dailies. All the stuff, basically, from the Scrum books. We had a dedicated product owner that was very helpful for us to get all the business aspects, canalize them into user stories. We did the planning poker on the store. So we did not go for, OK, this will take five days. No, we really did this planning poker stuff and made some estimations. And that quite worked, because our learnings from that Scrum was no free lunch, especially in big water for the company. Because everyone we had to interact with, we need to convince that that is a good idea, because most people just said, oh, Scrum, that's cool. That means just chaos. And he said, no. That means to be very precise about meeting times. Even meeting starts at five past something. It starts at five past, not six past, not eight past, or not showing up at all. That was quite hard for us. Thinking in MVPs was challenging, because our product, they also had a big vision, oh, big portals everywhere, big portals, big integration of all our products. We said, no, no, just go for what can we deliver within a few weeks a customer will buy? And then go from there. But besides that, the business side actually really adopted well to the agile and methodology. And they had a lot of fun with the reviews, with the plannings. And that was quite surprising for me, as I was completely new to insurance companies. And I thought, oh, my god, they are all so old and so established. But even they can change very fast. The last point, self-organization. No one told us to use Scrum. They just told us, develop a software within two months. It has to be done, no matter what. And we decided on ourself to go, Scrum. We decided on ourself to watch the technologies to use, and how to deploy the software. And actually, that worked pretty well. The next one, our technology stack. So we are a company that has mostly based on J2EE and WebSphere. And as we were quite new to enterprise software development and also to insurance, and we thought, OK, we have to be very rapid in development. That was no option for us. So we took a new stack. We went for Angular for the front-end. So it just gives you everything you need to build a nice application that's responsive, that works on almost any browsers, and just have to basically just to color it. Take your corporate brand colors, paint it, and then you are good to go. We went for Spring Boot. Spring Boot, that's the most important thing that helped us to go into rapid development. Just use Spring Initializer, create a new project, put a few models in there, a few controller methods, and you're good to go and you have your back end, at least at the beginning. Also, we used Lomborg because we did not want it to write all the getter, setter tests, and all this. We just got for Lomborg and had some like a value object. Swagger, are there any developers in here? Or just wasting your time. Yes, developers, awesome. I'm a developer too. So we used Swagger, not because we wanted to print some nice documentation of our APIs, but we had Angular developers and more back-end developers. And to minimize the work, they have to put into, OK, what will this API look like? We just used Swagger and generated the source code, the Angular bindings for the API. And we used integration tests to check that the back end, with every commit, the back end and the front end was working together. That was quite an achievement for us because then we had not to worry about anything like this. Like, oh, yeah, we developed something, you developed something, and yeah, it does not match. We used Spock. Spock is a testing framework. We did not go for JUnit. So we went for Spock, and you write the tests in a more declarative way. You can write data tables. You can write in and given when that syntax. So when you write like Spock tests, you can actually use this test, give them to the business side, and say, OK, let's talk about quote calculation. You gave me your lovely Excel sheet. I wrote this test. Are they correct? They just can go to the Excel, and everyone is successful. You are actually making the right quotes. Because if you go for industry insurances, actually 10% more or less that really matters, that are very big numbers you are working with. A GitLab. We did not went for our company S4N or something. We just went into a cloud with GitLab. We used GitLab as a source code repository. We used merge requests. We used some policies that every merge request has to be reviewed by another developer, but also the complete pipelining. So every commit, trigger the pipeline, and all tests were executed. So every developer got immediate feedback. Oh, I broke something at the API. Or I broke something at the calculations. So there was no hassles when we were integrating a feature. Like, OK, we did that feature, but it changed the behavior of our application. We were pretty assured that this was not an option. Also, all the deployments went automated through GitLab. All the branching was done by GitLab that gave us quite confident about that our software works at every stage, and we don't have to invest any time in deploying for the business side. Like, oh, OK, I have to deploy it today. Maybe that takes in half a day. No, that was just done by the pipelines. Also, a nice thing about GitLab, but also about the new Jenkins CI, you put all the pipeline declarations in your code. It's not something a different department has to do for you. It was very important for us that we can change our pipeline while our software was also changing and evolving. And last but not least, when we started that, when the moment came that state mattered, really state. Like, I have a customer, and a customer already paid something. We did not go just for the classical CRUD approach and say, yeah, OK, just make some data modeling and create some CRUD repositories because as we worked with MVPs, we did not know how the data structure will look like tomorrow. We were not sure if we modeled today a quote or an insurance policy because our product was not final. It could look different the next day. That's why we began for event sourcing. We said, OK, but we know right now what data is needed for today's quote. Maybe that's some different talk tomorrow, but we just put that into events and got a classic event sourcing with Axon Framework. And with Axon Framework, it helped us to just tomorrow, even if we have all the events, we can just create new read sites out of it, can transform the data, and are good to go. It helped us being very agile up almost to the end of the project. And it also took Flyway for database migrations that was basically drop all the read data tables with the next release and create a new from the events. So all learnings, you need some components or say architecture that should fit like LEGO bricks. You need a big toy box with a lot of LEGO bricks, and you can just put them in for exactly the problem you have right now. Don't go for this is a global framework or something. We had just created this policy for every new project. It just was the right architectural decision for exactly that product we were just working on. CQS and event sourcing was a quite good decision for us as we kept all the data modeling to a very late point in the development phase. Every commit should generate tests and builds. Your source code needs to be tested, and every commit should run into a pipeline build as you can see, OK, it works or not. And automatic deployment on absolutely all stages, including production, keeps you focused on actually developing software and not about running it. Our last thing, the flexible infrastructure. I mentioned earlier that we have a big web sphere on-premise cluster, but that was not an option for us to go to use. So we went to AWS. We already had a department at the company that was quite proficient with AWS. So we just basically gone to ECS. That's the Docker service of Amazon and deployed all software there. We just took RDS for our persistence backend, and you only need a credit card and basically a few clicks, and it's running. We used EC2 for our CI runners because we had to run all the pipeline builds in our own virtual private cloud, connected all this to the internet by all the neat Amazon things you can use, elastic load balancing, VPCs, and what they are called. But there are a few learnings. First, it gave us a head start. We could deliver the first version within a month from scratch. From the business came to us that we need a product. To give a little insight, the product was based on there was a change in Belgium. There was a new law taking an effect that just gave us the opportunity to bring a new insurance to the Belgian market. And we knew that this law will have has just a finite start date. And at that point, you needed this insurance. We actually did not know who will buy this insurance, how much should it cost, what will be the distribution channels. We only knew you have to ensure something new by mid of the last year. So Amazon gave us a head start that was quite awesome. The performance was awesome. Just go with your credit card and say, I need much performance. They charge you more. And it feels like there are unlimited resources at AWS. Maybe there are unlimited resources. I've never been there. It was very effective. Just write a few CloudFormation templates and you're good to go. But also, you have to know what you're doing, because that is completely self-service. It was not just there came five Amazon guys and said, yeah, we are your Amazon buddies. We will help you with all this. It was like just enter your credit card details in that online form. And then you're good to go to click everything together, all the pieces. And with this, it was very effective if I know what I was doing. And I'm just a software developer. I'm not a good ops guy. I'm not a network guy. Actually, I barely know what all this class B, A, C net means. I'm not good at this. And security is a big issue for insurance company. And I have to say, AWS by default is very secure. You don't have to care for the AWS by itself. But every service you consume is only as secure as you configure it. And you have to know how does not gateways work, how does security groups work, how does elastic load balancing work, are my containers isolated, are all these instances, how do I peer my back end? Is it possible that someone break into AWS because I misconfigured it and just hop into my insurance company's back end? That could be a disastrous thing. And with that, with all this, we were not really sure what we are doing, it became very complicated. And we will see that in the next few slides. The development came into install. At some point in the journey, AWS feel a bit like Blackmagic. If you are a great sorcerer, you can do amazing things. But if you're like me, like an Harry Potter apprentice, mostly get your butt burned. So to round up, Scrum was amazing, worked like a charm. Right now, we are about transitioning to extreme programming because we want to even further minimize the overhead in our development process. We have seen that working very well at Pivotal Labs. And we are now trying to give this a run. We want to go to short iterations, not bi-weekly, but weekly iterations. Actually, on Friday, I have an iteration review. And also, we are madly driven by curiosity. Our technology stack was good for the project. Our current project, for example, as it does not rely on state, we are not using Exxon right now. But I think it's every time an individual decision to choose your technologies for the needs you have. To talk about cloud, as I already said, I think we have to go a bit into detail with that. So about the release cycles, that are bi-weekly cycles. Now we are just going to cut them in half to weekly iterations. That does not mean that you get more done. It's just that you can react even quicker. An interesting fact for us was, when we looked into iterations, what we have done in product development and what we have done in operations, it started very operation heavy, like getting all this AWS stuff to work. And then it sunk. Like, OK, now we are developing, we are good to go. And it was also amazing. But every few iterations, all this stuff popped up. Like, I don't know, do you remember Meltdown Inspector? I actually do, because there was this announcement, we had absolutely no idea what to do. We had all this Docker images, libraries, EC2 instances. And the basic idea was, we have to patch everything. That was an iteration where we did not spend a lot of time on actually developing business value. What we identified are this, I think you have heard that already in a lot of talks, this day two operations, like creating Docker images for ECS. Who is the source of the Docker image? Is that all the security stuff? Is this fixed? We have had to patch all the EC2 instances. Are the instances that are hosting the Docker runtime? Are they secure? Integrating new services means to change all our cloud formation stacks. Like, we had one time the problem. We wanted to change our stack to bring a new service in. And it was our persistence stack. And it said, here, maybe, does this delete our RDS instance? Hit all our data loss if it does delete the stack? We did not know. And we started to feel very uncomfortable about this. Because actually, we are just software developers, not infrastructure guys. What you basically want is something like this. I think it's called the value line. Spend the most of your time developing actual business value. And just have a basic flat line about overhead operations, like changing your deployment strategy or something. That was very important for us to come to this flat line. And that's where, actually, CloudFormer kicked in. So how to improve. Deployments should have been even more easier, not with all the stack update cloud formation stuff. And creating like we had our pipeline had to create Docker images with our source code, had to upload them to the AWS Docker registry. We had to run all the cloud formation stack updates. That need to be done. All the network engineering. As I already said, I'm not a network guy. And that network stuff had to be cut out of our equation. Also, Docker images had to be gone. And a way to integrate new apps, new microservice. If you go microservice, you want, at some point, break them even smaller. If you start to get cautious about your cloud formation stacks, then you just say, yeah, maybe we will do this another iteration. Just keep with our micro monolith. And that's actually what CloudFormer gave us. CloudFormer started. We just make now CFPush. You can CFPush almost everything. You can, all the network stuff is just covered behind the CFRP, like the divine service, the service broker API, that makes you all the network stuff. As a developer, you absolutely don't have to care anymore how this works internally. You have this amazing platform that takes care of this. You just build a single jam in your pipeline, make the CFPush command, and it's running. And it really works that way. Also, all the routing, the integration of the application, CloudFormer gave us a very comfortable and easy and lightweight API to just add something to the context path, or to the sub-domain, and integrate our new services. So basically, shift from IIS to PAS was a major achievement of force. So just a few success factors. I'm getting a bit short of time. But if you start to implement it, handle it as a product. It's not something, it's not technical. It's not a project. You have to establish CloudFormer as a product at your place. On the right side, you even see our product logo. We call it our little CloudSheep. Your developers are customers, so go for them. Care for them. Bring features your developers want, not what your architecture board or your management says. And we started with small apps, like small microservices, small applications. But what you need, if you want to be successful, plan for all the legacy stuff, the brownfield migrations, that will be very complicated at the beginning, and it will need much attention. So basically, I'm done. Thank you. If you have questions, I'm short of time, but I will be out of the room, so you can ask me whatever you want. Also, our product manager for the platform is right there sitting. You can ask him how it felt to be responsible for bringing all this magic to talents. Thank you.