 Yeah, so welcome to the presentation. So today I'm going to talk about the surface-sized Swift with IBM Ketua with OpenShift. So Swift is a programming language developed by Apple. Swift targets mostly on macOS, iOS, watchOS and TVOS. Swift is really lightweight and fast. Super fast. Latest version of Swift is Swift 5.1. Back in the 2014 when Swift initially got introduced, it's supposed to take over some of the responsibility for Objective C. Objective C is a legacy language for iOS. So at that time, Apple come up and say, hey, Swift is the new way of developing iPhone apps and iPad apps. It's a descendant of the next generation of Objective C. The beauty of Swift is there's no pointer. You don't need to worry about a memory allocation, memory management. Swift is also a new functional programming language. You can pass a functional object into another function as a parameter. And as a matter of fact, Swift and Objective C could coexist in any iOS app using the bridging header. And Swift also come with the UI Automation Toolkit in Xcode that allows you to record and generate automatically automation Swift test code to test against your iOS app. Swift usually work in Xcode and also work in VS Code in Linux. So it depends on your computer. You can install Xcode or VS Code. So let's talk about why we want to talk about this with server-side application. So one of the most common problem is that iOS developer working on mobile client team do not understand. They only understand Swift and Objective C. When the mobile client team needs to work on a surface feature, a lot of times they don't have any idea where to start and they need to wait for the surface team to do the work for them. Most importantly, there was no co-sharing between the client team and the surface team because of the different languages and different technology stack. Team members were siloed that they either no fun end or no back end. So they also don't share the same release cadence. So in order for the client team to wait for the surface team to have a new feature come in, we need to wait for the next release. So where do we start? If we could start sharing code and architecture between the client and surface, they would solve some of the problem. We could leverage Swift as a bridge to bridge against the client and surface team. And also we can leverage some of the nature of Swift language to make the back end surface more lightweight and faster. So this is how my IBM Kituwa come into place. Kituwa is an open source framework developed by IBM back in 2015. Mobile developer could use the Swift skill to build back end web services, supporting web API, integrating with web sockets and open API and databases. So you can think about in this picture, right? Kituwa breached the gap between both the front end and back end. And also looking at some of the performance analysis from the IBM website about Kituwa, you can see that this is a chart about the performance of application. The response time of Swift is amazing, right? It's comparing to Java to JS to Ruby. It has the fastest response time. And the memory usage, same thing, right? Swift has a really low memory usage comparing to Java, to JavaScript and Ruby. And as far as for developer productivity, you can see that Swift basically has the highest productivity and also has the highest performance in the app. So which make it a preferable language, right? Swift, lightweight, fast performance, low memory usage, front end and back end portability. So think about if you manage a development team, right? You could manage the other source code coming from the Swift Xcode project, right? It would deploy to the client on the iOS app, deploy to the Swagger API, generate a Swagger documentation, deploy the service to Kituwa. And Kituwa, as a container, deploy to open shift, right? So that's the beauty of using Swift Kituwa. Everything comes from the single point of truth from the same Swift project. So as we said, open source Swift, Kituwa is only just one of the framework coming out from open source Swift. Perfect, Vapor and Selvo is also other framework that were there to support Swift, surface-sized Swift. So Kituwa is one of the more popular one. So this is the Linux architecture of Swift. So this is the Swift one time. So on the base on Swift, we have the standard library, the foundation, the Swift foundation and the dispatch, right? So you can think about this as a Linux platform container. And then when we extend that into the surface-sized Swift, everything's the same except we now have a component called server API that support making API call through the router, through the network and talk to the Swift library. And as you see, you know, Apple Swift also have integration with SiriKit, with Apple Pay, with augmented reality, with machine learning and with the iTunes, right? So if we use surface-sized Swift, we could get some of this feature for free, especially SiriKit. I found it's really useful when I can have my Swift surface, talk to Siri, Siri can do the work for me and then send me a notification back to my surface. Talking about Swift package management, there are two choices. The first one is called CocoaPod. The second one is called Carfish. CocoaPod is one of the more popular one, right? It's a dependency manager for Swift and Objective-C. It contains over 69,000 libraries, used by three million apps. I hope you scale your project. If you go to CocoaPod.org, you can find all the available libraries for Swift. To use a CocoaPod, it's very straightforward. You start with a pod file. You do pod in need. And then you add the dependency, in this case, AnimalFire. AnimalFire is a dependency for making network calls. So if I need to make an HTTP call or using AnimalFire, I can add pod, AnimalFire, and then a version number. And then after your pod file got updated, you call pod install. And then you go to your Swiftcast and do import AnimalFire. Then you can start using the API and libraries. Creating the Swift project is also really straightforward. The key to a Swift project, first you make a project file using the MacDurr and then your project name. Then you go into that project and then you do a Swift package command. You do a Swift package in need. We give it a type executable. And then you generate a package Swift file like this, right? So in your dependency block, you add a package that points to the IBM Kitua Git URL. So that's the first step. After that, you can start acting your HTTP endpoint. So in this case, this is an example of setting up HTTP get endpoint using the router. You pass in the request response parameter. And then next, inside the next is a functional block, right? And then it's just basically doing a response dot send hello world, send hello world back to your get response. So the next step, you hook it up to Kitua, you call the Kitua, add HTTP server, give it a wow that you have identified in the earlier step, give it a port number. And then at the end, you call Kitua.1. Then it will start up the surface for you in the container. So this is another example of a get endpoint, right? So you can see the whole coding structure as a functional programming syntax, right? You pass in request response. Next would be the closure in the closure. I'm going to do some business logic and then return the response. The post API also set up in a similar way, where you pass in the request response, do some business logic and then call response dot send and send back the payload for the for the post response. You'd also have integration with the database. So I'm just showing a Postgres SQL connection here. First, you call the Postgres SQL connection, create a pool, specify the host name, the port number, the database name. And then at the end, you can call database D4 and start the database with that specific specific pool. Creating a table with super straightforward, right? Once you have a database object called book, you can call book dot create table async. And then once you have the table, then you can start creating object inside the table. All you need is to pass in that closure. And then you can call book dot save and then pass in the completion handler. And that would create a data object for you inside the table, inside the book table. Looking up an object is also in a very similar way, right? You can call book dot find and pass in the object ID and the commission handler. So to compile your application, you do a swift dot build. Once it's built, it generally executable inside the dot build folder. You go to build, dot build, debunk my project. And then you can open up the localhost 8090 and see the web page that you just created for your Ketua application. So this is the high level cloud history. So in the past, we started with a data center. Then people migrated to infrastructure as a surface. Then people started doing platform as a surface. And today we kind of go into a serverless architecture. Right? So this is a high level architecture of a typical micro surface architecture. You have a business data abstraction at the lowest layer. And then you have some sort of data surfaces on top of the data abstraction, right? Surface layer is where you will build the Ketua surface, right? The micro surface, the standalone surface. So on top of the surface layer, you have the orchestration layer that make different surface call in order, right? Synchronously or asynchronously during the retry block, during the exception handling, right? That all happened in the orchestration layer. And then at the top most level, you have the monitoring and event management, right? So how do we apply this into our Ketua OpenShift framework? So why do we want to use OpenShift? OpenShift is a distribution of Kubernetes. Optimized for continuous application CICT pipeline, support multiple tendons, contain developer and operation centric tooling on top of Kubernetes, enable development, application scaling, lifecycle management. So this is an example of OpenShift architecture that developer checking code into Git, Git push code into Jenkins. Jenkins one, the deployment CICT pipeline. At the end, it will deploy to the OpenShift cluster based on the configuration, right? You have a cluster for development, a cluster for test, and a cluster for production. So how could we use OpenShift for Ketua? So OpenShift has a S2I source to image procedure that basically can run a Docker image by injecting the application source code into a Docker image and a sample a new Docker image. Using the new Docker image, it can incorporate a base image and the built-in source code, and then it will be ready for deployment. And also S2I process support incremental build and you can also reuse the previous build artifact based on versioning. So going back to Ketua, right? So first, where do we get the Docker image for Ketua? You can get that from IBM com slash Ketua with the latest version. Once you get the image, you can tag the image, push the Ketua image into your Docker registry and then you can run the registry in OpenShift. So the command to start, right? After you have the Ketua Docker image, you do OC new app, specify an app name, specify the Docker image, pointing to the registry that you just push your Ketua image to, right? And after that, the deployment happens automatically. And you can do OC get the list of pods associated with the deployment. So we talk about Image Stream could be used to update deployment when a newer version of the image is created. Image Stream create a Docker image identified by tag. OpenShift can build and deploy surface and receive notification from Image Stream. So for you, you can also do OC import image, right? Specify the Ketua Image Stream, right? And then after you import the Image Stream to your OpenShift namespace, you can start creating the app, also using the OC new app command and specify the dash i as a Ketua Image Stream. So this is the link for the Ketua tutorial. So I went through some of the very high level how to do Ketua, but this link talked about how to do, you know, creating a, to do list in the back end, authentication, session management, template, SSL, TLS, CGI, and how to handle request and response type handler, right? So these contain all the documentation, most of the learning that you need to learn about Ketua. So as a matter of fact, we have a client, Capital One, who is using Ketua for their project. So Ketua, HTTP, HTTPS server, configured to run on their iOS devices and their simulator. So we have a workout API and payback API to track the surface request and response using Ketua framework. That was a really interesting project. And it's the first time we're using Ketua in the consulting business. So also how to, where do we start from developing Ketua application? You can go to developer.ibm.com, technologies, SWIFT. That will talk about Ketua. And this is a GitHub example. So we have five minutes left. I'm going to show you a quick demo, how this works in OpenShift. So we talk about, so we talk about how, how, how, how the deployment works. So I deploy this into our OpenShift cluster with Ketua. And you can see that the container is really IBM com Ketua with the hash code of the image tag. So all I did is running the OC new app command and specify the Ketua image stream. Once it's deployed, you can start doing some of this API call. So I have post month up here. So the first one is really a get call. And you can see that this is pointing to the URL of my OpenShift cluster. I have an API call called hello. So when I make an HTTP get call, it sends me back to hello Ketua starter. The post call, this is an example of a post call that points to the OpenShift cluster. Again, to send me API endpoint hello. And then when you do a send request with the post call, you get back to receive a post request. This is an example of returning a JSON object. So I have an API endpoint that calls JSON. So it will return me a JSON object, you know, company name IBM, framework Ketua and location and all that. And we also have a health check endpoint, right? So each microservice would have its own health check endpoint. So this is also done with Ketua Swift. So when I make a get call, it will return me a status up and then a timestamp and the detail. So this is also an example of, so when I go to my Ketua application, when I go to the root URL, I will see, welcome to Ketua as a starting page on the IBM cloud. Yeah, so basically that's, that's all I got for this presentation. And I have maybe take one, five minutes, okay, five minutes for Q&A. And you guys have any question about Ketua that you want to learn more, or you have any other specific question you want to, you want to ask about Ketua. Go ahead. Congratulations. I haven't know about the Ketua in Swift, you know, technology, you know, there's open a lot of possibilities, you know, to have integration with Apple, you know, big guys and such. So this is a very nice thing. And I saw also that your service was mostly like 10 megabytes of energy. This is really, really fast. Yeah, lightweight. Very nice. But the images are based on you guys, you know, planning or something like to migrate to UBI8, you know, to help, for example, because our products and our base image, you know, the Meteor thing, and I considered this technology with Meteor, I think, I mean, the, the, the enough representation, I don't know if it is IBM thing or Red Hat thing, but if you are planning to bring to Red Hat, and you are planning to migrate those images to UBI8 to how it... That's a really good point. Actually, yes, okay. So, so the question is, when we are talking about bringing Ketua into Red Hat, and we may need to deal with supporting the image for Red Hat Enterprise Linux version 8. So, yes, IBM has planned to support and support some of this new image, and it will be available in the Docker image repository for download sometime this year. Yes. Yeah, this is one of the bigger initiatives, especially now Red Hat is part of IBM, right? So, one of the push is to, like, it's how do we bring the IBM technology together with the Red Hat technology? Like, Ketua is just one example, but you can see, you know, Ketua can bring in and work nicely with OpenShift, but at the same time, yes, you know, some of this configuration may need to, you know, the image and the, you know, some of this lower layer configuration would need to be updated to support more on the, on the Red Hat Linux. Yes. Okay, so you're bringing all the mid-range tools or, you know, this is IBM thing, and not Red Hat, but we use, like, the base image for Red Hat, but at the same time, you know, because there's a lot of IBM thing, you know, in the video, but if you guys are bringing this to Red Hat, are you planning to come, this is Red Hat thing now and follow the game? Because, you know, for marketing and to say, oh, we have, we have a new framework for running on OpenShift, we'll buy, buy, buy that, it's a big thing. Yeah. That's what I mean, not the technical, whether it be market, you know, the brain, these kind of stuff. Yes. It will be, you know, mixing things or actually you guys are bringing to Red Hat. Yeah, so the question is, are we going to bring this technology into Red Hat as a technology, or are we going to mix, you know, between Red Hat and IBM? So I believe the direction would be bringing in into Red Hat as IBM's commitment is keeping Red Hat as a stand-alone, you know, entity with an IBM. So some of this will be, you know, how do we bring, you know, bringing in some of the technology from IBM to Red Hat, improve the integration, being able to support the technology, right, without showing two different names, right? Also from the client's perspective, a lot of time, are they asking, hey, you know, is it an IBM thing or a Red Hat thing, right? So we try to avoid that confusion, right? So, you know, as you see, OpenShift is going to be Red Hat, Ketua is going to be IBM, but, you know, yes, again, there will be more integration, more people working together, more team sharing code together to make the product more successful. Yes. Yeah, for example, if I, for example, I can go to the RedHatch.hatch.com, you know, our container's English pre-posting and I search for a suite, and I saw, like, IBM thing, I made, you know, I opened this, and then I saw the image of this Ubuntu based, you know, this mix. It's confusing, yeah, exactly. Yeah, it is. It's not only confusing, they won't make sure that a lot of people won't be. Yeah, yeah, for sure, they won't be. They won't be, yeah, exactly. Yeah, it's open source, it's all this kind of stuff, you know, it may even bring everything to RedHatch and forget about this Ubuntu thing and know how to get it out. So, it will be a very nice thing, and I guess you guys will be more attracted to it. That's just how I might be more subjected to it. I don't know if you are looking to this, but please. So, we have Swift learning in Aurora now. Yeah. And it's the simplest learning container that will do the work. Yeah. So, we'll hold on to you. Yeah, yeah, yeah. We'll be working to get them more, yeah, and yeah, yeah, as we said, you know, Swift. We educated that they need to do it with other DVI, you know, just sort of the Ubuntu. Yeah, yeah. But yeah, I noticed that, too. The question about Swift Compiler. Yes. It's running on the server side, so it can be deployed in any architecture. Yeah. So, which architecture are supported with the Swift Compiler? The Swift Compiler, what architecture is it supported? Well, it supported the, well, you're asking about the operating system architecture. Yeah. Yeah, RedHatch. Well, I tried it on my local RedHatch laptop, and it works for me. So, my Swift Compiler works okay. But, I mean, I'm running a, it's 64-bit. And, yeah, Swift, as I said, you know, Swift originally developed by Apple to support more on the MacBooks, iOS Mac OS environment. But Linux, yes, there are still some hiccups that needs to be fixed, right? But yeah, but overall, there are additional documentation I can send out to you guys, and you can take a look, yes. So, dispatch on Linux, is that equivalent to GCD on Mac and iOS? That is correct. Similar, but not exactly the same. But I can send you more information and tell you more. Okay, so we are done with the presentation. Thank you again for coming, and please, you know, send me an email with your first question about Swift. Thank you. Thank you.