 Hi allon, I think, I'll start So, good afternoon, it's been a great day so far Thank you very much for taking your time out to come and join us For our presentation As the title implies We've been delivering Cloud Foundry now for just about five years To deliver What we believe that to be world class but certainly business critical a we will explain a little bit more as we go through. But we thought we would use this opportunity to share some of what we have learnt along the way. So, I hope you enjoy it or we hope you enjoy it. Do you want to introduce yourself? My name is Tim Savage. I am the CEO and founder, one of the founders anyway, I've got a background in various areas of technology spanning over the last 20 years, embarrassingly, and accommodated in forming Armacony, which is a consultancy we've formed in 2012. I'm a recent addition to the team. I'm extremely excited to be here and extremely excited to be a part of the Armacony world. I come from a world of tradition and problems and legacy IT, so when I met Tim a little while back and he introduced me to Cloud Foundry and actually showed me an agile pipeline, I was like wow, bowled over, absolutely bought him from that day forward and then conversations evolved. And I find myself talking to you guys now. I've been immersed in this, I suppose, for the past four or five months, but not much more. So I'm here really to introduce you, I guess, to my thoughts turning around trying to employ what is amazing technology in a world where people may not be quite as excited and may see it more as a threat on an issue. So more of a business perspective. I used to be a technologist, so I do have a background in technology, but that was some time ago. And now I focus around helping larger organisations improve the way they work. So a little bit about what or who Armacony is. Software development, the way it should be done. That's a very nice quote from one of our customers. And something that we think is what we try to achieve. So we specialise in cloud native software development and our mission now really is to support organisations doing things better, right? So on the journey to this amazing place that is cloud native and supported by Cloud Foundry. So removing all the bottlenecks. How do we do it? We either do it for them, our customers, or we help them do it for themselves. So it's either we give them the fish or we teach them how to fish. And we've worked with a number of organisations. And this presentation is our learnings from a number of organisations that we've worked with, both big and small, green field and some not so green. I think we have to appreciate that about 80% of the world is steeped in legacy, one part or another. So we've got some experience there with migrating and more brownfield projects. But we'd like to think of ourselves and I think we are one of the UK's leading independent Cloud Foundry experts. But it's not only if we've been using Cloud Foundry for five years, which is more than most people even know existed, I think. But also we use the open source version and we've worked with Pivotal and we've worked with IBM. So we've got quite a broad range of experience. This is ultimately I think what we try to give our customers, right? And this is what it's all about. It's freedom to innovate. It's about putting the business value at the centre. And to take out all the bottlenecks and remove all of the issues that people see about getting production ready code into production without all the pain that people seem to expect of today's technology world. So it's about putting the customer and business value at the centre of everything. So we are here to give back and just talk through some of what we've learnt along the way. But first I think it's important to give you a little bit of context. Tim will take you through a case study and briefly spend five, ten minutes just taking through a case study of how we've delivered one business critical app for comic relief and then we'll go on to some of the learnings that have come as a result of that. Thanks Ben. So this is something we've talked about before. You know some people might be familiar with some aspects of it but a lot of people probably won't be. One of our clients is Comet Relief, a UK charity. They were set up in 1985 and they have a mission statement which is a just world free from poverty. They're famous for the Red Nose Day campaign which I imagine a lot of people will be familiar with. It's a big campaign which culminates in a telethon. They've raised in excess of a billion pounds sterling over their lifetime and each individual campaign these days will raise sort of somewhere in the region of 100 odd million pounds. So it's big numbers. The telethons when they happen they take over the BBC so BBC One will be nothing but the telethon from 7 till 2 in the morning. They occasionally have a break for the news. It happens some years, not another years but very much the UK public is immersed in these events and it's pretty hard to avoid them generally unless people make a concerted effort. The audience will be in the region of 20 million, it goes over the evening but we are sort of prime time TV at that point in time. And Armacuni have built and run the platform that takes all of the car payments for these events so we cover web, mobile and anything through the call centres. So to give you some rough numbers, it's seven hours long. We have to cope with in the region of 400 payments per second. That's the metric which we build for to be able to handle. Those are live customer payments. To give you some context on the 400, the UK as a whole averages at 360 transactions a second for car payments for absolutely everything. So that's to give you a sort of scale of what 400 is in terms of national levels. We expect somewhere in the region of 100,000 concurrent public web users. We also have 14,000 call centre operators that will be logged in and using an application and working constantly taking donations as the calls come in. And we expect somewhere in the region of 800,000 transactions during the evening. So that's our sort of scale. So to summarise the challenge, we have no second chance, we run for one night. Once a year, seven hours, we take tens of millions of pounds and we can't fail. There is no option. People don't come back the next day and want to donate their emotional at the time. They're not buying a TV and they'll get it from the next store or whatever. It doesn't happen. So we have that one chance. So they've been running it for, the organisation has been running for 25 years and before us they had a platform. They've been doing it for 25 years. Before we came along it was a Java monolith that was the platform that was running this whole thing. It had evolved over nine years I think and was largely a black box in terms of what it did. Testing was entirely manual at all levels. So it's very limited. There were masses of potential for human error, big gaps. Deployment was manual. I remember regular shouts along the lines of the new JavaScript files are on half the servers and not the rest, all sorts of things and issues that we had to solve at the time. They had single points of failure. So infrastructure providers, platforms, bandwidth, payment providers, all of these things were single points of failure that at any point in time could and did go wrong. Also to pull the event together there was a very complex matrix of providers. So lots of organisations got involved. We had somewhere in the region of between 40 and 50 people coming together to make this event happen. But they're all partners and big organisations sort of pulling their resources together. After a while that started to fall apart. The partners were starting to compete and they all wanted different involvement levels. Originally they all had their own little areas and they started crossing over and going up and down the stack in terms of what they delivered as an organisation. Also in terms of the testing it was largely a one year feedback cycle. So we take the learnings from one event, work on them during the year and then apply them the next year. And that was literally the cycle. So this is our solution. We took a Java monolith and turned it into a sort of microservices architecture. I'm using this slide that was used by Gartner in the Catalyst conference two weeks ago I think it was. This was used to illustrate best practice multi cloud. We took the black box monolith and turned it into a sort of microservices architecture. Within this what you can see here is sort of the multi cloud deployment but there are 28 microservices in there that are running the whole thing. It's distributed across multiple infrastructure service providers and multiple continents. So it's quite truly multi cloud. We took the enterprise relational database and turned it into distributed data stores using eventual consistency and event sourced architecture. We took the lack of confidence and turned tested and development, BDD and a full suite of automated tests to get to a point where we could then put in place full continuous deployment. Everything now is as code, all automated. As you can see every change gets pushed and will go all the way through into production. So what was once a one year feedback cycle is now 50 times a day when we're working on it actively. So now developers can make changes with confidence. We took high spec hardware, moved to infrastructure as a service underneath the PAS layer. We took limited scalability and turned it into sort of unlimited horizontal scalability. And we took the partner list from down to one team. So it's now four people that built, five built it, four run it. And that's how it's run for the last few years. Everything's as code, apps infrastructure pipeline. And I guess, yeah, the sort of end result of all that everything is code. So that's where the knowledge is. All of it's contained within the code. There's no sideline knowledge, you know, sort of key man dependency or anything along those lines. So the result for the business, so far, it's been a total success. 90% reduction in team size. We've run four events over the last five years and processed millions of transactions. Although surprisingly it's only actually been doing its job for 28 hours over that period of time, which is weird when you put it in those terms. Yeah, it's an equivalent of five million pounds worth of savings in terms of the cost that the organisation has to bear. And we're now in a situation where we can push the entire thing and we push changes to production in 15 minutes. So we've been able to push changes during an event whilst taking up to 100 transactions a second. We can push changes into production. So what have you learned? That's a good question. OK, so that gives you some sort of idea. It's to put it into context, to give you a little bit of background in terms of one of the projects that we've worked on. That was more Greenfield moving from a Java monolith over to having carte blanche over the architecture. And the key decisions that we made to run with Cloud Foundry five years ago has proven to be the right decision. I think there are a lot of options at the time, but we decided that that was right for us. And we've stood to tell the tale. So what have we learned? So there's lots of things that we have learned. I need my glasses wherever they may be, because I'm getting old and I can't actually read anymore. So I suppose the most important thing that we've learned is that everyone can benefit from Cloud Foundry. There is not an application or an instance where we believe that Cloud Foundry cannot be deployed. There is one we've spoken with and we continue to talk with a client that is actually running high frequency applications, high frequency trading. And we're looking at ways that we can utilise Cloud Foundry to benefit them in a way that will still service a lot of their needs and introduce some sort of improvements in the way they work. But what's important is that whether you're big or small, whether you're a startup, whether you're a traditional, whether you've got legacy, whether you've got a Greenfield site, there is always a way that you can employ Cloud Foundry. But Cloud Foundry and Cloud Native is a big shift for some. Culture, industry does not necessarily allow the widespread adoption. So a lot of people over the next couple of days, you would have heard some already and you'll hear some more, no doubt, will be evangelising Cloud Foundry. And so they should, right? It's an amazing piece of technology is absolutely fundamental in terms of and has the ability to change the world. And we all believe in that, right? We're all sat in this room and we're all around this conference because we believe that Cloud Foundry has the ability to fundamentally change the way IT is delivered. I'm prone to getting on my soapbox, but the problem that we have as a community and as a platform is the success that Cloud Foundry has. And one of the key learnings that we have is its ability to be consumed within an organisation without giving the organisation any suggestion. So the adoption has to be specific to your organisation. There are different people that play a very significant part in Cloud Foundry's adoption and the move to Cloud Native. Now we had a very interesting conversation at the unconferenced last night where we were talking about different points of resistance. And it's really interesting to hear different views, whether it's the developers which seem to be very much split halfway down the middle. Some see it as this exciting opportunity to improve the way they work and genuinely take more control. Others are born to inertia and actually see it more as a threat because they're having to relearn a lot of the stuff that they've taken for granted. They're in a position of power and they don't really see it as a benefit. They see it more of a threat. You've got the DevOps and the infrastructure teams that some people think that they are used to picking up new systems as you go. So therefore it's just a new platform, it's a new product which they have to pick up and they're expected to deploy. Great and they don't have a problem. Others feel that it's a massive threat and that they're about to, it's a bit like selling Christmas to turkeys. It doesn't work. So adoption has to be specific to your organisation and it has to be balanced. There is this purist view where Cloud Foundry comes as a bigger package where it is Cloud Foundry, Cloud Native, 12 for Actors and Apps, Microservice Architecture can't be used for legacy, can't be used for, everything has to be moved over to this way of working. And then there's the more pragmatic approach which is an actual fact. I had a very interesting conversation last night about how Cloud Foundry can be deployed and you can build infrastructure services and almost, not quite as easy as being completely transparent or completely hidden from the developers and from parts of the organisation that may actually push back on it. But you can actually deploy it in a way that, more softly, softly. So you're actually building this wave without even people realising it by employing Cloud Foundry. And then when people, when you're presenting this new way of working, people are like, well, I don't like that, it's never going to work. But you've been using it for six months and you don't even really know it. So all these subtle changes that we've made to the way that you work. So the most important thing or one of the most important things that we've learnt and we continue to learn is that adoption of Cloud Foundry and ultimate success is dependent on the individual drivers within the organisation. To be able to appreciate that sometimes the cultural shift is too much. When you've got five, seven and a half thousand developers across multiple geographies and they've been stuck in the world of delivering waterfall and they've been reliant on massive test cycles to be able to take away this need for them to actually write good code, then you're going to struggle to actually employ Cloud Foundry in a way that you perhaps want to. And I think as, you know, we're all here, right? Because we all want to see Cloud Foundry adopted and we all see it as beneficial to us. So it's important that we look at the ways that we can influence management, develop other developers, our peers to be able to improve its adoption in a way that best befits our organisation. So this purest view sometimes you'll just be banging your head against brick wall and it hurts. So sometimes it's more pragmatic approach. So moving on from that perhaps certainly one of the, one of if not the singularly most important benefit of Cloud Foundry in our five years experience is that it creates a single contract. So if you imagine, so we were talking about this the other day and we've been using Cloud Foundry for five years. And within that five years we have used Cloud Foundry as a platform as a service. And if we hadn't chosen Cloud Foundry and we'd chosen to use a different technology, whether it was building our own custom paths as a lot of organisations have done, or we've chosen another route, we reckon that we would have done things three times over. There's the technology chance. So we would have had to continually update our custom paths or the technologies that we were using as these technologies either became redundant or they evolved. And still there are organisations that are pushing back on the adoption of something like Cloud Foundry as an industry standard, open source, de facto paths to use. Because they have invested a lot of time and effort in their own custom paths and they have these massive teams that have built it and that blood, sweat and tears have gone into these things. But every time that there is a new technology, every time there is a change, they have to invest time and effort to improve that. Cloud Foundry does it, right? They've got a bunch of developers and a bunch of technologies that are doing it for you. So every time that you're, and it's transparent to you, you just roll out the next version. We heard Sam earlier saying about all the new features that they're bringing out. It's got everybody firmly on-site in developing its functionality. But it's the single contract. So for us as developers it doesn't matter, right? We're just using Cloud Foundry. That's incredible. The other thing, of course, is it removes the need to retrain your team. So if you're using Cloud Foundry, then it's a consistent contract. There is CF push, right? And everything that goes around Cloud Foundry, you're not having to train them on different. So you train them on one platform and then you decide for whatever reason that you're going to upgrade or you're going to throw that out and get in something else. So you have to retrain. But also from a developer's point of view, if you're learning Cloud Foundry and you're actually competent and expert in Cloud Foundry, then you're opening up a whole huge opportunity in terms of the roles that you can perform. And the other thing is, of course, for us is we reckon we would have had to rebuild several of our apps, several of our software platforms, once if not twice in the past five years, as our customers have fallen out with their infrastructure providers and turned around and said, actually, we need to move. So we can't use them anymore because we don't like what they're charging us or what they're charging us or we're just unhappy with the level of service and we want to move over there. Now, we haven't had to do a great deal of work about redesigning or recoding to utilise the specific services that IaaS provider are offering. So we've not got, okay, but that doesn't mean that you're unable to leverage the platform specific or the IaaS specific services. So that is perhaps one of the biggest benefits and one of the most important learnings that we've had. Very fortunate in our decision to run with Cloud Foundry, but one of the magnificent benefits that we've received. I'm going to hand over to Tim now just to talk about what else we've learnt because there's been some more learnings about how you know you're on the right track in terms of your cloud native journey. Right, so I'm conscious of time as well, so I'll make this fairly quick. So this is all about the cloud native journey and how organisations are adopting or getting involved. You might be sort of thinking about Cloud Foundry, a whole bunch of things, but what we're trying to do here is this is a list of pointers as to, in this case, you might be losing the way, the cloud native way when, there's a lot of them. The Pares is the IaaS. You're directly dependent on IaaS offerings. The collaboration contract, so that single contract we were just talking about, that contract is broken. So when you've got your developers, the people adding value, if they aren't pushing directly or using a CI or something, then you're in that position where you've got a silo. Component cost is more important than developer cost. So we hear people that are talking about the efficiencies they can get from moving down from X to Y in terms of the machine size or the performance or whatever. What's actually the bigger cost is the amount of time these guys are spending doing it or the amount of time that's involved in the developer cost, the true cost of ownership, and that's never really appreciated or looked at. Complexity isn't adding value. So the complexity that you're adding in, and it is a complexity, put it sort of going into a Pares and microservice architecture, that is some complexity you're adding, you should then be able to iterate and add value on top of that. If you're not, you're losing your way. Developers aren't empowered. It sort of relates back to point two, but the further you move away from a self-service model, the more velocity and empathy is reduced. Apps aren't 12-factor. I think everyone knows about 12-factor and so on, so I think that speaks for itself. Tooling is deeply abstracted or version-specific. So we've seen scenarios where the tooling has got so complex to allow a push or to allow environments to build to happen or a whole complex chain of events to have to happen for something to get into production that you sort of stepped away from the path of the simplicity that you should have in terms of how you get applications into production. Forking Cloud Foundry, I think that speaks for itself. We've seen it. You expect Pares to behave like ours. This is where you sort of, you expect the instant access to the sweetie shop that IS is. There's no process to get existing staff to transition, so I think this has been a topic for quite a lot of talks today around that not being part of the process. And when Cloud Foundry is a solution, not an enabler, so I think somebody mentioned earlier, Cloud Foundry delivers zero user value. It delivers nothing. It enables you, it isn't the solution. So if it is the solution, it's being talked about as a solution, as it's solving the problem, you're losing your way. And you solve problems with version numbers, not patterns. So this is where people are talking about waiting for X or Y version because that will solve all your problems. If that's the world you're in, then things are going wrong. So you should floor it when, and this is when you're on the right path, you're architecture is Cloud Native. You can do small, quick iterative developments. You've got multiple teams working on multiple components. They're all working to contracts between each other. You can progress and you can add value quickly. The apps are easy to deploy. So the 12 factor apps, they get their config from the environment. A whole bunch of things that I imagine people here either know about or will learn about. Your apps can be automatically tested. So you can't get to this world of continuous deployment and continuous integration without thoroughly tested environments. And as much as we practice it and we see it, but we're constantly improving it and progressing it. Insight and logging are designed by the application developers. So migrating from a self-build infrastructure as a service environment to PAS often means that a lot of the insight you have before will be lost and needs to be, you'll get some from the PAS, Cloud Foundry gives you some insight, but you need to build in business-level metrics. How long are your applications taking? All the stuff you need to understand what's going on. Either at the application level or sometimes build-packy level. Your business differentiator is not platform dependent. So this is true for a lot of use cases, even though businesses maintain their special snowflakes. But sometimes it's not. So example the super low latency trading platform that Ben was talking about earlier. And your business process is agile too. So often go live and releases are entirely blocked by internal regulation compliance, a whole bunch of processes that are entirely non-agile. And that's something you need to be agile. And if that is, if you've bought them with you and taken them on your journey, you are on the cloud-native journey. So thank you very much. Our information is up there. We are hiring. So if anyone's looking for new work, give us a shout. Thank you very much. I think the first point on this big list of things not to do was doing your own IAS or having mixed with the PAS. Do you separate in size or is the general don't do it ever? In other words, when is it appropriate to run your own PAS on the IAS at the same time? The point that I was making was more that whatever you're calling your PAS is utterly dependent on something that's very infrastructure IAS specific. So, for example, you're using an AWS component that is specific to AWS. You're not in a position where you can be portable. You can't go multi-cloud. You haven't got any of that flexibility. So that was the point I was making. Does that answer your, sort of does not answer your question. But yeah. At the time, OpenShift existed, and there was quite a lot of work going on there. So we did evaluate it at the time. We spent quite a bit of time working with both, and we eventually decided on Cloud Foundry. A choice I'm glad we made now. I couldn't actually, because I was working with Cloud Foundry. I was working with Cloud Foundry. I was working with Cloud Foundry. I was working with Cloud Foundry. I couldn't actually, because I wasn't involved in that decision. I was on the other team. I could find out for you if you want to give you the reasons. Although it's probably now very out of date. Any others? Nope. I think the next talk is quite soon. I don't think it's a big gap. I'll drop out. All right. Thank you very much everyone.