 Hello and welcome everyone to a very special live stream today with the team from Oracle. They've been incredibly motivated to dive into contributions around all of our cloud native communities and it sounds like this is going to be the first of many of these sessions. I'm really excited to hear more of their experiences today. In today's session, the team will be presenting their perspectives on cloud native adoption in an enterprise setting. This is an official live stream of the CNCF and as such is subject to the CNCF code of conduct. Please don't add anything to the chat or questions that would be in violation of that code of conduct. Please be respectful to all fellow participants and presenters. Be excellent to one another. With that, I would like to hand it over to Rob to kick off today's presentation. With that, Rob, please take it away. Thanks Taylor. I appreciate it. It's been a great pleasure working with the CNCF, especially over the last six months and we've had some really good collaboration in terms of webinars and other streams of projects and I really look forward for the series of webinars that we're going to do jointly with CNCF, Oracle and CNCF and my role with Oracle is I lead open source initiators for Oracle Cloud and I'm very excited to have this panel of speakers here who are extremely qualified when it comes to cloud native. With that, I'll pass it on to the lead speaker of today's session. Hi, everybody, welcome. So first of all, we've got quite a bit of involved in a lot of different open source ecosystem including the CNCF and Linux foundation. We are integrating with pieces, we're contributing back to them, we're doing our part to be good citizens and we want to share our knowledge and our experiences where we can. So for this particular session, we're leading up to a major conference. We've got KubeCon coming up next week in Detroit, for those of you who are watching this after the fact, now you'll know when this took place and typically there's a lot of conference led development, you've got people who are going to talk your ear off about new developments, projects, integrations, releases, new products, versions, et cetera, et cetera, et cetera and knowing that that was going to be flooding your stream, we wanted to give everybody a little bit of a break from that. So we're here to give you value based not on what we're trying to announce, but based on our experiences with the expectation that anyone who might be attending the conference, whether it's going to be physically, virtually, watching the videos weeks or months from now on YouTube or just considering the content and trying to ingest it all, that when you're trying to get those takeaways from the sessions that you can bring home, that you can apply to your day job, that the insight that we'll be able to share here can help you get additional value out of the event out of the sessions that you're going to watch and about just in general being able to apply these principles to whatever you're working on. So the people we've got today, we've got a handful of folks and they represent several different product teams from within Oracle. We've got some apps folks, we've got some platforms, some services, some blended offerings and as much as we all think that all of our particular products are projects, they're all a special snowflake, they're all our baby and they're all individual and not like anybody else's, the truth is that there will be a little bit that will make it special, but most of the patterns that are going to come up are going to be patterns that you'll see again and again. They're not going to be that different, especially in a large enterprise environment like we're in. So we're here today to ask the panelists a handful of questions. We're going to ask each of the teams to answer each of our questions and then you, the viewer, can compare and contrast mentally those answers while you're ingesting that future content. And we hope it's going to provide some perspective on how you ingest the content and how you approach learning and making it part of your daily life. So we don't have any slides or anything, this is just going to be a lot of Q&A and we're going to start with some introductions. I'll start with myself. I am Noah Abrahams, I am the first ACNCF ambassador and now a Senior Principal Technical Program Manager here at Oracle and my day job, which is this, revolves around enabling people who want to contribute to CNCF projects, contribute to the ecosystems and generally being in good system. So I went first because I don't have a product or project on the line here. Now for each of the panelists, I want you in a couple of senses, introduce yourself. And also if you could very briefly describe your product or project that you work on so that when we go through these questions, people will understand, oh, that's that's a person who works on X, Y or Z. I'm just going to go by who's on my screen in order. So I'm going to start with Brad. Thanks, Noah. Brad Sargent. I'm a Senior Architect for Oracle CX Marketing. I've been with Oracle for over 22 years. We have B2B and B2C SaaS marketing products that we sell and build and also CDP that we have also developing and selling. And I've been working in SaaS for, been architect in SaaS for a whole time, been in Oracle 23 years, really Oracle. And before that responses, which Oracle bought and been working in container since probably 2016 is when we had to make the change from our own bare metal servers into the start using more of the open source and container mechanisms that it was probably around that era 2016. And since then it's been straight on till morning. Awesome. Next introduction, let's go to Subhan Karan. Hey, hi Noah. Thanks for that. Good morning. Good evening. The folks joining from the rear. So my name is Subhan Karan. So I am part of Oracle Applications Lab, OL, here. It's an internal team within Oracle and we kind of manage all of Oracle SaaS implementations, so HR, sales, finance, all of that actually. And we also build the extensions to those SaaS applications on the platform and infrastructure side of it, actually. I have been involved with CNCA projects for a little over five years now, starting off with Kubernetes service mess and couple of other projects around it. And I basically lead the platform and infrastructure engineering team here at OL and primarily responsible for app modernization and cloud native adoption within the organization. Awesome. Thank you. Moving along, Udayan. Hey, guys. Hello, everyone. I'm Udayan Sahu. I work with Brad in the same organization. I'm basically working on CX marketing platform, both B2B and B2C. My role in Oracle, before Oracle, I had done a couple of startups and loved to play with new technologies. And luckily in Oracle also, I got a similar role where I'm basically typically look at newer technologies and their adoption relevance to the product and other things. And when we started our move into OCI, that's where picked up multiple CNCF projects and evaluated many of them as the vision was to go infrastructure as a code. And they had really good things to offer along. We are so excited with the products that they offer and looking forward how they evolve from here. Thank you. Awesome. Back to you, Noah. And last but certainly not least, we'll pass it over to Sandy. Thanks, Noah. Hey, everyone. My name is Sandeep Gurum. I'm part of CX service organization. So my journey with the CloudNATO started with really in need of releasing software faster. We started with, hey, we really need to get our software out there faster. What can we do? And then we just, you know, one thing after the other, we kept on exploring more and more CloudNATO. And here we are five, six years later, we're fully CloudNATO and everything we develop and all the new applications. So, yeah, that's kind of how our journey started with the need to get software out there faster. Awesome. Thank you. You've all sort of touched on the first question that I wanted to dive into, which is how did your projects start using the CloudNATO ecosystem? How did you get involved with using the projects? And, you know, it sounds like nobody really started there, that there was an evolution. So people could talk a little bit about what the evolution was for incorporating CNCF projects into what you were working on and what you were building. That would be fantastic as well. Let's go back to the topic and start with Brad. Yeah, it was an interesting, we sort of backed into this. We had been building our own data centers for a long time, since 2000, really 1999, really, and doing SaaS products and using bare metal horrible bot responses that I was architect for in 2014. And we were having to convert over to use these large computing systems much too big for a single application. And so we were we first looked at VMs to try and solve that problem. But the VMs had performance limitations for maybe 15, 20 percent of our applications created too much latency with a lot of different complex systems we had to develop and the latency and the throughput was really critical. So we thought, well, let's look at containers. And I was actually given the job to do that and found that I could I could develop, I could use container technology and have basically no overhead in IO and we use Mac VLAN for our network connection. So the network was really fast and direct connection for that. I ended up taking all the legacy applications and converting them into containers in 2016 and and that that was still in our in our legacy data centers of data centers we were running over the next couple of years. We evolved and picked up more and more open source technology from that. And we moved to the OCI and in the process of moving to OCI, we picked up Kubernetes. Before that, we have been using Docker Compose on individual machines and and, you know, the using Prometheus and FileBeat and NodeExporter and things like that to to handle that ourselves, moving to OCI, open it up quite a bit and then we focused on how on how how we could use Kubernetes to to provide a more elastic, more live environment where we weren't managing our containers and statically allocating the individual servers. So that really shifted for us around 2018. And then once we were in OCI, it just in that environment, we were able to be much more cloud native in all of our approaches, automating everything and and using things like we're we're using, like I mentioned, Prometheus. And I didn't write it down. A bunch of projects that are actually even newer came up. What's the what's the what's a great project that is the is the workflow engine? Argo. Argo. We're using Argo for custom ETL, which has really been a lifesaver for us. A cute little project and and that's actually more recent. So anyway, it continues to evolve. Now, Udayan is more hands on on that stuff. So I'll let him talk more about the details going for the more modern stuff we're doing. Go ahead. Yeah, thanks. Yeah, basically as we started evolving and as we started seeing our goal, so one of the goals when we were doing with Docker Compose and other things, it took a kind of kind of quarter quite a bit of a time to actually maintain the container states and even the deployment. So like the one of when we moved into OCI, the goal was like, OK, how can we cut down a three month deployment period to probably weeks? And that was a big possible like Kubernetes and other things. They really managed those things well and taken basically gave us a really leg up as we moved along. Yeah, there were. OK, I'll pass probably. I can keep talking on this topic, but let's let's hear from the ban list. OK, let's pass it over to Subankar for the same. Hey, no, good. Yeah, so our journey is kind of similar, but more on the platform side of things. So as I said, so the organization itself is huge. So we have about like 500 to 1000 developers actually, right? So across various functional groups. Now our journey like we run this corporate applications which are running in our legacy data centers for more than a decade or so. And there was this push from management back in 2015 to 16 when they wanted to move everything from on premise data centers to CI and also on the SAS side of things. We wanted to move to the Oracle Cloud ERP, Cloud HCM and all those, right? So there was a need to modernize these applications and the monolith applications which are built for years. I mean, we looked at how we could re architect those and come up with the microservice platform. Actually, so because that was a crux of it and to make sure all these developers are able to build agile applications and also meet our timelines, aggressive timelines. So we looked at various things. So we started off initially by running something on container cloud service, which was built on Docker swarm. This was back in 2017, but the world has already moved around Kubernetes back then. So 2018 roughly, I joined the cube con in Seattle and that's where we kind of opened up to the whole ecosystem, right? It's not just Kubernetes. Actually, there is an whole ecosystem around it where you have several of these CNC projects that enable you to build this platform thing, right? So we come back and start putting together pieces. And then we decided the base of the platform is going to be obviously Kubernetes and luckily, OCI had a managed Kubernetes offering back then, which was okay. That that helped us a lot because when it is a service complex, so you don't want to be managing it on your own with the control plane at least. So we took that as the basis of our platform. And then what we needed on top of it was a service mess. Because one of the challenge that we kind of heard from all of our developers is with when you move to microservices, you have to address all of these issues around service load balancing security, circuit breaker pattern and observability and all of that. So we didn't want our developers to start coding for each of those individually, right? And this is a polyclot environment, like we have Java containers, Python containers, node containers, so and on various versions. So we wanted to standardize the stack. And that's where we picked up Istio, because that was a leading service mess back then actually. And so we kind of had Kubernetes with Istio on top of it. And then we kind of added a lot more services around deployment automation, which is where we used the combination of Jenkins and Argo. And then we have our own observability solution using Grafana Prometheus. Then the log aggregation happened using EFK stack, like we had Fluent, Elastic and all that. So yeah, I mean, if you can see like the whole platform play was not just giving vanilla Kubernetes, but the entire gamut of services around it. So that as a developer, they just keep the focus on the code development. And the rest of the things is taken care by the platform. So that that's how we have been evolving, actually. And like right now, I would say like, we are spanning across like hundreds of worker nodes with thousands of course running, actually, right? Production applications for the last couple of years. Yeah. That's great. Thanks. Let's move on and take the same question for Sandeep. Cool. Thanks for your evolution. Yeah. So although we arrived pretty much nearly the same spot as in what Brad, Subhan Karanuddin mentioned, our journey was a little bit different. So our need to move into cloud native started out with a we wanted to get our software out there faster. That was the basis. But there are also other constraints that we're starting to run against in 2015, 16 timeframe. That's kind of the timeframe where Oracle and a lot of it as Subhan Karanuddin mentioned, we're moving on premise our own data centers to our OCI cloud. And we are we were not expanding our footprint or legacy data centers. So and we have we wanted to use our existing resources more efficiently until we make that transition and combine that with we also need at the time we were doing our quarterly deliveries, we really wanted to cut that down to like weekly five weekly as a good. So you know, putting those two together, we started out with a we need to break our monolith down. So you know, we introduce service discovery. And that's, you know, we were able to decouple pieces and then have those communicate back and forth with service discovery. That's that's our first step into the cloud cloud native journey. And at the time, and we also wanted to use it resources efficiently at the time, we were just running one service per VM. And yes, we have multiple instances of it, but they're not all getting used at the same time. So that's kind of where we really need a scheduler, like we need to use that resource efficiently. So we we can, you know, we can get another year or two of runtime before, before we move to cloud, we have more more resource available for us. So so we actually started out with Nomad and orchestrator or Java processes for good six months or so. We continue doing that. And that's kind of when we started transition to OCI. That's we have to manage communities available for us, and which made it a lot more developer friendly. So until until that point, a lot of our investment was to how to operate what our developers write in a more efficient way and decouple them. And then how can we enable our developers to take advantage of all the self service they can do all the tooling that's starting to be available with Kubernetes. So I think it's about 2000. Later than 1718 is when we are transition to like more developer focus, less ops focus and more developer focus on how to enable developers to take advantage of, you know, schedulers and in a service discovery. So that that's going to start where we are transition to a developer centric cloud native ecosystem. And that's when we started introducing, okay, you know, developer can get an environment with push of button and then start deploying us and get get get a namespace, get get the whole supporting ecosystem. Like Supergrim mentioned, Prometheus Grafana and tracing it just out of the box. As long as you comply with certain contract that's established as part of our platform, you can just start developing, getting all the benefits without having to think about it as long as you meet this contract. That opened up like rich observability and, you know, ability to see what's going on within their services. All of that just made it's eyeopening for a lot of developers who've been, you know, who didn't have that ability until that point. And also it's to do stress on the ops side of who are who are dealing with data today. That's when the overlap between ops and dev, we started closing gap between what was ops and dev, now we're getting closer and closer to dev ops. So that's kind of, you know, our transition, five years later, until recently a few weeks ago, I was running our cloud native developer platform, which provided all basically all of the tooling, observability, tooling and CI CD. We used Argo CD to deploy and enable developers to deploy apps themselves as frequently as they can. We went from in three months to two weeks to like whenever you want. So yeah, that's kind of our evolution towards cloud native. Awesome. Awesome. I love it. So I think the next set of questions that we want to ask, now that everybody's told us a bit about how they got there and the what happened, is we want to talk a little bit about the why and the decision processes that went around, not just how it was built and architected, but around the projects themselves and how they got incorporated. We'd like to talk a little bit about why were the particular projects chosen? Was there just a following the tide? Because everybody's doing Kubernetes, were there technical decisions, were there political decisions? I know people are watching and they're interested in what it's like in an enterprise setting. Everybody's going to go, oh, how much did politics push down from the top to make sure that this was going to happen. So I want to ask everybody, you know, talk about the decisions, talk about autonomy, etc, and we'll go back to the top and start with Brad again. That's actually a very interesting question. I already mentioned that we originally got into the container world because having to deal with a large metal and needed to be able to abstract it and not lose IO and network efficiency and we were able to do that with containers. And I mentioned that we started out in our legacy data centers doing everything with Docker Compose and hand crafting it on each server with making sure that we had the right mix of containers that played well together. And that whole process was manageable because we had a small number of servers. Moving to OCI was a mandate that Oracle has had for its SASS organizations because of the operational efficiency and the higher level of security and there are many reasons for that. So that's definitely motivated by policy from our organization. So in working to how do we get there, I was originally tasked to do that as well. And so I looked at we were in OCI and I was basically replicating what I had done in the legacy data center using Docker Compose and building, you know, a few machines to build smaller deployments. And the upper level VP said put down and said no you have to use Kubernetes in fact you have to use OKE and OKE was just coming out with limited availability. And so I ended up being there in the first week when the managed Kubernetes that Oracle provides at OCI called OKE when it was available. So that's in 2018 early that's how we actually got in we were told I was going to use Kubernetes. I had known when I first started I'd been working for maybe six months in containers and I looked at at at Swarm and I'd looked at various things and I said Kubernetes is what I want to use but I'm going to wait. I wanted to get we have a lot of things we're doing. I didn't want to go right away into Kubernetes. But when we were in OCI was basically a mandate. I was all for it but I was going to wait a year but no they said you have to do it up front. So that was that decision. So in getting into it another thing that was interesting is coming from our own data center environment. The security we always used firewalls and so I was very knowledgeable and and managing the security using firewalls. Well there are no firewalls in OCI and we had to and when you're when you're using Kubernetes the way that a lot of this can be handled to get the security you need is with network policies. But network policies are not automatically enforced by Kubernetes and so you have to come up with how are you going to enforce network policies and so I think Sudhakar mentioned that he used Istio. I looked at Istio and I looked at Calico and so both open source both great tools and for my world I thought boy Istio looks really interesting but it was a bigger commitment. It's a framework and it was a lot more at that time to get into and get involved and adopt all the different aspects of it. Calico was a much more surgical tool that I could use as a plugin into Kubernetes and and do the enforcement of the network policies to take the place of to get the security we needed on a per container basis to take the place of what we used to do with firewalls technology in in our own data centers and so I went the other way so Sudhakar went with Istio and I went with Calico and so we're still we're still using Calico it still works for us. I do really see the value in Istio it's just that that was the trade-off we made because we had so much other things and complexity and also a lot of legacy applications that we just had to keep going that they make a lot of money for us and that we've been we've developed them for 20 over 20 years they're complex multi-threaded some of these are heavy things we're moving more and more into microservices and all the new stuff we're doing is with microservices but we still have these powerhouse complex applications and and so we're not able to just rewrite everything that we built over the last 20 years it is making a lot of money for us so so that's the trade-off we made I just wanted to mention that that was a decision I made about on Calico the decision for OKE and Kubernetes up front was really a management decision which turned out to be the best one for us the only other thing I'll mention is that when we started we built a lot of stuff by hand I wanted everything to be automated but I got a lot of pushbacks from managers in terms of time they had it was going to take too long we went through a couple of smaller projects new applications that we had built and published a couple of those when we got to the main product we were putting out in 2020 I said I put my foot down and said everything is going to be automated because we have to develop deploy all around the world like 40, 50 deployments separate deployments of these systems we cannot do this manually so we use we use Terraform in the past we've used Chef in our legacy environments but we've switched to Ansible because it was a little bit easier to use a little more flexible as well and a little less complicated for us and everything we do is now required to be automated that took a lot longer up front it's a lot more of an investment but it's really important I think that's one thing I wanted to just provide is my advice is that is really try and value complete automation in your systems rather than requiring to do things manually it makes a big difference in the long term awesome that's that's what I wanted to love it love it let's go over to Subankar next I'm going to skip hey I'll do this time right now hey no it's the same thing sure sure so yeah I think like the question around political versus technical playing a part in choosing some of these projects again I mean like I'll relate to what Brad mentioned like I believe Oracle had a corporate mandate to move all our on-premise data centers over to OCR right I think it made sense for the organization it was a strategic decision for the organization so kind of like all the teams internal teams and product teams are kind of moving towards that and we obviously since we were running on on-premise data centers we had to and these are like these applications that we manage are kind of the bread and butter for our own business so these are actually Oracle's own sales system HR system payroll and all so for us I think the most crucial aspect of it was time right so speed of delivery for the developers how rapidly they could iterate and rebuild some of these applications to make them cloud native that was very important so the platform was very important and I think we had full backing from management for picking up Kubernetes or the technology that could facilitate this speed of delivery as far as picking up other projects on the CNC of landscape those are purely like technical decisions and I think I mean if you look at the whole ecosystem of the CNC of landscape I think that's pretty massive 2018 KubeCon 2022 KubeCon I think the number of projects that are there in that is mind-boggling actually right so tough to even fit into one page where you can actually see all the projects and tiny little icons and there are so many overlapping functionalities in a lot of these projects actually right so it's very tough actually so if I'm working on picking something on the security side maybe there are like 50 projects out there which are trying to do something similar right so how do you pick the right project which is which you can maintain over time and which also meets all your requirements so I would give couple of examples I mean like on the security front or security policies right so that was one of the core requirement for us to make sure that our developers are not running privileged containers right and if you look at the ecosystem again there are so many tools out there we have OPA we have Kyberno policy engine there are so many projects which kind of meet the same requirement so for us when we are picking up some of these projects it was very important that we can maintain that over time so in our case between OPA and Kyberno we picked up Kyberno because Kyberno is again the same Pogonetis resources or YAML and we didn't have to learn a new language or new constructs which is needed for OPA but functionality wise they kind of give the same same kind of functionality right so so that that was a decision that we had to make right which tool to use same goes with service mess again I mean like between HTO and at that point I think CNCF had LinkerD which was their primary graduated project I would say for service mess but again when evaluating both we kind of looked at what functionalities do both of them provide and with LinkerD there were couple of core constructs which are missing like LinkerD didn't have an ingress of its own so we had to add an ingress on top of that and there were couple of other functionalities missing but HTO kind of came with all those functionalities in-built right so so we didn't want to again like when we are adding a framework we didn't want to keep on adding additional add-ons on top of the framework so these are some of the decisions that we had to make while picking up some of these CNCF projects and then obviously like when we are picking up some of these we also look at long term how do we maintain it right another example would be let's say we are using the EFK stack for our logging now tomorrow I don't want elastic I want to switch it to some other back and let's say open search so what is the effort that goes into switching that right so I could keep flow and D but I could kind of change the back and back end of it from elastic to open search all the while making it seamless for the developer right the developer doesn't have to worry about what is going in the back background actually so so those are some of the decisions that goes behind picking some of these projects and again I mean it is a continuously evolving thing so the whole cloud native ecosystem moves so fast so you have to keep looking at it every three to six months to make sure that your projects are staying up to date and you're trying to make the right backs at the right time and right so yeah awesome so indeed let's go over to you sure so one of the initial decisions we made was if you look at it you know I was starting out with Nomad for orchestration it had some context to that why we ended up doing that so originally we wanted to start with containers just running our applications in a container but this was 15, 16, 2015, 2016 again as enterprise we are very security conscious and our ops themes there is a there is a lot of discussion in the insecurity of the containers at the time and for us we really needed to move again our focus was moving fast and delivering fast so yeah we had to make a decision but if if you're taking time to do containers let's just go with the Nomad which can do just Java process orchestration for us we needed efficiency we need an orchestrator you know Nomad could do or Java process orchestration or any any any binary orchestration so that that was one of the decisions and we ended up doing a more surgical approach okay we need this now this provides that and allows us to move to the next level so our our journey was very surgical in the beginning to get us to what we need at that moment and then we you know slowly started evolving and you know and again it's the same as Brad mentioned you know when okay was available you know we it was kind of Oracle wide okay we are adopting Kubernetes at that point it was like great that's we've been waiting for that and we you know we could jump on that it's right that train and that's going to be an we ended up you know taking it as soon as the okay was available that was you know just great for us and we started at that point that removed any any any questions about container or not because yeah that which was it was great for us in that that accelerated adoption to cloud native landscape and see in terms of other decisions I don't know I think I'll I'll leave it at that okay um the there is one I think tangential question off of that and Subankar alluded to this in his mentioned of the projects having you know really high velocity and I'll I'll give this as a toss-up to whoever wants to take this question in the context of how the projects continue to evolve and the longevity of the individual projects how much build versus buy came into the adoption of the projects as a long-term maintenance decision and I'll give that to whoever wants to take that particular question and I'll take it okay so and the reason being one of the CNCF project is Helm so when we started our journey back in 2020 uh 2018 that time Helm was at 1.0 version at and we because we wanted to automate things from get go and the way Helm was positioned at that point of time we had to actually build our own orchestration of using directly Kubernetes APIs and and other things and for the the overall deployment project but like you say these projects evolve over time within two years when Helm 3.0 was released we re-evaluated our decision because anything which you build you have to keep investing and maintaining and doing all those things around it and probably around last year we actually pivoted again and started using Helm with Helm file to to actually satisfy our needs and that's where we actually stopped funding our build part and we went out went into and adopted something which was of the shelf and which matured over time to suit our needs yeah so the trade-off the trade-off you have to have the functionality you'd rather not have to build it and maintain it if it isn't your core your you know your core strength the or or what you're what you're what you're building for your up for your customers but but it's got to have the functionality but otherwise you know it really makes a lot of sense to leverage these open source technologies that are they're providing what you need even if you have to cobble them together but then you have to say on top of it you have to really do have to watch keep the versions that's the other side is there is a cost of ownership which is you you can't be letting things get too old you have to keep evolving so it's an it's an investment ongoing I think that's something that a lot of people don't consider in the context of build versus buy that buy could mean dollars or it could mean your time and human it means both both usually indirectly I think indirectly it's our dollar and end of the day right I mean you any yeah the the time that I would say like the time that is spent on maintaining some of these upgrading them I mean like look at the like the rapid versions that come out I mean Kubernetes almost like every year there are four versions I mean same goes with Istio and then some of these other projects so you have like security vulnerability CVs popping up all the time and you have to stay on top of all of this and there is a lot of maneuvers that goes into just maintaining these I mean the whole ecosystem actually right which is why it's so critical to automate you've got to automate all this stuff so that you can so you have less overhead and updating with to newer versions fixes whatever very critical exactly yep yep sure so let's take that in a slightly different direction now we've got a scenario where everybody's got your projects they're all built up and we've talked about the decisions that went into them but let's talk about sort of the unseen parts let's talk about speed bumps in the journey everybody's going to run into issues things that took longer than they expected things that you know were problems that you ran into it's going to happen so within each of these development life cycles what came up that you had planned for that you said this is going to take long and it took six months instead of three months that you were able to plan for and what came up that was completely unexpected that you know instead of being able to plan for it that you had to deal with it so let's uh let's go in reverse order for this one we'll start with Sandy yeah so when we started once we got on Kubernetes like we were really excited and we you know we tried to go all in we had our you know our observability with you know tracing time sees and then we also have our service mesh up and running and then now we started adding more developers and enabling everybody to be able to do everything and a few weeks in it created more nice than a velocity like one thing we learned at that point is like we had to back off like we had to start small you know in fact we pulled our service mesh out and we you know we didn't even go with service mesh to production and even though it's you know it decoupled it just caused more noise with development teams trying to adapt they're trying to it's overwhelming sometimes once you came in again you instrumented you instrumented your applications and then you add it's your tracing and it's like it's like what you used to do before what you have what you're doing in client applications you're doing putting a lot of things in ahead of time but taking that transition is in the in the beginning it was it was hard for a lot of our developers just change like I'd say that was speed bump and that was a lesson to not start with all of it like start as small as you can while still getting your achieving your business objectives just because you know we can do tracing can do we can do service mesh it doesn't mean you should do it all at once just focus on your business and see what what improves that and then just start there it's add more and more as you're trying to solve problems I feel like that we have to learn that the hard way and yeah I'd say that was our lesson in the beginning adding more developers just slowed it down in the beginning everything new set of frameworks and such great thank you same question over to Subankar hey I would agree with Sandeep I mean I mean we had similar kind of experience right so when you do this platform play like obviously like everyone's excited to get onto the platform but it takes time to build a production ready platform to be honest actually right so with all the bells and whistles around it like I mean security is one of the core concerns here so and like Kubernetes security has a lot of elements to it actually like starting from like making sure you have like hard-end images all the way till container scanning solutions your security on the runtime itself where where you don't have privileged containers you have restricted access between namespaces through network policies your egress and ingress controls all of that right I mean it takes time to build all of those so one thing that we learned is obviously like we we went slow I mean we started off with maybe couple of teams like two or three core teams we wanted to do the end-to-end workflow just to make sure that the whole platform the value of the platform can be demonstrated right and it's not just like on the deployment automation of it like how they secure containers but also like once the containers are live how do you observe them right be your metrics traces logs all of this how do you correlate them if there is an issue like now you're breaking down a monolith into maybe 10 different microservices your you have 10 different failure points so how do you basically correlate the traces to the metrics to the logs and then end of the day like give it to the developer saying that hey you have an issue this is how you kind of debug it right so it took us a while I mean good amount of time maybe like nine months to maybe a year actually just to get the whole production ready platform up and running and then that's where once you started showing the value of it then we had like knowledge transpositions with all the developers saying that hey this is how you can build this is how you can observe that's when we started seeing uptake of the platform more and more and so that was one learning and the other from an off-stand point I would say which was very which was something that we underestimated is the velocity with these projects have been built and that that we have to maintain we hadn't we had a very small team actually the ops team that was building the platform so we had our hands full actually what while building the platform and at the same time maintaining it and making sure that we have all the automation around it to patch when there is a CV or even just the regular cadence upgrading and keeping it in sync with upstream versions I mean that was a challenge actually right so it took us a while to again build those automation and have all of that in place so those are something that we hadn't anticipated because traditionally when you do monolith and on-premise development you don't run into these issues but when you pick up open source projects I mean there are a lot of these factors that have to be considered so I think that would be another speed bump or learning I would say that we had to factor in awesome thank you let's go over to Udayan first so yeah I think being in Oracle the security being the top most paramount there are that the processes itself make the overall deployment overwhelming when you talked about speed bump the instance which came out came to mind was more the way we had implemented so what we had done is with multiple teams they contributing their own containers and basically with Kubernetes you have the cron jobs so one of our DBA teams they wanted to monitor the databases and they started adding cron jobs and within no time no time we didn't realize that there were so many cron jobs starting and stopping and in the system it actually slowed down the whole system because like suddenly at 10 a.m. tons of cron jobs will start up and try to do certain things and so yeah these Kubernetes are great Kubernetes cron jobs right cron jobs yeah these tools are great they enable you very quickly or they empower you very quickly but at the same time there is no governance placed in they can basically it can become a very bigger problem so yeah just that was a kind of a big learning we had to actually go back and really bunch of things just to go around the problem I'll second I was gonna second that we had very much identical issues like one of the teams would cron job that kept failing and then that spun up thousands and then we took our masters down yeah exactly that was before we had limits in place and then we had limits on every namespace after that that's definitely a a trial life fire issue that everybody learns is putting in limits and quotas and yeah oh what do you mean I auto-scaled to 10,000 I think there's so much good content here with all the experiences that I think we could we could talk for hours probably but unfortunately we have a time limit on this particular session so I think we're going to try and end it there for the questions that we have lined up I think there's some questions in the chat that people want to talk about but I'm hoping that in general that being able to have seen the similarities and differences from each of these teams and what they went through and how they made their journey through the adoption of cloud native that it's going to help you know the folks that are watching at home assuming they're at home then it'll help them understand you know what gaps you might need to fill in in your own knowledge as you're adopting these technologies and that it'll help when you're attending the conference I hope you're all attending the conference at least virtually then it'll help you figure out your attention is going to be pulled in 20 different directions because there's how many talk tracks plus maintainer sessions plus the show floor if you're physically there and the hallway track and all the other ways that people on twitter and in advertising and whatnot are going to try and pull your attention in all these directions I hope that this is going to help everyone to focus a little more and get a better experience out of the show there's a lot of different opportunities to learn and hopefully this was helpful to all of you as you either adopt this expand your existing footprint or just think about how you're going to approach the system so shall we go to some of the questions that are in the chat there was one that I thought was interesting and is here in july because I worked in that space previously but I'm going to give it to the team what is your perspective on kubernetes cost management and it equals under the cnc and that it releases as toss ups sure I think we looked at kube cost actually so that's one of the cnc tools actually kube cost and I mean obviously we looked at sometime back it's a nice little tool which kind of gives you the way they have done it is they have plugins for each cloud provider so they kind of pull in the billing pricing details from each cloud provider and then they kind of go for the latest cost analysis that that is available out there so yeah I think I mean if you're looking at cncf projects probably that is one tool that we are looked at which I mean depending on what cloud provider you are using that definitely that's something that you can leverage actually yeah that's a particular for me I'm going to comment on it because a lot of people forget that cost management and resource management are the same thing and resources cost more than just money so here's a plug for something I'm not really involved with but that's okay the cncf has a tag devoted to environmental sustainability and as you continue to use more resources you are also using electricity you are using power you are using more air conditioning etc etc and the impact that you have on your cost management also has an impact on the world at large yeah so I agree I think you're in gear to my heart just wanted to get my two cents in there I'll get off my soapbox now let's see what are the other questions that we have in here observability logging and metrics very important to ensure your apps and systems are moderating healthy 24-7 what is your strategy and are the tools that you are using cncf sponsor projects again it's awesome who wants it yeah I can I can go for it we even pull on cncf on a for tracing we're using Yeager for for logging we've used low-key kafana for observability and visualization to see Prometheus for time series Hanoz for our long-term time series database so basically each and every one of them work are cncf projects awesome and relating to another question up there um I don't even know the answer to this do we OCI offer a managed Prometheus does anyone know I don't know as of now yeah not as of now internally it's not it's not external yeah is that all the questions that we have from the chat I think the cost cost-benefit justification is is a general question makes a lot of sense if I said okay I'll jump in and and just say something about that going from coming from speaking as someone who managed their own data center for sass for for 15 years not not using a public cloud like OCI before we went to OCI it we built everything so we were responsible you know for the compute for the databases the networking all the security everything building this up from scratch in a in a data center it took it for the for the deployments we had it would take a full year to do a full new deployment of the applications which is complicated moving to OCI we can do that in in in just a few weeks just like just maybe even in a brand new region it takes about six weeks total it's it's a huge difference so the time it takes to deploy is a big part of the cost you just can't cut down if you're doing it yourself if you're if you're in a your own data center it's it's a I can't under over us overstate the importance of of the time value you you gain in a in a cloud once you get it down once you understand the tools once you know how to do the automation then the deployment times are just a very small fraction of what it takes to do it yourself in a data center so I think I think it's it's a big cost benefit just in terms of the time you save in the in the in the in the employee time yeah and I just want to add to what Brad said like I mean like I mean moving to cloud definitely I mean I have a lot of benefits so but one thing that we we try to be very careful is we don't over provision and underutilize right resources that's very critical for us actually I think we have seen I mean obviously like you have this you cut down your provisioning time and all of that and developers are all happy we want to get on board with all of this but then we are to be very careful about how we use the resources actually I'm not based on that right so yeah which you really can't do if you're doing it yourself totally right because you've got you got to buy the hardware and it's and it's whatever you use you use and yeah it's a that's a big deal and also the monitoring is always better in the clouds to know what you're doing and what you're using and you're sharing it with other people yeah right well thank you all I think Taylor's about to start queuing up the Oscars music to play us off so wow a huge thank you to Brad, Edian, Supankar and Sandy I hope everybody found this to be useful for all the perspective and all the experience that we could bring to you our viewers thank you all thank you thank you thank you oh Taylor one absolutely no thank you so much Noah thank you all for joining and just sharing those stories I feel like as we work through different cloud native contexts that's the thing that we don't always get to hear right we're not always on the same teams we have the same missions and objectives we're working you know same team different company for sure but we don't get to sit next to you all the time and hear what's going on this is really informative and interesting to hear kind of what the concerns are amongst folks within the community so thank you so much for taking the time to share and thank you all for joining us whether you're watching in real time or again like Noah said watching us many years from now thank you so much for coming on by and joining us for another cloud native live installment input we hope to see you again soon and for those looking forward to KubeCon Detroit here in North America I hope to see you there as well thanks again have a good one thanks for watching bye everyone thanks bye