 So thank you very much for coming to this session. We will discuss today about distributed service bundles for Cloud Foundry. My name is Krishanu Viswas and I am one of the product and engineering manager at SAP. I work from SAP Labs India. So next 30 minutes we will discuss about the idea of distributed service bundles, what it is and why are we basically talking about this topic, what's the motivation, what's the future of it and where we are and what's IJ's all about. So today I think the applications are not merely a cloud client server anymore, right? All the applications are kind of distributed in nature. So Cloud Foundry gives us a model wherein if you have an application you can bind it to a backing service and that's how your application can talk to a backing service. So this is via the service broker concept that Cloud Foundry has and this is kind of well established. This is working, all fine, all good. But in the enterprise space what we see today that there are more and more use cases for service to service consumption. So think of change data capture pipeline, for example. So the database has a single source of truth in this concept and the change is extracted from the transaction of the commit log. So all the data that comes into your database that becomes the source of the entire pipeline, so to say. And you extract that information out of the database automatically through some eventing mechanism and you push those events as a message to some message broker in between. It could be Kafka or it could be something else. And then you have a set of services which are listening to this particular pipeline and then they take these messages out and do the stuff that they want to do on these messages. So for example this record is inserted and then you want to index that to make it searchable. Maybe all the sales order that you want to show through some queries in an OLAP system maybe. So you have then an indexing or a searching system which will take this event out and then this will make it searchable or put an index on it so that it is easily searchable. You can build a cache out of it. You can build some kind of a machine learning system around these events. And then of course these are different services. You can also put some kind of a monitoring around it. So these are the different services that can actually be hooked into this pipeline and they are all different services and they hook into the pipeline, they extract their data and then the process on this data. So this is change data capture, kind of a pipeline. Why are we talking about this context of distributed service bundles? The question here then is that if I have so many of those services which are kind of working on the same set of data, can I just think of in cloud foundry terms that these services are kind of deployed together, managed together, right? So that is where this idea of distributed service bundles comes in and we will talk about it in a moment in more detail. So this is, if you're more interested, just visit this debitsium project from Red Hat. They are offering a lot of DecodeBuff for different databases. That you can put it along with the database and then it can extract this database evens out of it and then, you know, it can give you the information in the pipeline the way you want. You can also read a little more about LinkedIn's database infrastructure. They're also kind of doing this similar kind of a thing. To make this concept a little more clear, let's talk about a simple blogging site. So what happens is you have a blogging site and then you ingest blogs, basically, right? So you have the data and then you have the metadata that you want to store into the database, right? And from this database, basically this evens gets emitted and then you have certain search mechanism implemented by means of, let's say, elastic search, right? So it will index all these blogs based on the metadata, on the content, et cetera, so that other users who are searching for it can get it easily. Another service that is probably looking into this changed data pipeline is probably the aggregates. Maybe it's a Spark service that is hooked into this pipeline. It takes it out. It does the aggregate, you know, kind of keeping information of who is writing blogs, how many of them, and then things like that. And then maybe you want to apply some kind of a classification or clustering on top of this blogging information that is coming in, maybe an ML service, a machine learning service is running there. So what I mean to say here is that there are many services which are kind of hooked into this pipeline and these services are all working together, right? So the question is now if we can have a system in place where all these services are kind of managed together. Yet not sacrificing on the flexibility part of it, I should be able, because tomorrow the technology will probably change. I might need to bring in another service in, take some service out, maybe Spark is out there to maybe something else. I should also be able to do that. So this is the motivation. So a set of service, then what do I do about it? That's where, you know, the thinking of composite services comes into the picture. So in Cloud Foundry we have basically each backing service in itself is kind of distributed, right? And then a set of services, if we can just bundle them together, creating a composite service out of it that is deployed, undeployed, updated, operated, and monitored and scaled together, right? And thereby enabling inter-service communication. This services should be able to also talk to each other, allowing credential and message exchange between the constituent services. So from Cloud Foundry's proven model of app talking to a service, we are now talking about service-to-service communication, a set of services deployed together. Be able to, we should be able to flexibly modify this composition over a period of time that this bundle then we can bring in new services into it and can take maybe some existing services out of it. So it should be flexible enough. And the composition is the key here, allowing bundling and varying of individual services. So that's the central idea around distributed service bundles or the composites. And there is no such mechanism today in the Cloud Foundry backing services world that realizes this. We have tried to build a proof of concept around it and that's what I'm here to present to you. So what we need, and that is where we come in, we need an automated way now to provision this services as a single unit, right? A bundle, where in the varying of the services is automatically taken care of and controlled by the service broker. So we need a service broker now and able a capable service broker. And that is where it comes to service fabric. If you are not aware of service fabric, I've just put up a link there, have a look. So this is a proposed, the service fabric is a proposed project for incubation now. I think you have heard in the keynote about service fabric, SAP's movement towards supporting multi-cloud including Azure, including GCP and AWS and OpenStack. And also of course, service fabric is battle tested and being used within SAP and for SAP customers for quite some time now. On production. And service fabric is able to spin Bosch based production-ready services as well as Docker services for developers only. So what is service fabric? It's a set of tools which can be used to provision, manage and operate backing services at scale for cloud foundry applications, right? In an automated and managed way on a variety of cloud infrastructures. So we needed this broker and we wanted to ask this broker, hey, it is no longer a CF create service and it's just one service instance that you have to create, but now it's going to be multiple of those services and how do we kind of do this multiple service? We manage and operate them is something that where we needed service fabric. Just a little more on the service fabric so that you get the idea. So service fabric, usual, you have the CF CLI and with that you say CF create service and then the call comes to the central component you see there, the service fabric broker and service fabric broker then based on the request that's coming from you. Either it spins, let's say, a Bosch based service, maybe let's say, it's a Postgres or a MongoDB or maybe a Redis or a RabbitMQ today or it could be one of the Docker services of this services. Docker services are like single node, it just comes and go away, no SLS, nothing, but the Bosch based services, they come in clusters. So Postgres SQL, it has masters, it has the slaves and it's a proper setup with the failover given. So that's what it does, same for MongoDB. Based on the request, it either goes towards the Bosch or it goes to the swarm manager. So the advantage that we see here with the service fabric and that's the reason why we used we chose service fabric for this particular use cases is that it prohibitions manage and operate services at scale in an automated and managed way and then it enables seamless application development and deployment experience. You start, your developer in your company, it starts with a Docker service and when he's comfortable, he has worked his application out against this Docker service, let's say it's a Postgres service, the database, just came out immediately when he started developing his application. It all works fine now, then maybe you want to move more towards a production grade service then you'd probably need a Bosch based Postgres in that case. So it's kind of a gradual elevation of a developer developing his application from a very nascent state to a production setup. It supports this transformation. Multi-cloud, you don't have to care about underlying which particular IS you are running on. It could be AWS, OpenStack, Azure and GCP. For the developers, it all looks the same. He won't suppose, Chris, he just says that I want it on AWS or next time I want it on Azure or GCP. That's it. I think service fabric does the heavy lifting of managing that. Integrated monitoring, alerting, this is very important. When you have spawned, let's say, hundreds of this kind of systems and then you have hundreds of virtual machines running around, right? Now the question is, how is my Postgres doing? How is my Mongo doing? How do you monitor them? Audit logging is important. Who is inserting what into your database needs to be tracked and all this is all integrated within service fabric. And as I mentioned before, it's battle tested. It's used within SAP. The security is of utmost importance. Update and upgrade of the systems are important. So this has all been taken care of within the service fabric. Hence the choice of using service fabric for this scenario. Now that takes me to the demo part. We have a small demo showing what it means to have something like a service bundle on this. My setup looks like this. I have an account on AWS where I will be logging in into the jump box and then we need, of course, the Bosch director which will spin the cluster for us. We, of course, need cloud foundry wherein our application will be running and, of course, we need service fabric. The Bosch releases that we've used in this demo is like Kafka, ZooKeeper, and Postgres service fabric itself is a Bosch release and end release. The demo scenario goes something like this that we have an app which is basically ingesting tweets and which is pushing these tweets into the Postgres and so it generates some kind of a transaction log. And then there is this Debitium decode buff sitting on the Postgres node which is kind of pushing this... decoding this wall messages and pushing it into Kafka. And then we have a sentiment analyzer app sitting there hooked into Kafka and trying to do some kind of very basic sentiment analysis. That's not the problem we are trying to solve here. Just wanted to say that you can hook up this kind of even apps or services as many as you want into this queue following this change order capture pipeline that we have seen and then you can do some kind of an analysis on top. So, very basic. Let's get started with the demo. Let's say... Let's make it slightly bigger here. So, if you see now I've already logged in the marketplace if you look at you see that there is a service called distributed service bundle and then it has a plan called standard. There are other services as well. For example, MongoDB, RabbitMQ, they are independent and individual services but this one is a composite service that we are interested in now in this. So, what we do now is we try to create a service. So, CF create service and then the service name we need the plan and let's say that this is our CF Summit Bundle 17 instance. Okay, so I have to check on this but for the sake of time I think I have prepared an instance already maybe we can go ahead with that. So, this instance is already there and you see that demo instance and this is of course this distributed service bundle. This particular service instance is created already for us. So, let's take a look at CF service and then maybe this demo instance let's see what details it has. So, it says that the service is this and from this the service instance is created and of course these are the services you have in this bundle. So, this Postgres, Kafka and Redis and if you look at the composition now in this system we have just the Postgres and Kafka. So, what we can do now is we can see where our application is and this is our application basically this application shows the sentiment as I said, the sentiment analysis and the other application which is ingesting from the Twitter that is already running. So, let's see that and this is looking into the hash tag CF summit. So, I basically, you know, refresh this. We see that there are 1542 positive comments about it and there are 372 negative comments about coming in but this analysis is not important. I mean it is also sometimes giving you a wrong result but yeah, basic sentiment analysis that is happening following the same change that I captured and what is important here is that that we have kind of deployed this entire application together the services together so that it makes a service bundle. Now, so let's see we said that, you know, this service we should be able to manage monitor it together, right? So, we should be able to update it together, right? So, what we can do is we can look at the monitoring dashboard and then you can see this is the monitoring dashboard where you get to see all the services together you see Kafka, you see Postgres and then you see basically so you see this is the Kafka system which is running inside there's a Kafka system which is running inside this is the Postgres, the two node Postgres server which is running inside so basically it's a composite that you are trying to look at how my composite is doing and you see the CPU system here the CPU usage likewise you can see the memory usage of individual systems here and yeah, so the idea here is that can we now, since it is in a POC state at this point in time we were thinking and I was interested in taking your opinion and feedback on do you think that it makes sense somehow to think in this line do you see that you have use cases around managing this kind of services together in your company somehow then we can of course take it forward you know, can think of you know, collaborate with you writing some kind of a standard specification of how the services can be can be managed together and things like that so that was basically the idea so, yeah I think that was pretty much I have I can show you a little more on if you are interested in for example let's say that this particular service now has Kafka and Postgres running now let's say that you want to bring in a machine learning service which needs Redis as well so how do you bring it in it follows all the CF constructs so say you say CF update service and then you basically give the service name which is the service instance ID and then you pass on basically I have I'll show you the file here also see if some it I pass a JSON I pass a JSON file so I think it is add Redis.json right yes I meant update service okay so this is started now if we say CF CFS and then you see that the update is in progress so in a moment what you will see that the service composition which was made up of Kafka and Postgres before now will soon have Redis also inside so this way you can also remain flexible kind of bringing in your new service inside and take the other one out and the entire varying and everything else is being taken care of by service fabric extension that we have built here yeah so this is it pretty much that I wanted to show and talk about distributed service bundles if you have any question or if you have any suggestion on how should this be done because this is at a prototype stage at this point in time we are thinking of maybe it makes sense for larger companies who want to manage a lot of let's say big data services for example together all of them spark maybe Kisandra Kafka together maybe some other companies have different other changes to capture scenarios where in they want to manage and maintain all the services together so just wanted to know from you if you have any such use case then maybe we can talk about it a little bit if this really makes sense can you please for many services at once so basically this is managed by service fabric and this is all sitting on the same subnet at this point in time so within the subnet I think the systems can reach each other and of course the credit hub is something that we can use going forward to keep the credentials together and then everybody has one place where they can go for the credentials and they can pick up the credentials for the service that they want to basically consume yes of course so Elkstack means you have this this Kibana and Logstash and all of this system so again these three systems are again disparate systems but they work together of course then yes it could be a nice use case that these three services are kind of put together but I guess for Elkstack you already have a Bosch release and this you can then this Bosch release can be directly be provisioned directly on the system so you don't have to do any magic there I think this use case will fit more on a set of heterogeneous services that you may have in your company for which there is probably no single Bosch release exists today if you have a Bosch release take it just deploy it using service fabric everything will work but if it is kind of a heterogeneous set of services that you need to deploy that is probably the pipeline you want to support within your company then bring them together as a composite and then kind of try to deploy this so they are all independent Bosch releases and then create your pipeline by deploying them fabric will take care of kind of deploy them one after the other and ensure that internally they are able to deploy each other and they are kind of managed together once you run the update then all the software is kind of updated we can think of a scaling mechanism also going forward monitoring you saw a very basic example we can also see that how this composite so we are not talking about one particular service now at this point in time but as a composite this service how is it working now is it healthy is the question right so we are more towards such things so any opinion any feedback on if we should be using this yes please each separate service we have right but I believe there needs to be some glue that puts all those things together making it work together so you need to have a postgres building support it's all transactions that needs to be adjusted what is this where does this glue come from there are different components involved one project which is very interesting at this point in time is debitsium from redat which basically provides a lot of adapters onto the database that basically you can hook this up it is also there on my slide and these kind of they use some kind of a decode buff basically because the wall files the right ahead logs or the commit logs are binary files they are not understood outside so each database provider should provide some decoder that can understand this so this decode buff they basically read this data from the wall the transaction log and then kind of decode it and creates events which is pushed into Kafka in this case and then all other services that you have in your composition kind of hooked up into Kafka and they just extract the information out of Kafka and then do whatever they want to do they are meant for the rest of the glue lies with the service fabric where this message passing and the credential exchange and all of this is done by service fabric you can of course do that yes so we don't want to lose that capability because you want to update Kafka to the next version but not necessarily postgres but you should also be able to update it together right that's it yes thank you thank you thank you very much thank you