 In Japan, I'm definitely keen to discuss with you about worker services, continuous delivery and all things technical. So definitely keen to collaborate with you guys on getting your workloads and applications to the cloud. Now, what I want to begin is with this slide. I like it very much. So the title is Software Is It in the World by Mark Andreessen. It's a statement that he made in 2011. So that was five years' time for all legacy, all big companies to come to a conclusion and to a reality that Software Is actually being eaten in the world. And this picture is the Unicorn Club done by CBS Insights. So these are all the logos of companies that are above $1 billion. So you can see the time when that company reached that valuation. And on the right side, close to today, there's a big cloud of software companies which are disrupting the industry and they are not taking it from the newers. They're actually disrupting it from old legacy companies. Now, I would like to also use a statement by Gartner which mentions that by 2020, there will be 75% of companies who will build software applications rather than by them. And this is a differentiator because you cannot build a brand or a customer experience with off-the-shelf products. You have to engage with your customers. You have to build on those data insights and fast feedback loop to gain and retain your customers. Now, obviously, there is a cost for that ubiquity. We have now close to four billion devices, four billion mobile devices, which means that our customers are mobile. They will have infrastructure which is near free computing code. So we no longer need to wonder or do submit reports that will need to build a data center. We can literally go on the web to Amazon Web Services or even to Pivotal Web Services and without credit card, we've ran computing power, computing storage network power. And I would recommend those who do not have an account to go to run.pivotal.io, get a free account. It's two months and you can definitely try the best of our public hosting platform. Now, we do have a credit which is we believe that competitive advantage or innovative cost reduction can only come from custom-built software, not packaged applications because every time you want to do a modification or a customization, you need to have a vendor, a consultant, to send the sales, to walk you through the price and then you make the modifications and then you're releasing to product. So you need to build that expertise in-house to get it with business. And we have some really amazing case studies. One of those is Mercedes-Benz for whom we built their bus application. So the application that powers all the new Mercedes-Benz Trials on their phone is built together with Pivotal. Pivotal allows hosted on Pivotal Cloud Foundry all around the world. Another use case is GE Predix. Predix is a predictive analytics platform which is hosted by General Electric last year together with our chairman, Paul Moritz, Jeff Emel, the CEO of GE, welcomed 2,000 data scientists across the world from different companies to come with that platform to develop the next best experience for machines. Healthcare, aircraft, all sorts of modules that will tap on the Internet of Things. And you already know, I have a smart fit at home. I have a smart robot. So all those devices have IPs. Even the ERP system in Singapore has an IP. So you can interact with it. You can build insights. You can do very smart things using all of that. Now the problem becomes like, okay, so how often can you release? Let's say you build that customer software. How often can you release it? Is it every week? Is it every day, every hour? This is a nice example of Well Front Engineering, which is a robot advisory company. So they release software every hour. And they have a dashboard, which is wellfront.com slash engineering, where they post all the status code. And if you literally code now, you will be able to see when was their last push to production. That's amazing. And it's a $2 billion company. What used to be probably more, it's powered by 200 people. So 200 people, including the whole staff. And they are disrupting the private banking and wealth management. And if you think they are very good, Well Front is being disrupted by another startup, which is called Betterment, with even fewer developers and engineers, with an even higher valuation of $4 billion. Betterment is another robot advisory, which tells you that software is literally eating the boat. Now it's getting to the big companies, Fortune 500. So survival is not mandatory. This is a great code. And if you can look at the Fortune 500 statistics of all companies that exited that list, and you look at the history, some of the companies not only left that index of Fortune 500, they actually went into oblivion. They are gone no more. Remember Kodak, blockbuster, those companies are gone. So you should begin with an idea in the morning, and just start trying it in production by the evening. And this is not a code or something that we think is futuristic. This is actually a code from an old state, Andrew Cee, who changed the way IP and software development is happening in a 150 years old insurance business. So he gave this on stage on the Cloud 100 Summit in 2015. If you look at his background, he's a former VP of Cloud at PayPal, and a former CTO for JP Morgan. So he has a lot of credibility in the industry, and he went through all these principles where he believes it's not enough just to think about software, you need to change organization. Very much like if you're familiar with Melvin Conway's law, where if you do have organizations within your organization, you have two groups of people that do not talk between themselves, or they don't have a very good communication, then the software that they build is going to reflect that organizational structure. So if you want to fix within your department two applications that somehow fail, you fix the organization structure and the software will fix by itself. Get them communicated. So you need to go from waterfall to agile industry programming. You need to change your enterprise tools to open source tools. You need to establish a governance for everything and a committee decision to empower the innovators. You need to go from monolith to microservices. You need to go from manual deployment into continuous delivery. I suggest you all look for this video. It's a 20 minutes recording live on stage. Next I would like to make a statement about the operations of the secret source. This is a block on Radar or Rady from 2007. These are two identical companies that develop in the same domain, same application. These are two startups. They've done the study by GCP, which is an investor in Silicon Valley. And on the left side they've done traditional operations. That means that they were still doing manual deployments, configuration management. On the right side, the team has invested in building a platform. And you should know, if you do not have a platform, you either build it or you buy it. The way you deploy your application as a production makes your platform. So there's no companies that do not have a platform. They either have a Cloud Foundry-like system, or they have a wiki page of 100 easy steps to production. So you can see that though you made the investment upfront and it took time, you can actually regain, you can have an ROI in the long term. So you can spend that time into developing more applications, fixing, talking to your customer, getting the feedback rather than just babysitting those servers and every time restarting them, updating the software or doing monotonous tasks. So I think the code of the year was no CIO told the IT team good job configuring servers. Because this is not differentiating. We need to be building business that way. And I'll quickly go into what makes Platform as a Service or Cloud Foundry one of the best places to run your applications and workloads. Well, first of all, you have these three layers. You have the application code, application platform, and the actualized infrastructure. We do believe that the value is in differentiating the roles. So we'll start with the application development. So his role is really to create a deployable artifact with his tools. It's not about Docker files or learning any tool. If he's a Java developer, let him create Jars and Wars. If he's a PHP item or Ruby, let him do just that. Then we have the platform operations which are building this massive cluster, this massive data center driven by APIs and driven by software. They monitor the platform. They scale the platform. They think they do more proactive rather than reacting on the firefighting and responding to mails. And then you have the application operations. So these guys are not your platform operations. They are in the team. This is what we can see that the DevOps group, they do configuration for production environment. They deploy the application. They do have the insights on what makes an application and how it works. And they are interested in monitoring the application. They should not go into a server and monitoring what's the patch? What's the logs? What can I find? It's not really about when the CIO asks the IT department, how are we making or losing money? They should be able to tell you all of that. How many users? How many requests? What's the health of your system? Rather than just, okay, I do not know, but I can tell you the utilization of the CPU in the network. This is really not happening. So with that experience, we can go, here is my source code, run it in the cloud for me. I do not care how. It's not my code, but it's the code of Onsif Akuri, who is our VP of R&D. So with that, I would like to explain in the next 15 minutes the value line. So we do believe that there is a red dotted value line in terms of what can see this to be useful for the business and what you should not focus at all. So let's begin. You do need an operating system, but does it really matter which flavor of that operating system it is? Like the hardware on which it runs. It's really not differentiating. Yes, we do need the power, the networking, the kernel, everything to host, to attach a network or the storage. You also need a container orchestration. So that means if you do have a workload, some really smart way of scheduling and publishing your containers or jobs across the cloud, you do need some cloud orchestration in order to create those VMs, create networks, create storage, attach the storage in the network. This is really neat because though we do have serverless applications, guess what, they run on servers. So you do need all of that, excuse me. But ultimately, it's not that differentiating. And what we do have in Cloud Foundry is this notion of CPI, Cloud Provider Interfaces, which run on all these five big major cloud providers. So next time when you get a new project, how much value do you get from managing the operating systems? I'll tell you, it's zero. Literally like you do not get any value. It doesn't do anything for your customers. Your customers will not make a decision between you and your competitor based on your operating system. So you should focus on first three examples. And that means everything should be run as a service. Why? Because a service has an API. If you have an API, you can interact with it any day of the week, any hour of the day. It's not a ticketing-based system where we do have a nice front-end, but at the end it sends an email and there's a person who has to interact. You should strive to have zero human intervention. You should have all these service automation. And ultimately, but not least, you should think about the multi-cloud platform because if you have been long enough in the industry, we do remember the days of IBM when there was only one thing where you could run your workloads. Don't get yourself in the same bucket now with Amazon or services. Though it's a great cloud provider, do make a backup strategy. Do not tie yourself to those proprietary APIs. And I definitely suggest if you look at the great presentation by Polar Meet, the founder of Pivotal, where he believed that there should be an open-source operating system for the cloud that will operate with all cloud providers. And that's how Cloud Foundry was developed. Cloud Foundry was developed in open-source, and this made it the kernel for contributions. So we do have Microsoft Azure. We have Google CPI, which was contributed by the community. And by community, I mean Google engineers and Microsoft engineers. They started developing those cloud provider interfaces to plug in into Cloud Foundry to be able to run their workloads on those clouds. Because why? The customers asked. And given the open-source nature, it was very well welcomed. And developing in open-source is very much different than developing in a proprietary mode because you cannot have your peer who lives across the ocean in another time zone to tap him on the shoulder and say, okay, let's agree on something. You discuss through issues, through APIs, through well-modularized components. Okay. Above the value line. I think the differentiating is build custom applications. And that will be, and it's definitely advised to be Java microservices. Why? Because if you continuously want an improvement from the box, this is a great slide which shows Spring Boot downloads monthly. And it's never ending slow. It's almost 4.2 million downloads until June. Spring Boot is killing the JavaE enterprise. Because, first of all, velocity is very important. Spring Boot comes with features like actuator metrics. And I'll have some of my colleagues, Josh, actually giving you a presentation. So I'll not post that much on it. But ultimately what I want to say is innovation speed in Java links. So if you remember the days of WebLogic WebSphere where you would have to provision hours in advance or even ask months to just get access to it, now you can run a Spring Boot application in 0 to 5 minutes. Actually, if you use Spring with Pewter Cloud Foundry, Spring Boot will get you an application from 0 to 5 minutes. It's enterprise Java with dynamic language productivity. You have all the best features of the Spring Framework in an auto-configurable fashion where you do a plug and play of all modules and components that integrate with if you have no SQL, if you have a metrics agent. There will be a library, a shared component under the Spring umbrella in the open source that integrates with all of those. And of course, if you want to deploy in the cloud, there is some orchestration that you need to build in your application the way how you interact and register microservices. I will just give you a three simple example. Central configuration management, service registry and discovery, and fault tolerance, in-build application fault tolerance. Spring Cloud has an interesting history. It was built together with Netflix. Netflix is the biggest and largest video company in the world. It actually has three times more traffic than YouTube. So if you think YouTube is large, Netflix is even bigger. It dominates the Internet in the U.S. and I think now in Asia as well. So what is actually Spring Cloud? So Spring Cloud, if you are using Puton Cloud Foundry, we do have managed service for you. So we do have a circuit breaker dashboard. We do have a service registration and a configuration service that you just create service, pick up your plan, bind it to the application and that should work. How many of you are familiar with Cloud Foundry? In the next five to ten minutes, Josh will come and we'll actually show you in a demonstration. But Cloud Foundry has a CLI. There is a few principles that you work with it. So the main principle is CF push, the magic CF push where you do have an artifact. You upload the bits to the cloud and then the cloud will provision a file system for you. It will provision the runtime and then we'll schedule that workload in the container and we'll run it for you. And then you can interact with it, scale it up and down vertically or horizontally, add more memory, add more storage, bind services from the marketplace. Now how easy it is from a developer perspective. So this is Java code. Don't blush away. It's really just a few annotations. So I annotated as a Spring Boot application that metadata shows to the Java application to run it, isolated within... You can run it in a container on your laptop. You enable Circuit Breaker. You enable Discovery Client and that will trigger on the class path that you have either a history dashboard to consume the metrics from Turbine which will push all the metrics about the status and health of your application and very similar how a Circuit Breaker in your house, if the application malfunctions, it will open the Circuit Breaker so it doesn't fry your platform or your house in the second. And Discovery Client pins the service that it needs to register with a service registry and then you can bring up and down the application. So Spring Cloud Services is a Netflix OSS as a service for Google Cloud Funding. Next, we suggest once you build those applications, you need to build distributed tracing. You need to monitor. You need to make the application observable. What does it mean? It means that you need to get information about how the application works, how the application is functioning, what is the health and status. But you do not need it just in a specific time frame. You need to watch it across an interval to be able to judge if the application is behaving better or worse. Because snapshotting time is not that important. Of course, it's good to know the status in an instant, but you should know at the life cycle because when you are updating or patching your software, this will give you insight. Is the new release better or worse? So we do have this PCF metrics which is a fast feedback loop which gives you a live stream of 24 hours of data. It's a dashboard that you just get if you install eutopop on it. The next one is zip and tracing which gives you operational visibility distributed tracing. So you have all these calls with time spans and IDs, and then you can look across all your microservices. Where actually is the bottleneck? So if you go to microservice architecture, you will notice that suddenly you have almost like a crime investigation. Like where is the actual problem? Next, you need to think about API and API management. So we have route services which you can plug in. You can literally create a route service in binding to application that will do filtering or security or rate limiting or data analytics. So it will inspect the payload that you send to the API and do very smart API management for you. Route it. We do integrate with Apigee. If you have questions, definitely grab me after this talk. We'll go into more details. Next is data flow. So we believe that once you build those microservices, there's definitely data that is happening. That will be the subject of the third talk by my colleague Carlos Cueroz. But in a short while, this is literally what you need to set up a data microservice orchestration. So it's still a Java Spring Boot application where you register the module and then you create a stream. What means to create a stream? It's very much like how you create a pipeline of where the input and output goes for the subsequent services. Currently, if you build a good experience, if you have an application, then you will have demand. Then you'll have feedback from your customers. Then you need to iterate on it because the value of an application is to continuously improve that experience. It doesn't work if you have four releases a year. If you have four releases a year, then that means you only get feedback during that time, which is really, really slow and you'll probably get out of the pieces. And I know four releases a year sounds really interesting for folks who do one release per year. If you are there in the room, it's better to look for another job. So what actually means to that feedback loop? So this is the suffer of software. You begin with an idea, you write a story for it, you build some software, you run that software on the server and then you got the feedback. Once you got the feedback, then you improve, you patch and update your story. So we believe that there is actually a portfolio of products and a pivotal umbrella that will help you do that. And I give a talk which is more exhaustive. The title of it is Keep Calm and Push Applications as Service because ultimately, if you build a custom user application, you should have the freedom and flexibility and confidence to just push them to a cloud and worry about how application and business logic works rather than all the tedious bits of configuration management. So you write a story, you can use build.trakko which has been in a while. It was built together with Google engineers in 2000. You develop the code obviously with Spring, you deploy the code on build.trakko, why? Because Spring has this amazing umbrella. You have Spring at the core, you have Spring root, Spring Cloud, but don't forget there is Spring part, Spring integration, Spring data, Spring ready, Spring data, Cassandra. You have Spring social, you have Spring security, Spring budge. All of those are meant to get out of your way and if you need any configuration to interact with those applications, you just drop and develop that experience in a Spring root application. But microservices are not an island. They don't work by itself. Like, I know we've started doing Hello World applications, but soon enough within your portfolio you'll actually have multiple services that need to be orchestrated, need to be managed, that work and communicate with each other and that's where I believe Spring Cloud services will help you with those distributed patterns and on how Josh speak more about it. We do have a hosted, we do have a dedicated people, but we also have a PCF Dev which stands for your developed experience. I have one PCF Dev on my laptop running within a virtual, within a VM and all these containers, it's actually the same software that powers our distributed platform but now runs within images because there's less resources on my laptop but the contract is the same. It's the same experience. I go to network.pivotal.io product PCF Dev. It's literally a plugin that goes back to my Cloud Foundry CLI then I simply look in, it's on my local PCF Dev.io I can push the applications, I can get information about applications, I can scale and I can even remotely as a safety to the public face and this is just a screen if you start PCF Dev. Once you deploy that you need to build a pipeline what we recommend is this concourse CL which was built originally for testing and continuously integrating libraries and components from our Pivotal Cloud Foundry but it's independent from PCF you do not need to run it in PCF actually you can run it again on a laptop I have a vibrant image of concourse that I use for demos there is one that is being deployed that runs all the pipelines for components within Cloud Foundry so ultimately I think you have this circle circle of code but more importantly is you need to repeat this circle over and over again and the existence of it is because our namesake Pivotal is actually from this consultancy company called Pivotal Labs which has been existed for close to 30 years within Silicon Valley and the founder CEO he is now the CEO of Pivotal and he has a great talk which I again advise you all to just review it it's 10 minutes walk talk about state of mind where Silicon Valley is not just a place in the world but it can actually be transparent because there is a set of practices that you need to do set of ideas and expertise that you can move and even create enterprises we do have customers who once we worked on the platform they asked us to build a very similar Pivotal Labs within their company we do have a presence in Singapore I cannot be able to cover a lot about Pivotal Labs but this is the details currently it's Craig Road we do some of our meetups there so there are very nice bunch of kicks that like to work on the software so with that I would like to close ultimately the goal of this presentation is not to over well with the catalog of products of what we do but we need to start a conversation on let's build something meaningful I would like to help you to build your custom application so that you stay in business so that you make money so you make a better product and remain relevant thank you very much I can take a few more questions Jake is Josh around hey buddy do do do do do do do do I'll have a question slide even more