 I'd like to thank everyone who's joining us today. Welcome to today's CNCF webinar. Small is not always beautiful, moving to enterprise applications to the cloud. I'm Jeffrey Sika, I'm a senior software engineer at Red Hat and a cloud native ambassador. I'll be moderating today's webinar. We would like to welcome our presenters, Paul Jenkins, product manager at Oracle Cloud Infrastructure, cloud native services, and Tony Vertenten, co-founder and CTO of interest. A few housekeeping items before we get started. During the webinar, you are not able to talk as an attendee. There's a QA box at the bottom of your screen. Please feel free to drop your questions in there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such, it is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful to everyone, all of the participants, presenters and peers. Please also note that the recording and slides will be posted later today to the CNCF webinar page at cncf.io slash webinars. With that, I'll hand it over to Paul and Tony to kick off today's presentation. Thank you, Jeff. Thank you for everyone for joining. We'll get right into things and just introduce myself and as Jeff said, my name is Paul Jenkins. I'm a product manager in Oracle Cloud Infrastructure working on a developer services part of the organization. And that is, I look after kind of customer contact customer outreach for our managed Kubernetes service and API gateway products. I've been in Oracle a little over eight years in Oracle Cloud Infrastructure as a product manager for the last four and a half years. Before that, I spent an awful long time at IBM. And yeah, I've been in the industry probably for longer than most of the audience have been on this planet. In the current state, I'm working from home so I am, I'm hoping that nothing is gonna go wrong. I've switched my landline off so hopefully we'll be good to go. And I'll hand over to Tony to introduce himself. Good morning or afternoon. My name is Tony Verstensen. I'm a co-founder and not CEO but CTO too much credit there for interest. We founded the company 25 years ago. So I think I'm a bit longer in the field than Paul if I'm not mistaken. We've been a Oracle customer and we, well, Paul asked me to talk about our journey from on premise to the clouds to Kubernetes. Glad to do so. Thank you, Tony. Oh, I'll get going. So firstly, we've got a bit of a quiz. I don't expect anybody to answer but I was just wondering how many people would recognize this and knew what it is? Well, it's in fact probably the original CD tooling that I worked with back in the day. Back in the day when I first started programming and this was coding sheet was how we created the program. Code that's got sent off to an agency where the code was transferred into punch cards. Those punch cards were then loaded into this hopper and they were uploaded into a machine and it was almost exactly the same as that one. And then we were able to start compiling and running programs and we were at the height of tech then when we had three of these for a team of 10 programmers. That was pretty cool. And then what was really cool is when we each had one on our own desk and that we were really productive then. So that's kind of where I started and I think it's safe to say that things have moved on a little bit since then. So what's really happened is that the way that the process of development, the way applications are designed, the way they're deployed and what they run on has changed quite a lot from back in certainly the early 80s when I was doing that wonderful coding. And that kind of evolved through the agile processes, the multi-tier deployment, starting to use virtual servers. And instead of everybody having their own data center, we started to see the rise of hosted systems and outsourced systems. Today, we're kind of looking at an evolution of that which is more the DevOps process of design development using microservices and service-driven architectures to deploy the actual application logic. We're starting to see people wanting to use containers and serverless to be their deployment and packaging because it's much more efficient and more transportable and people, organizations are looking to use the cloud and not actually have to worry about owning or even running infrastructure. So while we've come kind of a long way from the top left hand corner in the 80s down to the bottom right hand corner of today, the basic what we're trying to do is still trying to deliver business value to our organizations. The fact that we're using different techniques and technologies doesn't change the whole lot really because we're still trying to do the same thing. And all that's really happened is that instead of punch cards and card readers and coding sheets, then we're using more modern IDEs and source control and CI CD tooling to make it faster and easier for us to deliver the change and the business value of the modern application development process and using the cloud as the environment in which to run. Now, over the years, I've seen lots of organizations and wanting to make this transition and there's always a big desire for this to make a really big change. I think we've all seen the Dilbert cartoon stripper, which the answer to everyone's Kubernetes. People aren't quite that tough, but these are absolute questions that when we've been given, asked to go in and talk to a customer, we say, okay, tell me how I want to go and pick serverless. How do we do DevOps? We get that question so often. What about server microservices? How do we reduce our delivery time? These are all kind of big desires, but it's kind of symptomatic of organizations wanting to make that move into the cloud, which many are kind of still struggling with from the enterprise space. And I think there's some real fundamental issues and questions that need to be asked, which aren't these big questions. There's some practicalities about dealing with the reality of what that actually means, because the realities of an enterprise doesn't have to be particularly large, but moving to the cloud is dealing with some fundamental questions and issues around complexity of the existing system. There's a lot of technical debt in enterprise systems. It's the diversity and the complexity and entire stack of having lots of different hardware that's being used through different programming languages, ways of integrating and accessing between systems. That's not such an easy thing to address and it needs some thinking about how we're going to address that diversity and the complexity of the stack required to move an application from on-premises into the cloud. Pace layering, not all systems need constant change. So what I'm referring to here is there was a few years ago, Gartner came out with this concept of paced layered applications and saying that applications change at different speeds, depending on where they sit in the sort of business chain. So the concept is that at the bottom is you've got systems of record. These are the systems that you just have to have in order to be running a business, to be legal, to be compliant and just to function. Above that, there's a layer of what they call systems of differentiation. And these are systems and processes that you do as an organization that differentiates you from competition. So it may be the way that you handle customer complaints to where you're onboarding customers, those kind of unique value, value adds that you as an organization producing it. The top layer is the systems of innovation. So these are fast-changing sort of digital environments that you're trying new things, it might work, it may not, it doesn't matter if the whole sort of start quick, fell fast or all that kind of speed and agility to much more customer digital experience kind of things. And there's sort of things that I'm talking about when we talk about not all systems need constant change. Not long ago I was speaking to a CTO of an insurance company and he was saying that they've got this sort of digital, platform, digital transformation going on there, creating mobile applications and starting to look at deploying microservices what they need, they still need to make their delivery cycle a lot shorter. So they're like on a four-week cycle, they're really trying to get down to a three-week change cycle. And he was complaining that the real problem is is that I cannot change all my systems quick enough that the policy management system was an application system that was bought in from commercial supplier and they can't change it quick enough to get into their three-week cycle. But when we actually talked a little bit more about whether that system, why would that system need to change so much? And after we've had a talk and he thought about it but he said, well, the reality is that every time we do make a change to that system it takes months to roll out that changes and educate all the users on the new features and functions of that. So, well, actually I don't want it to change. And that kind of bit of an epiphany moment for him and that's when it comes to those sorts of systems what we want to do in order to get the value of moving everything to the cloud is to be able to lift and shift that application environment from an on-premise environment to the cloud. You don't necessarily need to change it to get the value out of moving to the cloud. The other reality is skills. Organisations that have enterprise Java applications and enterprise Java servers have got a certain skill set that is very much focused around the development of those applications, not necessarily much around the operation of those systems. So there's a gap in what the organisation has and can do and what it needs to be able to do if they're making that transition. And I think one of some of the biggest problems of doing that is around organisation culture, not something that is really going to be solvable by moving application to the cloud. But one of the great example of the sorts of systems that need to change with a beyond-gest technology in our engineering centre in the UK, we get customers come in and talk to us about how we do things in terms of development for the cloud and our processors and all that kind of stuff. And we had a public sector, it was a police force that actually came in and wanted to talk about the whole DevOps approach and how we transformed this organisation to do that. And when we talked about skills, they were saying that part of their problem is that they have Java programmers in their organisation that are great Java programmers, but all they want to do is be Java programmers. They don't want to start looking at the operational side and working in different team structures, et cetera. And the other thing that struck them was when I took them just on a quick tour through the office, we happened to get a, there was one of the teams that it was working on, our functions at the time, were having a big huddle around trying to address a problem. There was half a dozen sat around the desk and looking at the screens and discussion and they said, oh, this is entirely different from our organisation. Our developers have all sat down in their cubicles and it's all silent and they're just working on what they do and chuck it over the wall. Those are sorts of things that beyond technology that really we see is probably bigger stumbling blocks to moving to the clay. So when we do speak to customers and see what's going on, there's kind of a journey that seems to be becoming a pattern and a model for this, that people take their existing applications and think, well, now we can start, see if we can run them in containers and Docker being a very popular one in the commercial enterprise space and then start realising that, well, if we've got the more of these things that we have, the more that we need to be able to manage them and then we start looking at Kubernetes as the end point and which is great, but when we talk about the skill sets differentiated, differences that we mentioned just now, then they need help in moving these Java enterprise applications into Kubernetes. So what we have is what we see is that the trends are moving to cloud naturally. Embracing Kubernetes is a preferred deployment platform for enterprise Java applications is something that we see and something that we're helping customers with, something that we are supporting and we're working to try and simplify the deployment of those applications onto Kubernetes. Why is that? Because A, they can migrate their existing applications then we've got an environment which customers can then use as a path to get to micro services to things like Heledon, Istio, et cetera, to be able to do that and start to then have an environment that maybe they can start to migrate their applications. So to that end, what we've done is that we've released a Kubernetes operator for WebLogic that basically helps our customers be able to lift and migrate their enterprise applications to the cloud. Now what that means is that it enables these organizations to make use of their existing skills. So me as an enterprise Java developer don't necessarily have to throw that out the window and start to learn something new from day one. It allows us to focus on creating and managing the applications that we're used to rather than having to worry everything about running and operating a Kubernetes cluster. So that also the operator then understands the application server cluster, it understands about domains, it understands how to scale the cluster and what it also does is it makes use of Kubernetes to automate the life cycle of the operations of that application server. And it also allows people to start to transition into modern tool changes that we looked at, to Jenkins or whatever CRCB tooling we can start to deploy as containers and have that much more automated way of deployment of application changes and updates. So what we've done is for the open sources we've released the WebLogic Kubernetes operator that basically managed the life cycle operations from a Kubernetes point of view that understands starting stopping an application server environment to automate the configuration of that environment and support standard Kubernetes, things like side cards and custom resources or that sort of thing. So it can really understand both the Kubernetes side to things and operate WebLogic. As I say, it's super sourced and fully supported on GitHub. So what I'd like to do now is to hand over to Tony and Tony will just talk us through his, their experience of following this path and some of the challenges and some of the benefits that they found during their journey. So I'll hand it over to you, Tony. Thank you, Paul. So we are interested and we are an independent software vendor and we have created a Java application for the logistic service providers for those of you who don't know what that is, that's forwarding company shipping agents, warehouse, that kind of stuff. We have a little over 300 customers. The interesting part there is that they range from two users to the largest one who has a little over 450 users. So it's a challenge as far as deployment is concerned. We are also having an embedded social license with Oracle and this is important to know why because that means that we have to actually install all the Oracle projects separately for each customer. So we cannot actually use a real source if you like. We also are using HR Scrum for development and we have a new release every six weeks. It used to be four weeks, but I'll come to that problem later on. We are not the biggest company. We have as a development team, we have 12 application developers and we have another team of four that do mainly integrations. And by integrations, I mean setting up BDI enterprise service based of that kind of team because in logistics, there is a lot of application integration going on between suppliers, official instances and so on. I've tried to, it's maybe a bit small, but I've tried to put out the way with the application is set up on the web logic. And that means that we have actually two domains. One is the application domain that has was always an admin server needed and we have four separate managed servers. Those managed servers are used for what's called Frisk Master. That's mainly for the interactive to the UI parts. We have a Frisk service that has all the services that are provided by the application. And then we have Frisk enterprise service bus that is based on Apache Camel that is used mainly for the integration between the different parts. And of course we also need a managed server for the broker. Other than that, we use Oracle Business Intelligence to provide a reporting and analytics, but also a very important part of it is we use it to generate and create documents as there is still a lot of different documents used in the logistics world. And then all of this is connected to an org enterprise database with has the application data course but also used for the meta data service. And then we have some other open source tools used like open office mail server, stuff like that. That's running on a separate server. So that's the application and a small introduction. And now I'll demonstrate my voice control slides. Next slide, please Paul. Wait. So what are the challenges we run and run into? First of all is we focus as Paul mentioned just earlier more on application development and really less on deployment and operating and all the stuff involved. Now, one of the things we run into frequently is that there is a mix of environments to deploy our application on. It's usually the customer that decides what kind of infrastructure he has. We do give him like the minimum requirements we need but they don't always follow our advice on that. And there can be both on-premise and in the cloud. When we started out, it was mostly on-premise all exclusively on-premise. It's only in the last two, three years that we actually see our customers being interested in moving to the cloud. Before that logistics, everybody wanted its own service, if data, his security. That's locally, that has changed a lot. The other thing we noticed is that the performance is varies extremely on the different environments. Even though we have the same Oracle stack, we have the same application, same database, we still noticed that with some customers, we have very good performance and with other customers, actually very bad performance. Well, we've always discussion and a lot of work and finding out what exactly was the cause of that. More specifically, it was the case with setting up the system itself. The well-known error, please do not use a virus scan on your database for it. Deployment was also a problem in the sense that we did have scripts as much as possible, automated deployment, but because of the variants on those different infrastructures, those could not always be used. As a solution, we set up a standard cloud input that we could offer our customers the standard environment in Oracle Cloud. That already changed a lot in the sense that it was a uniform environment. So the Linux was the same. We had the same CPU, same memory, same disk storage. And that gave us exactly what we wanted, namely a good predictable performance. The other thing is that we were able to actually standardize all the deployments now. So that was already a lift of a big burden on our deployment team, which by the way is only by four people. So we didn't have a big team there. We used one compute instance for small customers. So we have everything running, all those managed servers and the different domains on one compute instance. For the larger customers, we use three compute instance. Next slide, please. Okay, that already gave us an answer to a lot of anger and worries about having a performance issue, but now we faced with something else. And that is, as I said, we have a new release every six weeks, but it took us eight weeks to have all the customers, to have the new release deployed to all the customers. And that is something that we really set out to do is that we really want all our customers to have the same release. Now the solution there was, after having seen some demonstrations was going over to Kubernetes. The obvious advantages there is, one is I could automate my deployment and actually connect that to my CICD pipeline. That means that once the new release is available, we could actually automate the installation at all the different customers. Be it those customers that had agreed to use our cloud environment and some of the customers that also agreed to have Kubernetes on their own brand. But unfortunately, not everybody has made that move yet. The other big benefit I found is the blue and green set scenario which should be deployment. For those of you who don't know what that is, that is it gives me the opportunity to actually already prepare the new release. And once we have the matter of speech press the button to release it, it will actually start and see what pods or Kubernetes pods are eligible to start replacing and then it will fire up the new release in different pods. But that means that there is no longer a downtime required at the customer side, which is a great benefit because part of the problem why it took eight weeks to install every customer was that not all customers well, none of the customers wanted the downtime outside of the office hours. So we were always limited to weekends and nights. So also a bit benefit for my deployment. The other, sorry, one thing I need to mention by blue and green deployment is one of the problems there you have to solve is your database schema because in well, almost every case when we have a new release we also have a different database schema. Fortunately there we could make use of the Oracle feature called addition base three definition that meant that we could practically use the same way of working in the sense that we could already prepare the different schema in the database and by putting in another parameter in our connect we could have the new release actually make use of the new schema. What's also a benefit is a better use of the resources when we offer the cloud environment as I mentioned before the smallest unit we could offer our customer is one compute instance. For those customers who only have two users that is a bit of a overkill. So by using the Kubernetes we were able to share those compute resources and offer our smaller customers a better solution. I think Paul already mentioned it also was the fact that it is scalable. So that means that if we see that some of the managed servers have a bigger workload than expected we can easily scale up the number of managed servers for instance for the three services. And the nice thing about this is that can also be automated. So you can actually go and measure the amount of memory or CPU a certain port is using or the managed server in this case is using. And if you see that it's 100% which sometimes happens when big EDI jobs are running you can actually scale up and add another port for that. As also mentioned is the other big benefit is that it is available as well in the cloud as on premise. So that means that we can further uniform make standardized our way that we deploy our application. Next slide please. So this is a simplified schema of how we set up the application or the deployment in the different clusters. So we have three notes in three different availability domains on Oracle Cloud. This also gives me added benefit. And we agree with Oracle that if we put every customer in a separate namespace that they would see this as a separate installation. So we would not reach our meta software license. And we can kind of modify or adjust that to our customer's needs. So the example above is a medium customer which has two instances of the master in the service but the master broker and the enterprise service bus as well as the one you'll be I sorry is just running in one pot. Then we have the solution for the smaller customers that actually only have one instance of this master and his service. And of course we still have the OBI for the documents. And then the bottom I have an example of what we would do with the bigger customers although there we choose to put those in a separate cluster as not to overload all the rest of the customers. But that means that we can actually use this solution for the smaller customers instead of just one on instance I can put like we haven't tested it yet how far we can go with it seems that we could easily do 10 customers on a three notes solution. The other thing you see is that each customer has its own PDB so that's a private database it's feature of Oracle and that is running on a database cloud service as was advised by Oracle one others but also in literature. It's not always a good thing to put your database in a Docker container who best do that site in a different service. Next slide please. Okay, so going over to Kubernetes is a big help but it's not an easy walk because as Paul mentioned we didn't have any knowledge on Kubernetes and it is a big challenge. There is a lot of stuff available. There is a lot of decisions to make on how to do things you can have your solution set up in a different way. So where do we start? Well, as also mentioned we didn't have any experience with ops we focused really on application development and the other problem is that of course setting up that environment is you also want to monitor and manage it want to be able to act on problems. And if preferably be proactive so acts before a problem occurs. The solution we find there was that making use of existing tools because if there's one thing I learned about the general philosophy of a Kubernetes is that it is one of the directions is make it as simple as possible. So the existing tools we use is as mentioned by Paul is the WebLogic Kubernetes operator which really does a bunch of things that otherwise we should have created services, parts, deployments, jobs, demon sets, all those things we don't need to do. It's the operator that takes care of that. Also scaling and changes is taken care of by the operator. We also use two other open source tools from Oracle and it's called the WebLogic deployment tool. What that does is actually it helps us to create the WebLogic domains not only created but there is also some very nice features like actually discovering how a WebLogic is set up and actually creating your models so you will be able to create new domains based on the system. Also the possibility to update your domain afterwards. The other open source tool we're using is the WebLogic image tool and as the name already says that one is actually creating your Docker images for you based on making use of the WebLogic deployment to itself so what it actually does is it loads all the necessary software from Oracle including any patches you want to apply and then creates a Docker file and executes it and that Docker file is created in a way that to be honest we were never able to do so it's actually following best practices for Docker. The other tools that are very important for us are for the logging, managing the logging is elastic search, FluentD or FluentBit. We're currently looking at using FluentBit instead of FluentD because it's a lower footprint and of course Kibana for the logging and then we have the question of monitoring and showing the help of a system which is for which we use Prometheus and Grafana as the tool to visualize everything. So that's actually used at the moment. We're still learning a lot as we move on but the nice thing is it's most of these things almost work out of the box so that's and there is a lot of documentation available. Next slide please. Okay so this is very brief on what we want to do as next steps, it's just some topics that I wanted to mention is the first one is microservices and there it was the long question on should we go for microservices or not being an enterprise application? It's a big application, has a lot of features and functionalities but it's not easy and certainly in my opinion time consuming to transform the complete application to microservice. However, when we were on our journey we did find out that we don't have to actually transform the complete application to microservice. We can already start by using parts of it to microservices. One of them that we're actually at the moment developing is as I mentioned, we are using a BI publisher to generate documents. Is there using the library which is actually Java libraries for the BI publishing and put those or make those available as a microservice. For that, we're using Elidon as a tool to help us make that transition to microservices and also grow a VM to keep that image as small as possible. By having that experience came a parent that there were already a few other candidates to start transforming to microservices one of them is we have a workflow management system and one of the things that system needs to do quite often and which takes some resources is calculating priorities of tasks. We find that was also a very good case where we saw that, okay, we can take that out of the application and use it as a microservice. Same as generating or creating EDI so XML messages or JSON messages. And that's, I think I came to the end of my story. Thank you very much, Tony. So just to follow on from that and to wrap up. I think it's clear that from Tony's experience that yeah, great, we've got a Kubernetes operator that helps to migrate the third application. But as you saw from Tony, enterprise applications have a lot of complex interdependencies that we need monitoring, they need access control and they want to run these applications in the same kind of environment that you would want to start developing microservices as Tony mentioned. So to that end, what we're doing is to build out the environment that almost the same as what Tony talked about. So we're building some workload management tooling which again is open source called Verizano that makes use of underlying infrastructure management like Rantra and Istio to deploy the underlying Kubernetes environment and we're pre-wiring and joining together the monitoring with tooling for CI 3D and integrated security using these products. And it's an opinionated but very much open source based environment to help the deployment of these enterprise applications as they are onto Kubernetes running on-premise public cloud and of course multi-client. So we're building this up to build this kind of picture which is while the operator in Kubernetes is great to be successful, you have to have a complete environment with which to support those applications. And it also gives as Tony mentioned the environment to be able to lift and shift these traditional enterprise applications to the cloud. That means you don't have to from day one re-architect and it gives the environment with the Heladon and Istio and those other environments to be able to start to develop these new and develop the new services, microservices around that on that environment. So that's just a kind of, it's a bit of roadmap but we're actively working on that at the moment and we're sort of doing initial testing with that. So hopefully that's given you an idea of the sorts of issues when you've got to think about when migrating these applications and also to give you some confidence that there are tools and environments to help and that people like interest are being successful and doing that journey. So with that, I would like to thank everybody for their time. Hope it was interesting as worthwhile and I think if there's any questions, we've got a couple of minutes left for that. Yep, thanks Paul and Tony for a great presentation. We do have some time for some questions and I know there are a couple of queued up that I'll get to. If you have a question that you would like to ask, please drop it into the Q&A tab at the bottom of your screen. We'll get to as many as we have time for. So first question, which type of web logic domain configuration do you run in prod? Domain image in home or domain home on PV? Could you please give the reason for choosing the option? Okay, I guess that's a question that's addressed to me. We've chosen for the domain image in home, so not on the persistent volume and the reason for that is that it's much easier if you want to connect it to your CI CD. So if the moment we got a new Docker image with the web logic domain, it's just easier to manage. Awesome, next question. Can we run legacy or monolithic applications written in Java 8 using the web logic operator on Kubernetes? Not sure whether that's a question for me or for Paul. Java 8. Yep, Java 8. I believe so, but that's something I'd have to double check. For my two cents, I believe you can run Java 8 applications. However, the one thing to keep in mind is anything before I think Java 10. Java doesn't necessarily adhere to C groups and it can consume more memory than you allotted. So. Thanks, Jeff. Yep, next question. What are you using to manage Rancher? I mean, Infra as code to deploy Kubernetes via Rancher and managing Helm charts if using that? Basically, yes, to that. It's early days in that. So we've basically got Rancher managing the infrastructure underneath and the sort of Verizano is the layer on top of that to manage the application environment running on top of that. Awesome. How are you managing storage on bare metal via Kubernetes? It's not the same for Oracle for sure. I'm not sure that I understand the question. Yeah, go ahead, sorry. Yeah, so what I think what we're doing is we're using the file system of Oracle Cloud but that's not for the application and say it's more an easier means to store the lockings for all the different systems and that they will use you better accessible via tools such as Prometheus. And just to add to that, they mentioned that they meant EdgeFS or SETH. Right. Yeah, if there are any other questions, feel free to pop them in the Q&A tab. We do have a couple more minutes so we can take a few questions. Next question is in your microservices, have you considered stateless applications? The things we do use as a microservice are in fact stateless. We're looking at because in the 40 instance for the BI publisher, which we use for the documents, is we both provide the data as an XML and the templates. So we actually don't need any access to the database. So it's my opinion, it's stateless. Yeah, I think just to add to that, I think that's kind of a good recommendation on approaches that microservices being predominantly stateless. I know you don't have to be, but I think that's one of the areas that, these applications that Tony was talking about really lie quite heavily on state and state management. So they're not all necessarily a great thing just to be able to break down and say, well, we're just gonna use a service mesh and completely replace that because that's quite an undertaking. All right, one last question. How are you managing your state full footprint? So I would say the state for the applications is managed by or stored in the database. I think that's correct. Yeah, that's correct. We don't put anything, everything that has state is actually written to the database, including for instance, for the message broker, the person's stores are actually stored also in the database. Awesome. Well, thanks, Paul and Tony for a great presentation and Q&A session. That is all the questions we have time for today. Thanks for joining us. The webinar recording and slides will be online later today. We're looking forward to seeing you at a future CNCF webinar and have a great day. Thank you. Stay safe.