 Hello everybody, my name is Andrey Yorkevich and I'm with Alturas. Thank you for choosing my boring topic. We'll not speak about any fancy stuff like LEDs, like Diego, about microservices. We'll speak about numbers. But numbers are positive. We'll measure benefits today. Unfortunately, Mike Jacoby, who was advertised as a co-speaker, was unable to join me today on the stage. But I promise you my best effort to deliver this presentation and deliver the content that you've chosen to hear. So, let's start with a traditional survey. Show me a hand who didn't hear this phrase before. Okay, nobody. My next question. Who agrees with this principle? Who does agree? Okay, just half of that in this. Okay, interesting. And show me the hand who regularly uses this principle in your professional life. Okay, nice. Unfortunately, fewer people. And then I understand why. Using metrics is challenging. It's not something that we urge to do, urge to do, that we have to do. It's something that is important, but not mandatory urgent. So, we prefer to procrastinate. I hope that my presentation today will help you using the metrics in your cloud-friendly implementation. And my last question to you. Who of you is starting cloud-friendly implementation or thinking about implementation in the near future? Okay, nice. Yeah, so it's for you and why do we need metrics? Universal answer is that we need metrics to take decisions. And in Cloud Foundry case, I assume that you are champions of Cloud Foundry. And since you are here, you already sold or already sold on the idea of Cloud Foundry. And you took your decision. You are already interested in that. However, you may be not sure about implementing Cloud Foundry in your organization. And you need to understand why exactly you need Cloud Foundry. What goals you have. You also need to understand your alternatives. And metrics will help you as a champion to convince people around you who work with you, who work, whom you report. Maybe you manage people and you also need to convince them that it's the right thing to do. Maybe not. Maybe it will appear that it's not the right thing to do and you need to do something else. But again, you will have an answer. So we need to go in some other direction. Also, metrics will help us track our progress, where we go, how fast we go and get feedback whether we are approaching our destination point or we are moving maybe in some wrong direction. And I represent Altorus Professional Services Company and why we came up with this metrics. We work with companies on different stages of Cloud Foundry adoption. We work on trainings. We help implement Cloud Foundry and we help adopt Cloud Foundry. And this is exactly what I was telling to you about the Champions Challenge and the Champions Dilemma is that quite often people who are convinced about technology, who are passionate about it, they are struggling to promote it to their colleagues and I suggested this topic for the summit and it was accepted. So it's based on my real experience of dealing with different customers. And it's our location, it's our customers, so normal marketing. This is my version of why we need Cloud Foundry. You probably have your own version, maybe you saw some presentations and most likely other speakers were suggesting other reasons why Cloud Foundry should be used. My version is that the major, major advantage is decreasing time to production. You have faster application on the market. Also you can iterate faster and it's clear. You can increase productivity of developers. A lot of features that are already embedded into the platform have not to be developed because they are already in a platform. It's also obvious. Cloud Foundry also helps to improve quality of the products that you develop, primarily in terms of latency, low latency, high availability and high security. Efficiency of operations is also clear. High level automation, utilization of hardware also could be quite essential for some companies. In my practice I also faced other reasons why companies have chosen Cloud Foundry for the IT departments, for the enterprises, like for instance, unity of environments across multiple locations. For some companies, especially in the regulated industry, it's very important because they don't have to certify each new location. In your case it may be somewhat different. Now the question that you need to ask yourself is why exactly do I need Cloud Foundry? What exactly are my goals? It could be all of them. It could be two or three of these items. It could be something different. But you need to answer the question. Why do I need that? Another important question to ask yourself is what are my alternatives? What are the other ways that I can choose? What are the other paths that I can go? Maybe I will be happy with the infrastructure service. Maybe it's the way to go or maybe I can have capacity and desire to build some custom platform. Maybe I just don't need to choose anything and my situation is not that bad and probably going into some radical change and radical shift in my organization is not the way to go. So we need to understand what alternatives are. The next step is to identify how much money, how much it will cost to us in terms of time, in terms of money, in terms of effort. Also infrastructure is clear. We need infrastructure to run applications. Also Cloud Foundry doesn't come for free and it has several components that are basically an overhead in the system like Router, like Blobstore, like Cloud Controller. That's all the components that we need to keep in mind and understand that Cloud Foundry will be my applications plus something else, there is an overhead. We need software acquired or taken from a third party. We need to develop several tools on our platform like automated scalability, maybe security framework, maybe authentication framework. But if we have a platform, it makes sense for us to integrate several components that we will have to create in all our applications into the platform level. Integration work clear. Infrastructure and software support also clear. Our people need to be trained. And probably the most important investment item is cultural change, as Angel Diaz told in the keynote yesterday, that platform without culture is toxic. So, very good phrase, which I like a lot. And you will have to spend time, money to train your people to evangelize your platform to make sure that your people really create cloud-native applications that you invest into the culture of creating microservices, agile culture. So, you don't deploy Cloud Foundry just because you're fine. And all the way we are human and we understand that humans don't like change and we have to do this change. And we need to spend our time, money, effort in it. So, the next stage is we know how much it will cost to implement it. We know how much it will cost to support us and our vendors will help to understand how much it will take to purchase software, to buy professional services, to allocate our internal people, to implement the platform and support it. And the right pane of scale is filled with some amount of money. And now we will balance the scales and fill in the next and the other pane. Provisally, when I listed the benefits of Cloud Foundry, the first one was decreased time production and we will try to calculate how much time to production is worth of. So, it's now time to do the math. Now, formally simple, our effect will be time savings, multiply on cost of delay and the number of applications that we have. Cost of delay would be an amount of money that we earn or save if we had the application running already in production and let's say in our case it will be 2000 bucks a day. It may be a lot, maybe not too much depending on the size of the organization, but I think it's about to be true. Like for organization of a decent size, cost of and benefit of having application up and running could be something like 2000 a day. Let's say we have 20 applications. In our department we are going to develop 20 applications within the next year or year and a half. So, we need to calculate time savings. How are we going to do this? Let's say we have a value stream map to assess this timeline and one of the major components of starting a project is provisioning of the infrastructure. This map is relatively simple. It has just four stages. In most cases, for most enterprises, there will be much more than these four stages. There could be 15 or 20 or 30. The bigger the organization, the longer is the chain. The most important time that is being spent on this provision of the infrastructure is not the time that we do the work, actually. It's a lead time. How much time is spent when task is being hand-over between one specialist and another specialist. In our cases, let's say hardware is provisioned within three hours, but it's being queued for three days. IP address allocation took two hours, but again after it's provisioned, it could be hand-over to another specialist and this task will be waiting for two days to implement it. In my example, let's say it takes 10 days to provision the infrastructure. What do you think? Is it optimistic or pessimistic? I think at the time I'm a bit optimistic, but let's use this number for our calculations. Besides provisioning, there are other aspects of time-to-production savings. Besides provisioning the infrastructure, we will save time on developers, on developers setting up the environment. Also, let's assume we'll have four releases per day and in our case, it could take three days in the old-fashioned way of doing the release in Cloud Foundry to which we are much less. Also, a very interesting aspect is developers' productivity. As I said in the beginning, the platform already has several functions embedded, so developers don't have to spend time on developing these features. Let's say in my case, we have 29 days of savings before our application is being first released to production. What does it mean? It's over a million for 20 applications. I don't know, maybe it's not too much, maybe too much depending on the scale of the organization. I assume that the bigger organization is, the longer it will take to provision infrastructure. The higher will be cost of delay for applications, not being running, and the number application could be bigger. Using this approach, we can calculate what is the value of time-to-production and how we can justify the usage of Cloud Foundry just in one aspect. Let's take another example. We have a smaller organization, and the number of applications is lower. The cost of delay is also lower, and the organization is not so bureaucratic, and it takes less time to provision infrastructure, and the savings are not 30 days, but just 10 days. In this case, it's not so much. In this case, it's not that valuable, and we probably better consider other options or don't do the change at all if time-to-market is the only benefit that we're targeting. I won't stop on all the benefits, and I won't do all the math and make the total business case, but I would just like to share some ideas, some approaches, what could be measured to how benefits can be measured and how they could be converted into money, into actual savings. Besides, we already use developers' productivity in our previous example, and developers' productivity helps us save time-to-market and have our application delivered to production faster. However, there is another phase to it that developers don't spend that time, they don't get salary on these features, so there's another savings for our organization. For high availability, we can use percentage of availability, number of incidents, and we can convert it into dollar value with the cost of downtime and the cost of customer acquisition, assuming that some of our customers will just leave. If the service isn't stable, for service quality, also we can connect to customers, customers' lifetime and revenue per customer, how much customer gives to our organization during its lifespan, his or her lifespan. With operational efficiency, we can link to the amount of time that is being spent on supporting the maintenance of our system and production of our platform. Also conversion to dollars is a salary, also clear. Hard utilization is percentage of RAM being used at the cost of RAM, and if we use, let's say, such a metric as avoidance of infrastructure or service like you look in, we can use time and salary professional services that we don't have, that we may spend to migrate to another platform. How much we are anchored to this specific infrastructure and how much it will cost for us to go somewhere else. Besides that, my dear champions, you may use additional benefits that could be monetized and quantified, could not be monetized or quantified, but you may expect that with the properly functioning platform you will have more satisfied developer customers. Also quite important could be lower management overhead and also lower barrier to initiate new projects. Again, if you didn't justify the values and your expenses into the platform before with the metrics that we used on our previous slide, then you can dig into these metrics or utilize your own goals and your own benefits. And let's say we calculated 10 million potential of Cloud Foundry usage, Cloud Foundry utilization. And if nobody uses it, we can calculate the effect. And I'm suggesting to use another dimension of metrics which are adoption metrics to see how much actually your organization is utilizing the platform in terms of applications that are being hosted. So these are some examples of metrics that you can use to track the adoption with the increase of adoption. You will increase the value of the platform for your company, your organization. And we are working in software development industry and there are agile methodologies that tell us how to develop our software. And we may apply this scientific method or lean approach into our organization and to iterate, move to our goal, see how we achieve our metrics and how we achieve our goals. And as a summary, we're close to the end of my presentation in order to convince and to be successful in Cloud Foundry implementation. I suggest that the champions of Cloud Foundry should understand the goals, identify metrics, be clear about what they want to achieve and what's achievable, assess possible results and if the results are satisfactory, if it's worth of pursuing these goals and just to act, you take your decision and you act on them. Now, also having metrics helps us to track the progress, to get a proof of success. And we need to understand that it just doesn't come for free and we need to iterate, to change culture, to convince people around us and to be the leaders. Thank you. Questions? Okay, do we have questions? Yeah, very good question. Actually, I would suggest to use the metrics that are objective to utilize the actual processes that the organization is utilizing and try to identify the hidden processes, what we didn't calculate, what we do, and to be as objective as possible. The number of applications? No, I get the number back. Okay, we have... In my equation, you have three elements. It's cost of delay. It's money metric. Then cost of delay per day. And so we have to multiply it by number of days and also number of applications. Did I address a question? Okay. Other questions? Yeah, thanks again.