 OK. So the topic of today is really service brokers deep dive. And the reason I've chosen this topic is because we are doing it in a community effort together with the DevOps and the Spring User Group. So if I just, you would raise your hand. Who is from the Spring Meetup? Spring Meetup? OK, a few hands, one. OK. And who is from the DevOps Meetup? OK, who is from the both? OK, cool stuff. So one of the reason is that by choosing this topic, I thought that I will have something to share for the platform operators, for the IT operations, and as well as for developers. So I will touch into specific topics and I will try to bring the best I can the information. And because there's such a small audience, we can interact more. So I don't really want to give instructions and step-by-step execution that can be followed easily by a GitHub. But I really want to have a conversation with you guys and girls and would like to interact so that this is really the best part. So if you are attending this time on a Friday evening, you're making a sacrifice. So let's get something for both of us, really. So I will pause. And I really want to explain the whys, not necessarily just the what, because I've seen so many times in the corporate or in the community where people go attend a workshop or read a book and they get the magic recipe and they start implementing. And the others who haven't read or haven't attended the conferences, they don't know the whys. They don't have the context. So it's really hard for them to follow and then make it a constructive debate. And following blindly without for yourself really believing, it's just so much harder. So let's build the context together and we will have this session. So I think we will have one hour and a half. And definitely, let's have, stop me when you want to ask anything. And another note, so I recently have a knee injury. So I'll have to sit more than so. So please excuse me. So who am I? So my name is Sergio Bodiu. I am based in Singapore. I work for Pivotal as a platform architect for the Asia Pacific and Japan region. So I do have regional responsibility. I'm also organizing the Singapore Spring User Group. And together with Satyam and other community leaders, we organized this Dev of States conference, which is going to be the second year. Now, without further ado, so what I'm trying to do with this talk is really get everyone to understand that there is value in continuous delivery. And ultimately, all these technical talks or whatever you are attending, it really should help you either as a developer, as an architect, as an IT operator to be able to answer a couple of questions. Like how easy can I change anything in my application? Or how often can I release the new features to production? So by answering to these questions, you will establish your release lifecycle. And you will know if you're implementing continuous delivery, continuous deployment, continuous integration, unlike if you're really doing agile. So just keep in mind, if you are not doing any of these, then it means that you are in a legacy world. A little bit about, so I mentioned I work for Pivotal. So Pivotal as a company, it's a startup that was founded in 2013, spun out of the assets between VMware, EMC, and General Electric. It really literally had 1,250 people at that time and under the leadership of Paul Maritz. So his vision was to create a company that will create a operating system for the cloud. Now, the latest news was that sometime back in May, we had another round of series C for seed, which we collected over 650 millions. So we are no longer a startup, but I definitely think we have found a niche market and we are the leaders in the platform as a service space. Now, why do we see more and more, so Anderson has said that software is eating the world. Well, this is actually a depiction of how is it doing. So this is a diagram by CBS Insights where they put all the logos when the startups reached the $1 billion valuation. So these are all the Unicorn Club members. So as you can see, on the far right side, you can see almost like a cloud of companies. So all these companies have a valuation of more than $1 billion. This, of course, worries the Wall Street and the traditional companies who are making the end meet. So for them, it's always about the PNL and profit and losses. Let me give you an example. So this is a slide from Citibank, which was done during the Spring 1 platform in Las Vegas just a month ago. So I was fortunate to attend this presentation. And this is the way where they are thinking to do the digital transformation for their portfolio of apps. So this presentation was done by Brett Miller. And he's the head of digital. And basically, he looks at refactoring from both sides, like top down and bottoms up. And interestingly enough, he shared a lot of lessons learned, like how people, after starting doing a bottoms up approach, they were just looking at this as refactoring exercise. And now the application server changed the framework without an actual business benefit. So they were just changing some of the plumbing between the applications without adding actual value. So the whole exercise was to cut costs and make it cheaper to run the applications. However, the investment of time and effort to go through this exercise is, again, very significant. So he joked about it. And he said, if you're trying to rebuild the platform in the cloud, and you are starting to chop small pieces of it and will rebuild it, then by the instinct, you'll have this mess, this distributed monolith cloud, where you're going to basically repeat all the mistakes that were in the old platform. So you'll bring all that legacy technical debt. And then more importantly, again, you're going to fail. So all that faith and that this time we'll do it right is going to the sink. So then let's ask a question. How do we fix my legacy system? And then the immediate question is that rather than solving just a technical problem, we need to solve a more cultural problem. How do I fix the culture in my company so that the people in my company are actually building the right system, the right way, and adding value? Now, let's talk about what we're going to do today. So the goal of the demo that I'm going to present is I'm going to have an Amazon S3 broker that will create a S3 bucket that can be automatically bound to your application. So think of it, we have a ton of legacy applications that are either stuck on the mainframe or using NAS or any legacy storage. So in order for them to move to the cloud, one of the prerequisites as part of the 12-factor principles is really to move to stateless application or extract that functionality to a storage that is scalable and resilient in the cloud. So S3 comes in mind. So that's usually a prerequisite where I see a lot of people asking, how do we move from A to B? In this case, how do we move the files or the batch files or whatever reports that they're having? So the service will be using a Spring Boot startup project to auto-configure the connection as easy as to consume it in a cloud-native way. So one of the other principles of 12-factor is really the way you manage your configuration. So rather than having the configuration into your application, put together with the code, which then makes it really hard to unbundle and then deploy it into different environments because that configuration is very specific to any environment. And if you bundle it together, then you basically you're not making it portable. If it's not portable between your development test production, then you are investing a lot of time in just plumbing various points in your architecture. Then the Spring Boot application will look at those environment variables and will automatically configure the S3 connection. So by using this approach, we're actually also improving the security. So you remember, and I believe if you are working for any corporate by now, is you need to have access to credentials, be it API keys, database passwords. So there is usually a process, but that process requires a manual handoff. Like the admin or the IT opens a chat window or sends an email to a developer. And then the developer or the release manager keys in those credentials into the application code or into the XML or property files. So you want to avoid that part. You want to dynamically generate those credentials so that if those services are corrupted, you can immediately remove the access and be safe. And as well, if you are looking at update and upgrade scenarios, that will serve you very well because then you dynamically generate the credentials and you can bind and unbind, attach all these services as backing services. So we can create a starter project that includes an Amazon S3 template for consuming S3 service instances. All we need to do is include that Amazon S3 project into our... So think of it rather than just me handing off a documentation to someone how to write a client, I'm going proactive and creating not just a client, but a template where I'm saying, in the 80% of the use cases, this is how you would probably use the S3. So I'm creating the buckets for you. I'm creating the users. You just need to do your business logic. In the other cases where you need to add maybe billing, maybe auditing, you have to do some customization, but this should be enough. Another example would be if you look at the spring JDBC template. So of course, when we are persisting data, we need to open a connection. We need to create a prepare statement. We need to execute an SQL. We need to get the result set and then the result set, we need to map it into a bin or into a data object. But those are not serving us any purpose. This is just repetitive code. It's not really a business logic. Really, the customization that we are doing is in that SQL statement that we will implement our logic. So what we would have is really a template and then we will have that portion of our custom code. Why is that? So basically we want to avoid orchestration, right? And one of the perils going into this cloud journey is that people think that this is again service-oriented architecture and go with a bottom-up approach and they break the applications and then they have to orchestrate. Like applications still need to be deployed in a certain order for the workflow to work. So if your services or microservices are not independently deployed, then you're basically repeating the mistake. You're recreating a distributed monolith. And that's a big pain because on one hand, you are getting all the worst parts of the legacy system and then you're creating a big problem because then your deployment is actually much worse than it used to be because you still need to deploy X amount of services. So let me actually, yep. I mean the orchestration of the controllers. Because if you are writing multiple services, still we need to go for some kind of orchestration and still we need to call multiple services and then we need to have it in some kind of state in terms of controllers. So is it only about the deployment or is it about calling multiple services from a controller perspective? I think that the best way to describe it is like when you are looking at a microservice being a single deployable unit of work. So it really needs to be independent by itself. Now it definitely will have dependencies because you might need a caching as a service, you might need some storage, you might need a relational database or a document store, all of those, or maybe like some authorization and security. However, those are dump services in a mean. There should not be a leak of business logic between the application and the way which services you're calling because if you're doing that, then the service again is not independent, right? The logic is leaked and then you have the same issues that you used to have with service-oriented architecture. So my question is about the security aspect of it exactly? Yeah, but security, let's just discuss a little bit, maybe one more minute. Security by itself, it's a cross-cutting concern. So you do need to have security in the whole application. However, that should not impact the business logic, right? It's really a input-output processor. So like, you know, you are the denied access to the resource or you're accepted and then there's another filter that will be executed until you execute your workflow. So what I'm currently having is, I'm gonna showcase you Cloud Foundry. So I do have a Cloud Foundry instance and more importantly, this is a locally Cloud Foundry on my laptop. The way I did it is there's this CLI. So I've started this instance. So I said, okay, please start me a development instance of Cloud Foundry with eight gigs of memory. So I thought eight gigs of memory will be enough for me to play with the brokers, the applications, the samples, and then the other services, right? Now, because this is a development, I also can do all that mean stuff. So I don't need to ask permission. So I have access to the build packs. Okay, let's resume. So I suspended it. Let me resume the machine. So the machine is really a virtual box instance. As you can see, it's restoring the state. And now it's gonna take just a few seconds. It's a mistake, but let me actually show you what I mean by. Now this is just a virtual machine with all the same components running as containers inside your VM. So while that VM starts up, let me just show you this picture which will help you understand how it works. So on the left side, we have Pivotal Cloud Foundry which is our commercial offering, which is again based on the open source Cloud Foundry. So, but it's fair to understand that this is a distributed system. So all its components are standalone virtual machines. So if you're talking Cloud Controller, Login, Blob Store, all of these are components which live by itself in a virtual machine. So a minimum installation requires 28 virtual machines. Now on the right side, I have the same capabilities but meant for a development workload. Like so myself, if I'm a developer and I want to extend the platform or I want to test the application before I actually deploy it to a remote Cloud Foundry, I can do that and I can just spin up that virtual machine and all the same components exactly the same but running as containers. Now it's fair to understand, there is definitely some difference. However, in the terms of contract, API, libraries, it's kept to mirror the same capabilities. However, things like Bosch, so some of the self-healing capabilities are not there. So you still have the applications instances, you still have a marketplace but it's like, let's say, condensed PCF components. But it's the same API how I would use a Cloud Foundry instance. How many of you are familiar with Cloud Foundry? Just a few. So in a nutshell, have you used OpenShift, Kubernetes or any of other platforms per se? So let's say if you do have a traditional workload now, if you want to deploy an application, then you need to do some amount of middleware configuration. You need to stand up basically a server, you install the operating system, add all the runtimes, the shared libraries and then all the components and then you can run the application. Now there's a amount of effort that it's repetitive and you'll be doing it for all the other application services. So this needs to be extracted and the way we extract it is we build this pure Cloud Foundry which is running applications within containers and then uses a Bosch tool chain which is interacting with our infrastructure as a service to build that package. So think of it, you can run the same platform on Amazon web services, on OpenStack, on Azure, on Google Cloud, be it public cloud or on-premise but the API remains the same. Okay, so PCF Dev is running, so let me just do, so I can do a login. So you notice there is an API endpoint. I'm just gonna add admin, admin. Then it prompts me because this is a multi-tenant environment to ask me, okay, so I see you have a couple of organizations. So this in that perspective is like, imagine you have your procurement and then logistics or you have your HR and then development or IT. They do run applications. There needs to be a role-based authentication so you would have different organization so that you can have, you can manage quotas, applications, access and yeah, you had a question. Okay, so I'm just gonna choose PCF Dev and what I'm gonna do is I'm gonna show you the marketplace. So just to show you is we do have already this service created. So I've created a service broker and I've created an Amazon S3 service which is not available by default. Now the way I can see this is I can look at the application. So you see I have my broker application which is again running as an application instance on this platform and then I have my demo application. So you can see this is the service brokers that I have. So I have a Redis, Rabbit and Q, MySQL and then my custom Amazon S3. Just to show you the demo. So this is the application sample. Now it's a simple upload and download application. So I've created an S3 bucket because I have this service. We'll go through the code and follow the steps. Let me show you the end result. So I'm gonna go and pick a file to upload. Some uploading this image. Yeah. Do it again. Haven't tested with. So yeah, you can see it's a new JPEG image. I want to top load, just do some. So this is the picture which I want to top load. This is from last year DevOps days. You see the merry crowd. So far is the application workflow easy to understand what we're going to build? Yep, cool. Let me explain the patterns that we're going to use. So first of all, why go to that extent and creating a service broker? Why not just do it in the application itself and just create an S3 service in the application? Well, first and foremost, that will probably duplicate. I'll probably have a few applications that are going to repeat the same code. And if I'm going to duplicate that code, that means that I'm gonna have different versions. So then I will have, to manage those different versions, have operational overhead in terms of how I upgrade and how do I keep, you know, let's say, matching the libraries, avoiding security issues and so on and so forth. So definitely it's not a good use case for me to duplicate that effort and then have it sprawl into my, into my portfolio of applications. So let me define who is a DevOps consultant. I'm not gonna go into the buzzword of just DevOps, but let's say this is a description that I got from Patrick de Bois, who is one of the creators who basically created this terminology. So this is his description. Like, he is a DevOps consultant and the way he describes himself, he's bridging the gap between projects and operations by using agile techniques in development, project management and system administration. Well, if I look to it, it's not nothing new. It's the same areas of expertise that we used to have. It's just like now I have fewer people. And I think this is very important because now, you know, not only applications grow more in complex, but we really do not need the middle layer where we have to have layers of layers of business analysts and people who translate requirements. The moment we can have customers working with developers, you know, that if that gap is minimal, then we will not have unforeseen results. So like there will be the same communication. There will not be that gap. Now, another example would be, and this is something that I've done or showcased at the previous DevOps where, you know, the way it was defined in the beginning was that this is agile infrastructure and this is the GATNA diagram. So the way they see DevOps or the expert in this domain is that, you know, so we have the development, we have the quality assurance, and then we have the technology operation. So people who do software engineering who operate and test, they come together and we have this DevOps team that takes care of this whole responsibility of delivering end-to-end solution. Now, I do agree this is really exciting, especially if like you can tag a single person and assign all this responsibility. However, I do believe that, you know, it's more than just that. Like it not necessarily needs to be the same person that will do all these tasks, but there's definitely a shared of knowledge that needs to be done between these various teams. So as a development, I need to start learning more about the way I manage resources, the way I document my services. It's not really where I can bury it down into my application code and, you know, it will blow up into production. I need to start looking and managing the dependencies. Like, you know, before I deploy my application, I need this database with this schema with this specific version. So I start doing versioning of my database or for messaging queues. I need these specific dependencies. And that creates a responsibility on the developer to create that manifest, you know, like a recipe, like a cookbook if you want. Like, this is what I need in order for my application to work. And then you go into that microservices domain because if you're able to document all those dependencies, then it's very easy for people to manage it. And if there's a problem, then they can look throughout cookbook and hopefully the application is resilient and it's able to give you a specific error message that will help you to understand. So far, so clear. How many developers do we have in the room? Okay, so we do have a lot, which is good. Gonna skip the rest. Now let's go to the operations. Many operations and many colleagues of mine before my work, they have this amazing number of scripts. Like in every directory, on every server, they have these 50 easy steps to deploy to production. You know, they document these wiki pages, which is like, yeah, you just do, you know, one to 500 and then like, you know, if you have just repeat it again. So those scripts need to go away or there needs to be a better management. So like, you no longer re-implement the same recipes, you probably will use a stack or a framework or a scripting language that makes all those artifacts reusable so that you can share amongst your peers. So if any of you have been programming in PAL, it know how easy it is to implement a one-liner and how hard it is for someone else to maintain it. Now, definitely version control and it's really about infrastructure as a code, but infrastructure as a code means that you need to develop APIs because, you know, it's not gonna be a ticket, an email or a person who's gonna respond to you. So, and then we go into a discussion in APIs. However, I'll skip, but if you have any questions or you want just clarifications. I'm actually developing a map for desktop application. So how does Cloud Foundry, I think it's a very basic question, maybe it's quite off topic, but how does Cloud Foundry can help in that continuous deployment? So currently we are using Jenkins, Jira, GitHub, and all these things. So it's a desktop application, but how many team members do you have? Five. Five. And do you consume any services outside? Yes, it's actually talking to Cloud, basically it's a mimicking Cloud data on your desktop. Okay, and let me ask you, so how long does the continuous integration lifecycle? Let's say from your code commit until all the test passes, and let's say some QA and maybe someone does a sign-off. So, ha, ha. So automatic, like test automation in the test, it takes maybe like 30 minutes. Like the moment I commit my code, the build starts in Jenkins, and unit test, integration test, I think it's done that, it's 30 minutes. And what do the other people in your team do while that runs? They wait? All five people are developers, they just take up the stories based on... Yeah, so that's an easy way, like just to look at it. If you can parallelize those environments, instead of all your team members sharing the same environment, like if you're able to provision an environment just for yourself, so that you can boost the speed, and you can build the environment on demand, and then kill it after you've done all your integration testing, then you can speed up the whole development lifecycle. Let me use CloudFont for desktop-class application or is it meant for on-leap or browser-based app? It's meant for services, it's meant for web applications. It's, if you look at it, it's really how you design your application. Of course, if you, like, I think the next question would be how you do this testing. Do you do user interface testing, or you do some sort of API testing? Do unit testing of each individual model doesn't have any interface, like directly on the model we're testing, and then the action user level is testing, but in other, there's a UI automation testing, like both, like, and both are the same. Yeah, so I think that unit testing is one way that you can help. Then the other part is really the dependency services, like, for example, like, do you use consumer-driven contracts? How do you keep up with the new releases of services? Let's say, you know, if one of your dependencies, it's upgraded, like, do you need to receive, like, one month in advance to prepare for that deployment, or you can just do it ad hoc and then have darshing strategies and, like, you know. Currently it's called manual, like, it's a new version of a dependency release term, we manually take it and integrate it. And then we've got the C++ applications. C++, I think... So Mac Finder-based applications, the application itself doesn't have any UI slightly indicated to the Mac Finder? Okay. So definitely there might be use cases where you can benefit, but I feel that you need to look above that, like, you know, what about the other applications in the portfolio? Like, how do they work together? Because Cloud Foundry is good for running one application, but it's much better if running a fleet of applications. You know, really you see the benefits once, you know, all your teams have the same expectations, like, you know, for yourself, if you're going to move next year, or, you know, into a different team, then you'll not have to relearn 500 easy steps to production. You'll actually, you know, you'll have all the same tooling, the same APIs, and you say, okay, let's just do a CF push. You know, and then everything is just, I worry about the code. So the moment you use these platforms, it comes with pro and cons. So definitely there's benefits in using it because you have an API first. But again, it really depends on your application. Like, you know, what's the workload? Like, you know, how you scale it? How is it? Can I say, is it like a kind of a competitor or an improvement over Jenkins or something like that, continuous integration or something like that? How is it, compared to what we are doing now? So you can actually run Jenkins on Cloud Foundry. So Cloud Foundry is more than just like a running application. It also runs services, and this is why I'm going to demonstrate how this Astri broker can, so basically what you're doing is there's no existing Astri service on the platform, but how you can build it yourself easily, and then how you can bring other services onto the platform. And then ultimately, everyone needs to test fast. Like, literally, I think the best lessons learned if you are building a Cloud-native application or you're going into this new world of you need to decrease the operational overhead. And by decreasing that operational overhead, if you're doing continuous delivery or continuous integration and you have a QA team, you're not doing it right. You need to automate all those steps because that's your blocker. You're just doing it, you jump the fence, but then you have this huge wall, this gate to pass. So oftentimes, you need to begin with a test-first approach. Be it to your application, be it to your services, to your platform services, so on and so forth. This will ensure that, first of all, that testing can also serve as documentation, the way how application was meant to work. Because oftentimes, we see people adding tests as a check-off, just to improve the coverage. And without the explanation, sometimes you go into the testing, the code, and it's just awful. So let's say if I'm gonna explain or give you a short five minutes description of what's Cloud Foundry. So there's three parts to it. One is these clouds. So Cloud Foundry, as a platform, is meant to run on these cloud providers or how we call it cloud provider interfaces. So infrastructure is a service, like Amazon, web service, OpenStack, VMware. So they give you the compute, the networking, the storage, all these APIs, but they are raw. So we have a set of 13 APIs that the cloud provider needs to support, like, for example, creating a disk, attaching a disk, creating a network interface, creating a VM, destroying the VM, so that we can orchestrate the creation of services and the virtual machines. Then the next part is the runtime and framework. So once we've created, you know, that we have the underlying infrastructure and we have a layer of abstraction, then we can start building higher level APIs. Like you are a Java developer, you probably need an operating system with JDK installed on it so that you can run your code. You have a Python application, then you need a Python interpreter. You have a Ruby, you need a Ruby interpreter. You have a binary application, then you just need to run a Sage or bot file. You have PHP, .NET, Node.js. It comes with its extension points, but fair to say there is like this concept of build packs and framework that will help you gather all these dependencies and I'll just show you in a minute. Now you have up services and service brokers. So if you look at it is the application by itself, it will consume services. Like I don't see a benefit as an application developer for you to actually go and build your database or build a messaging service or build a caching service. Like literally if you're doing that, then you probably should work into a vendor space and that might be right. Maybe that's your differentiator, but if you are defining or creating custom application, mobile applications, then you really are more focused on the user experience and how the customer will interact with the application and how we'll consume the data and how you can monetize that aspect and really work in a close feedback loop to improve your service rather than just like work on this patching of how the backing service works. How the disk, how the drivers for the disk working or how the network drivers and so on and so forth. Now I don't want to go into more details, but like this is a really small picture of Cloud Foundry architecture. So you have the pivotal network. This is the way how you download the software. So Pivotal Cloud Foundry is a software package. It needs the underlying infrastructure to be able to work and give you the, so there's no manual wiring. This needs to be done by someone and that's why we have the dependency on the infrastructure as a service. Then we have the apps manager, which is really to manage the applications, really the application layer, the customer facing applications. And we have a Cloud Foundry API and then a service broker marketplace. Now the service marketplace, it's really to expose as I said, shared services, foundational service, like think of it as continuous integration. That continuous integration can be used by n number of applications. Database as a service again can be used by n number of service. I can map it one to one or one to n. It's really how I design my application. And the same goes for not just data services, but mobile services, caching as a service, messaging as a service. This is really how I take benefit of a catalog and then create my custom application where I really need to focus on the logic rather than just on the plumbing. And then where I deploy that logic, as I said. Like you do have an application, you, as a developer, you build that artifact and you really should not be worried. Like, the worst that I need is really to write a Docker file where I document how I, which Linux version, which operating system, which runtime I need to do. Because if I do that, it's really hard for me to maintain a governance. And that might be true if you're a startup. This is where we go into a conversation like how you manage risk and acquiring customers. Like really, if you're a startup, do whatever works. Like oftentimes I get asked, like how do we do this microservice architecture? And then the question that I ask is like, do you have customers? I do not have customers. Maybe that's the first priority where you should work and work on getting the customers and the feedback and then you can worry about the microservice architecture. The same, this is really for corporations, for small and medium businesses that have customers and they don't want to dwell on the operational overhead. So I have a question regarding the service broker functionalities or functions. So let's say I want to use a MySQL service broker. I still have to write the JTBC template and I have to still write the skill query. And the service broker, I just say I'm writing a service. I just bind that, my service into the service broker, service name. So what exactly like in terms of functionality if I have to list it out? So what other thing you'd exactly list? Let me just go quickly over this and then I'll reply back to. So when I try to elaborate on what's a microservice, I like very much to present this picture because then it gives people an understanding in terms of like, what is a service? So the question is like, how many microservices do you see on this webpage, which is an Amazon product page? And animation should start right now, yeah. So you have all these boxes highlighting different parts of it, which are independent functionality that can be deployed independently and they are managed by different teams. So you totally have 11 services. So here you have your recommendation service, your shipment service, your description and catalog, availability and then currency exchange and so on and so forth. And why is Amazon that successful? So this is a post from 2003. It appeared on the World Wide Web by mistake because an internal employee disclosed this internal memo. So this is really how Jeff Bezos brought top down microservices architecture on the teams. So rather than having all these teams going to the meetings and discussing how they are going to manage the release or manage the integration, to say like, if you are an independent team, famous to pizza team, you're going to create a service and then all the applications that are consuming it, you're gonna abide by this contract defined by you and you're going to give them an SLA. So if they implement this contract, then you give them the guarantee that you'll support them. And of course he ends up like whoever, like no exception, anyone who doesn't do this will be fired. So like this gives you like a, you know, no return policy. Like, and now let me get back to you. So when you have like a JDBC, so there's two parts of it. One is the client part and the other one is the operational aspect. So for the operational aspect, this is where the service broker comes in. So you need to understand like for service broker to work, there needs to be a table space. There needs to be a schema. There needs to be a user that is created, you know, so that you have that resource. And obviously that resource needs to be contained and you know, there needs to be role, access, privilege. And then if you are using in a multi-tenant environment, then you have different options, different SLA. Say your MySQL could be a Oracle Rack cluster and have one level of SLA. It could be a standalone MySQL, you know, in a VM or it could be a in-memory database. And that's really the plan or the service SLA that you are deciding from an operational aspect. Whereas from a development aspect, yes, you still need to write a SQL query. Of course, there are now frameworks like Spring or even, you know, Sinatra and Ruby or in Python where you don't go and write all that boilerplate. Like in Spring, you really are focusing just like you don't even write now the query. Like you write that JPA interface like anywhere, say like find by name and that immediately will convert into a SQL query where we'll say select star or select star from employees where name equals blah. All right, so this can be done magically because you know, there's really not that complicated. Like honestly, if you are going to implement again and look at the database contract, it's really Java persistence API that tells, okay, I need a socket, so you need to open the connection. Give me the query and this is the result. So for you say like, okay, so really the business logic that you code into your application is that query and what you do with the result after. Like the rest is just like repetitive. It's not different from a report, from a login or from any other functionality that works with a persistence API, right? So you do need to think in terms of client as a developer, like how I'm consuming this service and what custom functionality I'm using and then the operational where like I need to manage different versions. Like, you know, there will be a schema changes. Like how do I upgrade the schemas? How do I run DDL and other queries? You know, how I upgrade libraries? Like, you know, there's a TCP connection and like I need to upgrade the database and then I upgrade the client libraries. So this is all operational. That needs to be done by someone who has a governance on the entire data layer, like, you know, like a CIO who manages the information. And then for you as a developer, you just worry, okay, so I'm given a persistence API and for me it's enough. This is enough, the SLA that I've been given. So what I'll do, I'll code using that, having that in mind. This is another example of a distributed monolith. Like, I really want to explain that you need to keep things separate and as simple as possible because like, often time using a same example, like if I'm managing the database and then I've write a query, then there's that vicious circle where like, am I a database administrator or am I a developer? Like, am I an expert in optimizing the queries and you know, looking after the table space indexes or am I really implementing the custom logic and working with the customer to understand the requirements and moving on the user experience rather than just like on the, let's, managing that layer. So even before the service was introduced long before that, I used to still connect to the database with the connection parameters which are pretty contract oriented, meaning in terms of JBA and JDBC still. Yeah, and that's where like an application, but who was solving for you the provisioning? Like, who was updating those credentials? Who was managing the availability? Let's say, you know, soon enough you need to delete your application. Or you know, like, who takes care of those aspects? Or you want to update your application and then migrate the database? Who's gonna take over? The operations didn't give me the name for security. And what's the API that they're giving? It's really just like a closed wall. They are not giving you any API. Like, you are not informed, it just, they will tell you a window. Like during this time, we're gonna do something magic and you just like, you know, wait until we, the service is available rather than for you choosing, like, you know, well, you are giving me a new catalog service. Like this is, you know, maybe like version seven. But, you know, I'm still not compelled because I'm still the SLA that I have, it's fine for my application. And then you move on your choice. But then it doesn't stop the platform engineer and the platform architects, you know, like the guys who are managing that platform as a whole to improve their service offerings. So like, what are, like, if you can deploy your services independently, then they aren't microservices. So what should you do? You should decouple, you should transform the data, use a strangler pattern. So really carve out a functionality in that big monolith, you know, or how you're managing that data and just build a new service and then migrate your users to use this new service and then just like remove it, like, you know, decommission that once you have the 100% of your users on the new, on the new service. Start doing API-first design. Because oftentimes, like, if you remember, we had in the university, like, how you should design the schemas and how you should rationalize the design, like how you should do the normalization and then you have different levels of database normalization. Whereas that is not really important, like, this is very good from a database perspective, but clients are not using the database. They're looking at a specific workflow. Like, if I'm, like, you know, buying something from an online workshop, I really don't care if there's like five, 10 tables or 20 tables. I really want a seamless interaction. Like, I want the item to be charged on my card and then shipped to my home. And I will pay, you know, the fees. And then I want to be informed about the, you know, when it's gonna arrive. It's totally different how we used to do database modeling. Like, we would usually go into database and then see, like, okay, this is a foreign key and then this is how you do, like, all this nice, like, it looked very well on the dashboard, but it was so hard to implement a usable service. Like, oftentimes it will deadlock or it will time out or it will have an awful experience. Like, you know, it would just be a spinning wheel where, like, you know, waiting. And then consumer driven contracts. And that's where, like, I think if you are going microservices and you want to do it independently, like, you still want to have that reassurance that once I deploy my application, it's working end to end. Now, the trouble with that is that now you've split it and you have that independent. However, if you want to run, you know, like a full end to end test for your entire portfolio of applications, then that means that for every commit that you have, you need to deploy all the applications, all the dependencies. And that's gonna be very expensive. Rather than just, like, deploying your whole application portfolio, you just, like, look at the dependencies and if you change a specific service, then you just need to verify the contract with its dependencies. And if those contracts are still true, then, you know, the assumption is that everything is gonna work as fine. So there's, like, a new way and there's this new layer that you need to implement consumer driven contracts. And the way it works is, you know, I define a new service. If someone uses my service, it needs to write a contract and commit it as a test on my project. So this way I'm actually informed that someone is using the service and there's this specific SLA. So they're using version one, version two, into this, you know, they're expecting this SLA. So like, you know, let's say a reporting that just does quarterly reporting, you know. So they are going to submit and check in a test into my service. So every time I'm gonna release, I need to be mindful and say, okay, so I still have those users that are still running it. And then the same is being executed on their side. So they have this as a mockup and say, like, okay, as long as, you know, so I have the test, so whenever there is a change into that application, if it fails that, it will just break. So it will not released. So just mock it. I really do not need that real application to be side by side with me. Is it clear? I know Consumer Driven Contract is really very new topic and quite interesting in terms of its implementation. So it's between integration testing and mocking. So after the day, we just don't make it. You run the APIs on the... Yeah, that's very much like an API test. However, it's not the end-to-end testing. So you're not really testing with the real application. You're really mocking it, but it still crosses the network bound. So that means that you will treat it as an external service. You're not going to work with it as an in-memory, you know, like a stub. You really are going to test the contract. Okay, now let me go into why customer services are very important, like beside the application lifecycle. So I know people, docker, docker, docker. Like, you know, you have this container and then you run it, the application and that's, this is fine. It's a good packaging format. However, you need to think about your services and SLA. Like how do they operate it? You know, there's very much a big difference how you run a Redis instance versus a Oracle instance versus a Rabbit MQ instance. Like just in their behavior and what they're doing and then what they need as resources, it's very different. So, you know, there's three options, how you bring a new service into the platform. So the first one is the one that I'm gonna mention today. So it's a service broker. So it's a simple and consistent way to access services that are running on Cloud Foundry. So there is a contract, what I meant to say and that's five RESTful APIs that you need to implement and if you're implementing those, then you can have an offering on the marketplace. Then there is custom PCF tile and user provided. User provided is very, like, you know, if you need to integrate a Samba server or email servers where the user credentials don't change and you just can use it as a dumb end point, well, just use it as it is. You don't need a special offering. Whereas with service brokers and custom tiles, you can have more interesting use cases, like you can implement chargeback model. Like, you know, I want to know who's using my service so that I can have their cost center and then have a billing report every month. I want to know the usage patterns. I want to run some analytics and see, like, you know, who's using my latest version versus version one, version two, like, what's really the feedback rather than going person by person and doing. With a PCF tile, you can interact and with the operations manager and really have a portable cloud offering. In more details, like where you would see and why you can use a specific service broker. So, like, this is really the five APIs which I mentioned. So you need to have a catalog offering. Like, you know, if I'm a new applications and I don't have a person to inquire, then this is the end point where I'll check, okay, so what's the service theme, what's the description, which plans are available and how can I create, like, what requirements do you need? Then once you have that, you can create a service instance. So, like, you know, I have the catalog, I know the broker, I know the plan, I know the parameters, I can create, so I can submit that put request to put a service instance with a name, with all those parameters. The next one is I've created that service, but now what I want to do, I want to consume it. So bear in mind, the service can be one to many associated. So I can have a database that it's used by two, three applications, or just one. Or I have a messaging broker, which is, again, used by one application or by multiple application. It's really my use case. So that's where, like, I have this offering where I can bind an application to a service instance. And of course I can do the reverse, I can unbind it. And then, ultimately, if the service is not needed and I want to free the resources, I just delete it. So far, it's clear, like, it's very simple API. So this is the API that I, as a client, would use interacting with the service broker. The implementation details will be part of the service implement. So, like, you know, it could be, you know, if I'm provisioning a database, then I will have, you know, have to create a table space, have to create the schema, have to create the user, or in my case, with Amazon S3, what I'm going to do is I'm going to create a bucket. I'm going to create an IAM user. I'm going to put a specific policy on that bucket with that user so that it's being able to create access. And then, for the client, I will allow it to upload and then delete, you know, images or files on that bucket. So those are the extreme points you will implement as part of the service broker in the relationship with this approach against processor? So this is the API, the way I interact. Now, when, like, the catalog is really a information service, we'll go into the code very shortly. The creation, it's really how I reserve the resources. Or what do I do in order, you know, the client expects for me to create a database with a certain SLA, let's say 512 megabytes, that I need to create that, right? So let's go quickly. So I mentioned the Cloud Foundry, right? So I have the demo working, so I prove it to you. Now I go and ask the demo gods to be very easy on me and allow me to do that again live. So I have these applications. I'm going to delete the sample up. How about now? Can you see? Yep. So I'm just doing, I can do either delete or D. That's the shorthand. So I'm saying, like, please delete this application force. So it goes and deletes. I then have the services, right? So I delete the service, delete service, or DS, and say, OK, delete my service. Again, force. And then in the meantime, I'm going to look what's. Can you increase the performance? Yeah, just a moment. So I'm still going to concentrate on the app. So now I want to disable the services. So earlier I enabled the service access. Now I'm going to disable the service access, right? So I'm now going and cleaning up the environment to have a clean new environment. I'm going to delete the S3 broker. I deleted the broker. And notice I still have a database. So let me delete this database as well. Now that's easy, right? I could have scripted, but I just wanted to show you that everything is API driven. So I can easily go with a CLI and order and clean up everything myself. And then if I go into my marketplace, remember there used to be a S3 offering. Now it's gone because I deleted it completely. I'm going to go back and just explain you what I'm going to do in simple words. So I'm going to demo the create this S3 service broker. Then I'm going to extend a string boot application to consume the service. And then I'm going to deploy the sample with that library so that I really don't do any configuration. It's just like, as I mentioned, a template. Let me just, I mentioned the template. So are you guys familiar with a template? This is a design pattern from Gang of Force. So on top, you have the definition by Wiki. So in the template method of this design pattern, one or more algorithm steps can be done overridden by subclasses to allow different behaviors while ensuring that the overarching algorithm is still followed. Pretty complex. Now the below one is the definition of a template in an open office, like a document. And this is much easier for me to understand to be fair. I template what I would expect. This is a model, how I create other documents on top of it. So for example, if I'm going to create a new invoice, I have a template with the logo and then the footer of my company. And then I just write key in the numbers into that template. And then I create a new invoice. And this is very easy to relate. So I think the same if we're applying technology where a lot of it, it's really having bridging that gap. And if you just go your way with buzzwords, like though you sound very smart and people are fearful of you, like they don't want to go into a debate, like you're not helping anyone. So really you need to put yourself in the shoes of others. Really explain with their terminology, especially if you're talking to the business with an IT ops, use their conversation, have empathy and explain so that you both get benefit from that discussion. So this is the way you create that service. So I think to your question, like what will happen with a service broker that is like MySQL? So you have this MySQL broker and then this MySQL broker will have different plans. Let's say a paid plan and a free plan. The free plan will be a shared schema into an existing database, whereas with a paid you're actually provisioning a new database, a new virtual machine on demand. And the way you interact is like, okay, so you create the service broker via the catalog because you need to know what's the service offering and what's the API and how to interact. Like every service broker will need a specific set of parameters. Like when you're creating a database, you need to give it one set of parameters. When you're creating a messaging, it's a different set of parameters and so on and so forth. So then you have inquired the marketplace, you create the service, you bind the service, very much the same and there's this link. So I'm gonna share the slides. You can go again and look through that docs. Very useful. Read the docs. Now how it works in terms of just like a graphic. So from my CLI, I'm gonna say, please create this service, which is hitting that rest endpoint, which talks to the Cloud Controller. The Cloud Controller then communicates with the service broker and gathers all the parameters. It knows the user and I have the privilege. Like for example, before that, it can verify like I'm just an auditor. I cannot create services or I'm not allowed access to that service because it's paid and I am just a FEMA user. So all of those will be done as checks before and it doesn't have anything to do with the service broker, like the contract. Like I can have different checks in between. Then I reserve the resources, like if this is the data, then I bind the service. So that's where I actually obtained the credential. There's really no manual handoff where I will, okay. Now, if I would look at service broker and give you more examples, like you have them as a service and that's where I saw the rise of Cloud offerings. So like you can have New Relics and Read, Mongo Lab, ClearDB, which are services available on the Cloud. So when you provision them, they're basically running in a different data center where you can have on-premise deployments. So similarly to your Cloud Foundry installation which is sitting in your on-premise data center, you can create via Bosch a virtual machine or a set of virtual machines that will build that service offering. Yep. From the credential part. Yep, so let me show you some code. So remember I said catalog. So I have this catalog service which is really how it's implementing the underlying. So it's code. It says like, okay, get me this catalog and then give a service definition. So if I go, I have a controller which is a RESTful controller which answers to this API context path. So I'm like V2 catalog. So that, you know, Cloud Foundry, when I add this service broker, it can add it to the marketplace. So you see in this controller which is really implementing the REST implementation, I use the service which is the underlying business logic. Now, I said previously like, you know, in terms of the implementation, for my S3 service, let's say if I'm gonna create a service what it's actually meaning to do, right? So when I'm creating the service, I'm using the Amazon S3 JDK or not JDK, the SDK. And then you see I'm creating a user with my application ID. Then I create an access key, which by the way uses the public and the secret key so that I operate with the Amazon S3 part. So this is more on the operational side. So here I create a user, then I create the bucket, then I add the user policy. You see here? Okay, let me just, you see here? I attach the user policy and then I do all that customization so that, you know, the user or when I create that service, I create it in a multi-tenant environment, but applications from different services, they will not clash with the bucket definition. So they will not see each other pictures and there's a policy clear so far. I can go in more details, but they just like think that this is suffice just to go in terms of what's the contract. Now, if I go into service brokers, this is actually the application. So it's S3 service broker and I'm gonna deploy it on Cloud Foundry. You saw it before. I'm gonna just redo that again. But let me explain one thing. So you remember I said, this is a Spring Boot application. I'm gonna deploy it to Cloud Foundry and there's definitely some metadata that I want to specify. For example, as I create this broker, there's some credentials or there's some persistence that I want to do. Like for example, I've created a service for you. I want to know that when I bind this application, I bound it to this. So there's some persistence that I need to do. So you see here in the services, I'm expecting a dependencies. I'm saying I will need a service that goes by this name, you know, S3 broker DB. I have this artifact which I built, which is in this folder and I'm gonna use this application. I'm gonna require 600 megabytes. It's a Java application. So if I do the build packs, right? Remember when I showed you the three components? Like I can easily create a service broker in any of these frameworks. Like Ruby, Python, it really doesn't matter because the contract is rest. It's really language agnostic. So far so clear. So now if I inquire my marketplace, I say, okay, so I have a Redis. That's not a database. It's a cache. I have a RabbitMQ, which is a messaging service. I have a MySQL and I have two plans, 500 and one gig. Let me just go ahead and create it. So I'm gonna create, yeah, okay, yeah. Create the service, get the service, the plan and the name, creating it. And then I just do a CF push. And then I'll just describe what happens. So it's a new application. There's a new route. This application will be usable on the internet. Currently it's local deployment, but the same will be executed if I'm gonna use our public cloud or let's say on-premise. It's gonna still create a route so that I can access that application. There's a few things that happen. So I'm uploading then the bits. I'm binding the service. So this is where the exchange of credentials between my broker and the MySQL database. Then it downloads the Java build pack and then immediately starts to do some preprocessing. So it noticed that I need a JDK. It noticed that I need a memory calculator and then a spring auto configuration. It can do even more. Like for example, if I would add monitoring, like a new relic or I would add an agent that will need to do logging, it will add all those dependencies. It just for this example, I'm not gonna use any of those extensions. But suffice to say from the operational aspect, I can create that governance where I can create a template in how I build and run all my application in a development environment, in a test environment or production environment. So it built a droplet. So I uploaded the artifact, which is the compile, the jar file. I've added all those dependencies like the runtime and then I compile that template so that if needed, I can actually scale it. In this case, I don't need to scale, but if I would want to scale it, it's very much like this CF scale as tree broker. And I can say the number of instances and scale to two. I can say the memory. If I want to scale the memory instead of 600, I can give it one gig. And I can give it the disk space. It's gonna be all the same. I can do it. It's really no difference. So now I pushed it. It's available under this URL. There's a default username and password. It's admin, admin for my application. It says that it's up. And let me just go V2 catalog. So you see, I immediately have a description. And because I'm not passing header parameters, like I'm not actually doing an action, it just gives me a default. So I'm missing the version. The broker expects a contract for a specific version. I can have different service offerings. This is why it allows me to do these service upgrades for the SLA. Now, you notice if I do marketplace, it's not there. Though I push the broker, I need to inform the Cloud Foundry or the Cloud Controller to create this new service offering. And that's where I can add more specifics. So I can enable the access for a specific set of users, for a specific organization, for a specific space. And that's where I can do more of the management aspect. I'm just gonna go and enable access for everyone. And Amazon is available. Now, what's gonna happen next is, so I have my S3 service broker. Now, I wanted to show you the ease of use for the application. Now I said that I'm gonna do auto configuration. And I'm creating this Amazon S3 template and auto configuration because I really want to allow my developers in the 20, 80% of rule that if you do have this access key and key secret and you have this bucket for application defined in your environment variables, then you can immediately use this S3 connectivity. I'm gonna create for you a connection with the S3 API. You just need to have these dependencies. And then the S3 template, as I said, it will have these credentials. And then it's gonna be able to operate with it. So I'm gonna be able to get an object by the key. I'm gonna then be able to get the credentials so that I can authentify, right? Like it's a really download upload exercise. Then I said I'm gonna create a Spring Boot Starter. Now the reason I want to create a Spring Boot Starter is do you know about this website? It's called start.spring.io. So it's very similar like how you do the Cloud Foundry marketplace and you get service offerings. This is sort of a marketplace for developers, you know? Like if I'm a developer and I want to interact with a messaging queue or a database, like I really can go and say, I'm gonna build a web application. I'm gonna build my SQL application who's gonna interact with JDBC driver. I'm gonna say, you know, some messaging. I'm gonna switch to the full version. Why? Because I wanna show you. So like for example, I can start building my pizza from all these various components. So I can build security. I can build rest. I can build hate OS. I can build rest documentation. I can build a template. I can build these various SQL engines. Like, you know, I can do it a simple JDBC or I can do it via Java persistence API or do it via jock, which is Java object-oriented querying. And then I can have cloud components. I can have cloud discovery, cloud routing, and this is all clients. And when I'm creating that starter, I can actually add a checkbox. Like I can literally extend this starter project and then add an offering into my business and say like, okay, so if you need to consume S3 or Amazon S3, then just click this, add this dependency to yourself. And like for 80% of the use cases, you just don't need to do anything, okay? So if you look at the starter, the starter just add this auto configuration. So then in my application, notice I don't have any dependency on Amazon, right? Right? I'm just using this starter, which is auto configured as a dependency. Now this solves a couple of easy going. As I said, it's a template. And you know, for 80% of the use cases, you know, it's dumb, but it will do the work. I will get the credentials, I will get access to the bucket, the policy will be enabled, I will get everything provisioned by the environment. And then in my application, I can actually do what it's supposed to do, right? So it's again a Spring Boot application. And then I just notice I don't use the S3. I'm just depending on that Amazon S3 template. And I'm saying the container to initiate it. If you look at it, I'm not creating it. I'm not giving it the credentials. I'm not doing any of that operational aspect. So someone else will do it. I just know, well, I need to use it at the runtime. If I'm deploying it to Cloud Foundry and there's this service broker, then the template will read the credentials and then I will be able to access. And then I just, this is my contract. I literally just depend on this Amazon S3 template. Let me show you just quickly what it was really that auto configuration, because I think though I understand some of you are not experts in what happens if I do not have Amazon. So the configuration is being very smart. It's like saying, okay, so if you do not have this being Amazon S3 template, if you do not require, and if you do not have these property files, just like don't do nothing. Don't explode into my face because I miss the dependencies. So that means that you probably don't need this server software. But if the developer needs to do it, then it will have an exception and then he will add all these dependencies at the staging phase, not when I'm running it in production. You can put the memory dependency on the screen. If you... Yeah, but you saw the way it's being defined is just if I have this Amazon properties, which is enabled, and someone passes it to me, like let me show you, like, I'm not, like in my application, I'm not filling these properties files. I'm really depending on the environment to inject those properties, to manage it. So the server is going to inject the username, username, keys, and the username. So but this application itself, for example, if it is a, the service name is specified in the client but don't forget this service broker, as part of its logic, when I showed you earlier, it's creating a new user for every service instance. So when I'm creating and provisioning a service, then it's creating that user. So when I'm gonna delete that user, it's gonna delete the resources. So then it just removes that explicit binding. So when I move to a different, let's say region, like I'm deploying this application, it's in this region. I'm deploying to another region, it's gonna be a different contract. I don't need to manage it myself. Someone from the operational aspect will just have a configuration in the broker, which will be true for all the other offerings. If I as application developer, then in my application, I need to code specific code and saying like, okay, so if the host begins with Southeast Asia, then I need to have this explicit. If it's from US, then I need to do this. So you see like, you start adding this and soon enough you are in a rabbit hole. It's just like add different ifs and it's very hard to test. I haven't showed the test because I don't have enough time, but it's unit tested. I build this project. The testing is just gonna consume more time. So okay, I enabled. Now I need to create the service broker. Okay, so I'm gonna create a service and saying like, from this plan, S3 basic, name it S3 service. I know you're wondering, let's say, so I have this application deployed, right? If I'm saying the broker, what can I do? Well, I can do with it a lot of interesting things. So I can say CF logs, S3 broker. And then I'm gonna push, when I'm gonna push this application, spring boot Amazon, then here I have my sample in the push. Now it's gonna execute the same steps and bind application. Notice how in a few seconds when the binding will happen, I'll have the logs output here saying that there's an action. You saw it? You see the logs saying like, okay, put this instance and then I have the instance UID from this IP and all the information, right? Now I can do the logging on the applications. I can do the logging on the broker. I can even do something really interesting. I can SSH. And for those who know SSH, I'm inside a container, right? And if I execute top, like you can see this is a container and then the only process IDs that are running is my bash, my top, which is just run, my SSHD daemon. And then really the root is running on the one so that it can run in the privileged access and then just a single process. Like if I exit the top and exit the container, it's very compact. It's really just using what it's need to do. I can as well, I can show you that there's the application. So you can see, in my app, I have the boot, I have the work and then the classes. So everything is there. So I'm in this container. I can do everything it's, so I'm gonna exit. I deploy the application. Obviously the application is no longer having these awesome pictures. So I'm gonna go again, get my DevOps, upload it, and here you go. The application is in a S3 bucket, the end. But anyway, I would like to take some questions or maybe go into more advanced questions or topics that surely everyone has. How do you use everything like the Pisa, everything? So the key, it's provision as environment variable. So let me see if I can do now, hopefully, I do hope. So I haven't enabled the actuator, but now the problem is this is recording. So I have my Amazon keys there, so I don't want to disclose them, but it's definitely there. Like, let me show you if I go to my Amazon. But even if I do the CFN, it will show the keys, right? So I was hoping, so we do a smart thing. So if you do have the actuator, and then the key ends with a specific suffix or starts with a prefix like password key secret, then it just shows you the asterisk. If I do the CFNV or I go into the environment variables, it's gonna show the black on white or white on black. That's my terminal. So let me just show you. So you see, I run it a couple of times. So I think it's this one, no? This one? So this is the one that I just uploaded a few minutes ago. So there is also the logic to delete the buckets on the previous shortage. But obviously I haven't done a lot. Like for example, I would do better if I would create it via Bosch. And like let me just show you a use case if I would create it with Bosch where it will make more sense. So let's say I have the same MySQL example. So I really want to have a multi-node cluster because then I can do load balancing, right? I can have that high availability. Like everything about, you know, if you're going to enterprise, it's really about enterprise-ready functionality. Like, you know, how you manage the access, how you do the backup to upgrade. So like for example, in this case, I can have my MariaDB server in three availability zones. You know, three standalone virtual machines. Then I can have a proxy and then I can have a load balancer that will be able to load balance depending on which node is available. So it could be around robbing. It could be some smart logic. But then what also happens is there's data replication amongst the nodes. So I have, you know, 300%. So there's failover functionality. There is like all this network marketplace that once I build that Bosch tile, then I can really sell it as an offering on the marketplace. Like for example, I have, for example, CloudBees, which is Jenkins, which you mentioned. So like, you know, you can have it. You have Datastacks, which is Cassandra. You have GitLab, which is a Git offering. You have JFrog, which is Artifactory. You have ELK, which is Elastic Cash Logstash and Kibana. So you have different offerings. So this is really the catalog once you go and build an application for real users, right? Then if you build it as a custom style, then you can have installation and configuration. Like for example, you know, when you're deploying it on Amazon, like and you have a MySQL, you can have an option to use the RDS rather than just provisioning, you know, and building the whole MySQL instance by itself. So you can have those options. Then as well, you can have a configuration where you can control the availability. Like, you know, I want to have a cluster of three nodes, five nodes. I want to have two load balancers, three load balancer. I want to have nodes of like one terabyte or 500, you know. It's really options that I configure. And then that's where like the whole platform operations and the platform engineering come into place and they look and take care of it. Like they can do capacity planning. Like as a developer, you know, I hate when my application is down because there's not enough table space or there's not enough space on the disk because of logs. Like it shouldn't be done by me. But if I'm having my talker file, yeah. That's like, I'm pretty much stuck. So then I can scale it horizontally and vertically. And you know, and on the other hand, is then I can go and do proactive. Like, you know, ultimately there's patches that needs to be, there's security vulnerability that is disclosed. And then as part of my network, I can do rolling releases. Like I say, well, you know, I've just patched the version. Please, Mr. Customer, upgrade because there's this security vulnerability which is a zero day bug. You just, I just patched it and you just need to do a click install. And that again, from a developer perspective, nothing changes because it still uses the contract. But from an operational aspect, I still have to do all those exercises. Is it clear? Ask more questions. I feel that I talk too much. And like, you know, just me telling myself that, okay, so you know that, let's. So I would rather answer questions that you are. So maybe someone from that side, what do you guys think? Guys and ladies. Was it a useful presentation? I do hope so. You still, you came all the way Friday. What's the difference between the commercial Kafka recovery and the open source Kafka? So the core, the API, it's all the same. The commercial offering is still using the same elastic runtime. Commercial offering has this all other services. Like, you know, if you're planning to use data Kafka gem for our API gateway analytics, this is only available as commercial because this is offering that we give SLA support, we upgrade. So really the marketplace is the big difference. The ops manager, ops manager, yes. Like we do have, you know. Yeah, let me actually show you. So, you know, I mentioned that. So for some reason it's people to exit. How do you exit? I think there's probably a pop up. Can I stop this? Okay, my presentation has gone wrong. I hate when that happens. No, you just, it's probably like a pop up. Has got that focus. And then that pop up is out of the screen. So, it's probably on the display. I forgot it. Any more questions? I'm gonna show you the public cloud and I do advise. So like if you go now run.pivotal.io, you can sign up for a 60 days free trial on our public cloud offering. And you can play with the marketplace and you can push applications. So if I go to run.pivotal.io, then I can log in. So you just need to sign up and there will be an SMS just to confirm your identity. We want to avoid bots, then I sign in. And then this is the UI that you can work. So, you know, like the marketplace, this is a multi-tenant for APJ. So you have multiple spaces. You can see the number of apps that are working. So for example here, you can see that there's six apps that are stopped. There are 31 apps totally in the worker. There's like they're using 32% of the quota. There's the services. There is a billing report. Like, you know, this is on the public cloud. You can definitely have the chargeback model and like you can have, you know, for this amount who is using which spaces. You know, if I'm going to the development, I can see per application how much time it was used. So this is all by the service broker and it's using this information. Now, if I'm going to a development space, I can see the applications. Yep, yeah, it's the same UI. And then this is the marketplace, which is available on the cloud. Because it's on the cloud, it uses cloud offerings, like I said, but on premise it's going to be the same. So for example, you know, I'm going to use. So this is an application that I'm using. It's an application that I've done for a long, long time. Yep. Yeah, we do have Windows applications running. We even have a Bosch that it's able to install Windows servers. So that's definitely available. But that's the application they need to, like as a matter of fact, they need to run on the client. But we can provision Windows servers. So that's probably it. Any more questions? We're on top of the hour and I don't want to keep you waiting if you don't have to be. Thanks everyone. I'll make available the slides and I'll post it to the meetup. So I look forward to see you next time. I'm going for a small surgery, so I'm going to be off for a bit, but definitely looking forward to say hi to everyone. So thanks for coming. Now it's Friday and good to see you all.