Join a real-life journey on the road to cloud-native
Good morning, good afternoon, good evening wherever you are on the world My name is René Moddejongen and on behalf of Microsoft. I want to welcome all of you. And I'm pretty excited. And the reason why I'm excited; we are here together with a fantastic partner and also a fantastic customer. We will showcase one of the use cases that we've created together. Again my name is René Moddejongen. I used to be the open source lead within Microsoft Western Europe but now I'm also leading the partner ecosystem in the Netherlands, for parts of it by the way.
So let's start with a formal round of introduction. I introduced myself already Klaas Peter, KP, can you please introduce yourself? Yes thank you Klaas Peter Majoor, I'm working for HCS Company as managing partner and we have something in common we both love open source. Or probably we all have something in common we love open source and I'm happy to be here I asked Joris a couple of times already. Hey, we need to talk about this because this is very cool.
And I'm excited that we're here. And before we move it over, can you talk a little bit about your company? Who is your company? What do you do? Our company is specialized in Red Hat open source and mainly in OpenShift implementations so we work with site reliability engineers and we our customers to to deliver reliable environments and we modernize a lot of applications. Fantastic well thanks for the great introduction on that side let's move over to you. I'm Joris Cramwinckel , I work for Ortec Finance as a technologist
doing that already for nine years. I have a background in high performance computing. Also at Ortec I work in the candy shop I can work with all new technologies. I'm responsible for all the new technologies at Ortec Finance and cloud technologies have been on our agenda for a while now . And yeah last year I think I called KP. We decided that we we believe all technologies are proven
by now and we want to do it first time right and we need a cloud-native platform. That's why we started to work together. Can you tell can you talk a little bit about your company? Yeah, Ortec Finance. What we do in a nutshell is we design
mathematical models for the financial sector. And we package that in software in different ways as pure SaaS or APIs. Typically these models help our customers balance the risk and return trade-offs. For a few years now also climate risk next to financial risk is embedded in our models and yeah we do that on global scale.
Pension funds insurance companies banks. So the solutions you're creating you're actually also selling to your own customers. So it's an ISV solution you're creating. And I think the stuff you've created together with us that's a perfect example of it right? Yeah that's one of the examples one of our core engines core mathematical models exposed in web applications which we transformed.
To the audience at home or maybe you're at work but I think KP created a couple of topics that we want to discuss so he's going to lead that discussion. I will fill in as much as I can but again you're the subject matter expert that's going to explain what he did at his company and KP is going to lead the way. So maybe walk us through it. Thank you I will. Well we did the short introduction already right, let's skip that. This picture
was taken in Prague during the Red Hat partner summit. It was a time where we could gather together with a lot of people and we were there, you were there as well. I remember that we had a great time. I think we said enough about our companies right? Absolutely. Okay, Joris came to us a year ago I think and he was like hey we have a cloud native dream. Can you tell something about that? So cloud native is a mean to to achieve your objectives. It's not a goal
per se. We discovered that when we revisited our complete enterprise technology strategy with a small group of engineers headed by our CTO. And yeah the term cloud native first set some some friction in the organization. Cloud and typically the financial sector is rather conservative but when we preceded the discussions we discovered that things aren't like they were two or three years ago. Things move fast also at our clients. So actually we had three objectives of the enterprise technology strategy. Technology should enable growth of the company. It should
assure quality, with a log4j situation last week that's a proven point. But the quality standards in the financial sector are really high and tough and the last objective was to deliver fast. We experienced that the lead time from an idea or a customer demand to production was perceived too long. So growth, quality and the last one was also faster speed of delivery. Instrumental of achieving those goals was a shift towards cloud but also a shift towards using containers. And that started with a container platform.
Then we had lots lots of discussion. What type of container platform or cloud native platform what you call it. Platform is maybe a hype term nowadays. Fits our organization best. Actually I called KP we need a batteries included cloud native platform. That's a nice one. Yeah. The visual described it on one of our
pilot reports. So we started doing a pilot with one of our products and I pictured a slippery cloudy road because we did not know where the road ended and how we would go. But along the way for a couple of months the road became sunnier. And more straight and we learned a lot. You are still a very eager organization. In our first conversation I remember that I told you guys okay this is going to be technology and organizational change. Be prepared for that. And that's something you did very well. but we'll discuss it later
in a couple of statements as well. We fastened our seat belts for the slippery road. Maybe first, you decided then to go for for a small pilot. The Navigator right? Yeah Navigator is one of our younger propositions that means that the code base is rather fresh but it was built on what I call now traditional or legacy stack. I interviewed all the product owners in an organization together with with our CTO and we assessed okay which product fits fits best in this this mission? And being a young product, the Navigator had a young team of engineers that we had confidence in.
That's why we selected the Navigator. And the stack that the Navigator is built on is very representative. Which is nice for some other web applications. So yeah it was a really eager team wanting to learn, open mindsets, ready for change. You're hesitating... In a sense that like we, they did also not know what to expect. But that also proves that there was a lot of trust and that was also instrumental, in this in this first journey, was the trust relation of the engineers. Can you double click on that part, the trust part,
trust on what because that's not completely clear to me. Now we all know the management strategic slides about cloud native. The art is to to get your value out of it. And that requires trust because it was a very uncertain road a lot of question marks still in the implementation. We don't work waterfall, so we didn't plan in that much detail. We did the planning but
in terms of goals. It was like you were in the middle of a journey and the destination obviously was perhaps clear, but the road to the destination needed to be found out. Yeah, got your point. One of the things I remember was that you
were looking for a partner who could deliver the 'batteries included' model right? You remember that? Yeah, we had some discussions they were like okay we're not able to deliver that because it's so flexible still so we advise you to choose some platform, some container platform and and use us as a guidance. But don't pull those together. Let's do some statements and see where we went. Cloud native is all about technology. I'm quite opinionated about this part. Would really love to hear your perspective as well yours. It's definitely not.
I think every every shift in technology comes with change and when you're about to change you have a human part always. But I think cloud native is one of the first at least in my brief career that has so much emphasis on the human part because handled incorrectly cloud native will give you superpowers. But they should be handled with care and when onboarding such a journey be prepared that you need to change roles in your organization. You need to change responsibilities and that's easier for a small company than for a large company. Ortec Finance is around a 300 FTE company to put that in perspective. But still that means that if you really want to change an operational role to transform that to towards more to the developer side. For us that means
that we need executive commitment for this and eventually also the board needs to agree on such shifts. So you definitely don't need to underestimate that. I think it's 50/50. What did you experience in this project or
in this pilot. Did you change anything to your organization? Now first during the pilot we gave it the status of a project. So that we in our company had all the freedom to organize as we think that was best and we changed that many times. Also my vision changed many times. Because the surface that a container platform touches is really large.
It's current operations, it's the engineers. We have chapters that govern the standards in the company. They have a role in it as well and in the end you also you need a team to maintain and govern the platform and enable engineers in the onboarding process. What I like by the way. Also in how you've set things up and of course you know I said I was opinionated but I agree to me it's people, process, technology. All parts need to be beared in mind. But what I like as well treat this as a project. It's an agile approach, you're not opinionated whatsoever. It's a journey so you don't know exactly what's going to happen in there.
It's empowering also the team to become creative and to think outside of the box to make sure you focus on the innovation part. Celebrate also the success of this because again if the project is successful you're gonna increase the scope. And the project team members are gonna be the new heroes within the organization. Because they've achieved something extraordinary. And another thing that I like really is what to
do with super powers. If you get super powers it sounds like a Marvel comic story you know. So you really need to think about that part as well. I think it's a perfect explanation so thanks a lot. I agree especially about the super powers. I'm going to use it okay? Let's take the next one. Batteries included makes life easier. You came to us with the story about batteries included
and you were talking all the time about batteries included and I loved it very much because you thought you want as less hassle as possible as you just want to use it right? What did you mean by batteries included at the beginning of the project? I think it's twofold. I think first all container platforms are driven by Kubernetes. And you can start building your own platform, start playing vanilla kubernetes and build a lock stack on it and build a monitoring stack on it and implement your airbag. We acknowledged very soon that that's not our core business. We see some of our clients with a large skill doing this but they have platform teams with 50 FTE. We don't have that. And it's not our core business. So yeah first we want a Kubernetes platform enterprise grade
When a lock stack updates it can happen that other components of your platform are not compatible. We do have the expertise but we don't have the energy to constantly have the stack compatible. What I like by the way, sorry to chip in here, but I think this is also something from the Microsoft side we call tech intensity. We expect our customers to focus on stuff that's really creating a competitive advantage for them to compete in the market and take, you know, the technology stack for granted.
We're gonna have you back on that side and that's also you know especially the parts that you're actually explaining right now so the batteries should be included on that side. So we can focus on what we do best and that's to create solutions that bring us value for our customers. And the second part is infrastructure.
We don't want to hire people with screwdrivers anymore we have on-premise data centers and that so far worked worked excellent. But at a certain point the standards grow things like region redundancy would be very expensive to offer to our clients remaining on premise so that's yeah of course that's where the term cloud comes from. But we therefore preferred a container platform solution that was glued on top of infrastructure. Also the batteries included meant for us that we should be able to rely on the auto scaling of the underlying virtual machines of the vendor and not have to worry on that ourselves.
I remember discussions about I think it was the image repository and that you said as well I don't care as long as this battery is included. So let's see what the cloud vendors provide. Every platform has its own philosophy and when we wrote down our our principles, one of the first things we wrote down is managed services overdo it yourself. So that meant if we start with a platform we will continuously increment it with components or services along if developers need stuff or new components we should be able to cater for that and at the moment we were considering how to provide redis solutions and first we look in production and acceptance we want to rely on managed services In dev and in test environments we sometimes make exemptions. We just install the operator and and do it ourselves. But again that's the batteries included part. I like it. Next one. You can trust your vendor or hyperscaler
Again i'm opinionated. What do you think about this? No I think the trust in, all jokes aside, i think you know in the end also as a hyperscaler as a tech provider we build on trust. If there's no trust there's no future for us. I'm quite passionate to work for a great company like Microsoft because if you take a look at the innovation that Microsoft is providing now also to the market I'm really really proud to be part of it and obviously you know if we talk about the trust element if you talk about the security elements there are so many things that we're investing in.
We can spend hours on that part alone but of course it's not about me. It's about the customer. It's about also the partners and in this case of course we would like to hear your perspective. Nobody cares about what I have to say. Yeah, I think that's key.
The way we operate we want as little a tax service as possible. Cyber security wise. We had discussions with our security office and he was blown away when I explained him we don't have file system access in the platform ourselves. So even if even an attacker got our admin credentials or whatsoever, like a ransomware is out of the question because we can't do it ourselves. If we can't do it an attacker can't do it as well. So the remaining attack service will be from underneath. From our vendors.
We have significant trust that on the scale cloud vendors work they outperform us on what we could do ourselves by a big length. And I think also what's what's strong here is that the incentives of the the defenders in the market are really strong to be best in class cyber security wise. They need to be. I remember that when we were talking one year ago. All the cloud vendors were trying to get to you guys because they all wanted to you guys to work with them. So why did you choose for Microsoft? Pretend Renée is
not here. Pretending now... We first fell in love with the philosophy of OpenShift. That that was exactly the type of batteries included we needed. OpenShift offers a strategic advantage, of not to marry with a cloud vendor. Also our big clients that have multi multi-cloud strategies. That's there for a reason. For instance for safety, so not only commercial reasons. Now a lost what I was saying. Too much thinking and talking at the same time. Pick it up again because I think you're hitting
a really important point here. It's all about choice and you need to have and offer choice also to your to your customers in the end. And I think it's about multi-cloud. In the end also your customers need to have an access strategy. If you rely then on a single set of technology, or you're locked into a specific hyperscaler, that's not the way going forward. So I agree with you having having a solution a technology solution,
provided by Red Hat in this case OpenShift, that runs on every cloud even even on prem, that's also your escape route. Yeah that's a strong strategic advantage and why did we end up with ARO, Azure Red Hat OpenShift? ARO had a proven track record. By the time we had to decide AWS has a similar service by now called ROSA but it was still young and immature. And we are far more fun ;-)
No all jokes aside, I think the solutions are on par and I agree at that point in time we definitely had a lot of references already and we were in touch with you guys as well. We loved also the interaction and in the end it's also about people buying from people. In the end I think the account team had a good connection with you guys so yeah.
And the fast track engineers were amazing that really fueled our our transformation. You have that low barrier access to support even the most technical issues. To have that hotline was pivotal for our success. They're amazing. That was for database questions, for networking questions.
But also very trivial questions, like how to set up my cost management. Okay please direct me. All right next one. Managed to OpenShift versus managed Kubernetes.
Yeah, we talked already a little bit about this. We did compare. During the Navigator pilot I had a graduate student and I asked him okay we choose for ARO but show me how it will look like if we run it in AKS. That's nice. What I liked, and cost was never an incentive to do this, but cost wise these solutions don't defer that much. It's really about what fits your organization best and I strongly believe that managed Kubernetes for anyone operating on our scale is the solution and whether it's managed OpenShift or or AKS or EKS or whatever flavors we have. ROSA, whatever. It's a matter of flavor.
I think what I like on this slide is the choice element. As a customer you can choose and I think your statement is spot on. What's fit for purpose for your organization? And what I really appreciated also in this whole cycle and this whole journey we're in the middle of still. Is the role the partner played because in the end it's also about making sure that you get all the information so you as an organization can make a well thought and decision.
What's best fit for purpose for your organization and i think that's a critical role that's also something I will salute big time. Of course I represent this company, but nevertheless the open source ground principles, and they're about collaboration, sharing and openness. Making sure that everybody has the same, It's like you said before. We're in the middle of a candy store and there are all kinds of great candies out there, you like all of them, but which one are you going to choose? And having somebody that's going to navigate you, in this case HCS, that's helping you also to navigate you; what's best fit for purpose for us, and supplied you with all the information. That's something also that from our side we deeply appreciate. And it's on us to continue to deliver the proof elements that were the best choice for you. So that's my take
on this one. Yeah cool. I remember that our guys loved to work with your guys as well. Even nowadays and today again give them a puzzle and let's solve it together. And the funny thing is that we started off with batteries included. Can you deliver that? We were like, uh no. We can help you and now we're still doing the same thing and and we're learning on the journey as well. So it's cool, I like it very much.
Azure or AWS? Yeah... I think we assessed also the ROSA service like from a functional perspective and I think they are at par. It's the minor things like how support is arranged, where can I go if I have questions, how do they handle OpenShift updates, for instance how adequate are those... We didn't work with ROSA, but i would expect that it's very similar. But in the end you worked with Azure with ARO right? So we have students as well and one of the students he said well I want to finish my studies and i want to do a study on how do you choose your platform. I was like good luck to that. because there are so many ingredients that make a choice for a platform. Do you remember
what eventually made the choice of the platform you chose right now? Was there one trigger or....? I don't know. It can be relationship or it can be anything we worked with both Azure and AWS before and the procurement on that respect was done by our head of operations. So I was like yeah please do that. I don't have a strong preference and we landed on Azure ARO. I think the most important thing was was confidence that we got from ARO having a longer track record. Yeah I remember that, I think ROSA was a little bit later. Yeah it was announced in November 2020 and general available in February. That's exactly when we started.
Sometimes i can listen :-) I I haven't been in every session but as soon as I was in a session I felt a lot of energy. From you guys, but from our guys as well. And I remember an awesome session about data persistence. And the question is did you tackle it? I think so but not with the decision tree like this :-) What was the challenge with data persistence in a project like this? There are many aspects in choosing the right persistent technology, whether it's relational database or non-sql or file or blob or are using Kubernetes features. And then still do I operate
it myself or do I take it managed? What's not in your decision tree, is the licensing aspect you do have. When you start cloud native, you have the freedom. It's card blanche. You can pick and choose your stack. It's still the candy store, but you have to do that with care. It's tempting to choose for free open source components always. But that's not always the best case. One example is, we are currently making the architectural designs for our flagship product, boarding the cloud native platform. And it relied on SQL server relational storage
in order of magnitude; terabytes per client and when we started filling in the Azure calculator like the figures were pretty high, I would say. Like several ten tens of thousands of Euros per month for our storage need for that product. So we ended up with the solution which was still SQL server. But then the serverless version. Because our load with these heavy models is very burst like. It's beginning of the month or end of the year people start using it and that really made it made a big difference. We were able to to pay-per-use also on the license bit. Which made it a business decision whether you want to shift
to a license-free technology. But yeah then the difference, if it's pay-per-use, the difference becomes smaller and it's not for the software architects but more for the business owners to decide whether that feature is valuable or not. And what's also not in this picture is that we we give more freedom in dev and test environments. People can can request operators and then can play around. I think it's important for developers that if they want to use redis, they install the redis operator or whatever technology.
Once they agree with the chapters to onboard it in their stack, then we will think about the acceptance and production environments. And I think up to now we choose fully managed services for that. Just because we don't want to have DBAs in our engineering teams. So in the development space you give freedom and then there's a certain point in the production space that you say nuh-uh, we're going to do it with this managed services. They were not saying nuh-uh, we're saying what's the chapter saying and then we look at the case. Are you going to support this? Yeah but if it's a proven technology and we have a data management chapter which governs these quests. I like the creative part. At first you just test, just go out there use
the candies from the store and do whatever you would like with it. And afterwards you know once it comes to a certain stage then of course there are some processes in place. Just to make sure that since this is an environment that's gonna also impact your customers you need to be sure that this is completely stable. I like this approach big time.
So make sure that they can do whatever they like on this side make all the tools available But at the same time once this progresses then you need to make some solid decisions how this can impact also the the customer experience. I like it yeah. Lets take the next one. I mean if unless of course we want to have a webinar of one and a half hour of course ;-) Let's move on. We enabled our developers to deliver faster and write better code. Write better code I don't think a container platform will help you write better code. Maybe because you have more focus but that's also not necessarily true I think. No so what happens with developers, we perceive that they are developing faster. But that's not because they code faster but also because lead times are way less. Yeah you don't need to send a ticket like: I need a
virtual machine or I need to increase in storage. We choose for a self-service approach. So developers can most of the time cater themselves. But you do need to be very aware that instead of only building your software development teams are building and running their software. And we try to give developer experience for the full operations. So every also the running bit is is working a lot
with git and yamos. So the skills set is rather homogeneous. You work across the same set. Hey I work for my IDE with git and I can control the whole pipeline. However it does come with an increased cognitive load for developers. And I think for every organization that's different. But traditionally we are an organization that build software by econometricians for econometricians so we tend to like high cognitive loads. But also other organizations yeah you have self-service platforms that might be a better fit for them.
But nevertheless I think the additional task and responsibility, or the portfolio of the engineering team, increases. In what they need to do. And we can see we can do that budget neutral. So yeah, engineering teams don't have to expand. They have to change roles and they have to be guided and educated. Like you did with us the first time. And yeah, what's also key here is that our platform team enables. It's a really
different way of operations. Yeah I recognize that! The term harbor master... :-) Do you have a specific example you share on what you did with his team? Well I think the harbor master is a very nice example of somebody who helps the teams to find a spot and use the platform and work with it. And just I don't know they just help right? They enable. And I think that's the difference. I like the metaphor big time by the way.
Yeah yeah it's a nice metaphor. And we had a lot of discussions about that. Which is not at all technology related but it's related to the way you work. Yeah. And the way you behave. Yeah that's also like going from ticket ops to self-service with a harbor master it's like okay there are the toilets and there's your power supply. And that's nice but you have to help. You have to do it yourself right. He's just guiding. Was it also about reinventing roles then because the responsibilities were shifting obviously? I mean that's also what I'm hearing you talk about. Was that part of it as well? Yeah. Cool! I think this is amazing .
And to your point, when you started this journey and you were talking about goals you were talking about of course quality. But to your point it's not going to help you to write better code, but in the end you know the whole process, the output ideally is gonna be higher quality and deliver faster. Which was also one of the goals right? So I think yeah that's something that resonates big time. So this I don't know, did you create the statement? I did yeah :-) But the thing I like the most about your company is that it doesn't matter who you talk to but they want to learn. And that is something which is very key. And this is what we
experienced throughout one year I always think it goes faster, maybe you guys do that as well. Give me three months and I'll show you. It's not the way it goes. Is that really then also the growth mindset that's part of your organization and you know more learn it all you want to know everything you know you want to get to learn everything and all the new topics which are out there in the market.
Is that the culture within your company? We have an innovative culture indeed, but setting it up as a project also allowed for a lot of creativity. Instead of steering on proficiency we gave room to the creativity and yeah that's something that in retrospect i would advise also other organizations. that are about to onboard such a journey. But you have to make very clear agreements with the executives. Or you also need to project kind of what they can expect. That's something I liked also big time. You know your exec team was
highly involved. Also you know on the desires, you know when you started this journey. And in the end of course we're quite pleased with the outcome. So I think that's definitely a good mixture. Let's move on. We've changed our way of working. 100% ;-). I think how technology interacts with the human. We use a lot of Slack integrations. Instead of passively looking at dashboards, There are tons of dashboarding tools. But at some point we're like okay yeah that's that's very nice to have at your scrum board if your team is physical at one table. That's not the case.
So that's something we really changed. I remember we opened the Slack channel as well. Which was for us, i don't know the first time we did it. We do it now more often with customers and with partners. We're talking about teams channels right or :-) No but it was very awesome because everybody was like hey cool I can see what's happening there.
I think that's really nice. Change the way of working definitely. I think you know your first response: yes definitely! I think that's I like the emotional part of this one. Absolutely. Cool. We work intensively with vendors to challenge us Mostly to help us but... We can help you on the channel :-) Did you or? Yeah we have as I mentioned the fasttrack engineers. We worked with them. Anything Red Hat
related mostly was covered already by by HCS before we needed to call Microsoft. Yeah. I think also, that's my two cents. I think what I like and that's also I think the innovative approach, that you have. You're already challenging yourself big time. And I think that's also another reason why I said yeah we're getting support from the vendors obviously The way that you're approaching stacks is you know the tech intensity that I mentioned before. They just consume what's already standard out there and you focus also on the innovation.
And you know better than anybody the innovation that you need to address your customers so I think it makes a lot of sense. Yeah, and vendors do play a very important role, not to cherry pick the nicest logos and also don't over engineer things. That's a good one because that's also part of the superpowers. You get increased flexibility then engineers have to yeah ... No I agree, and I think the thing that we also liked in the collaboration altogether with Red Hat of course we provide this joint minutes service to the market where there's below the hoot there's of course joint support that we deliver to our customers. And in the end the business pains that we're solving because of this platform as a service offering that we have as a managed service that's really outstanding. And I think this is a great example. I agree. Last one.
I was expecting another one. It's sometimes considered as the the holy grail, right? Cloud-native. Yeah. I had to explain cloud native many times and my explanations changed over the year. And I tend to believe now that I think there's no industry definition of cloud native. But we learned that we do so many things differently. Like doing githubs, is also the way to go. Right? And yes for us a cloud powered container
engine is instrumental for doing all these things. For unlocking all these super powers. But in the end I think cloud native is just a movement. Maybe. That's fueled by technological advancements like cloud. Yeah, there's no, like you have maybe in art or in building architectures... you have these all kinds of movements as well, but you always have a counterpart. And I don't
think cloud native has a counter movement. Now even if you run stuff on prem you still most likely will use a lot of container technologies right? To me I think you know cloud native is about innovation and embracing innovation. And i think cloud native represents you know a certain stream of innovation with doing things a different way people process technology. Redefining also what it means to you as a company. And I think what's going to be the next big hit. We were talking about serverless already. There's all kinds of new stuff going on over there. i think embracing the innovation mindset, that's what it's all about. And I think Ortec Finance is
really representing that part in really embracing new ways of working. Embracing new technology. Embracing also you know to chance your own internal processes. Because in the end you need to serve your customers. You want to stay relevant not only now but also towards the future. And i think that's really something that we appreciate big time moving forward.
The thing i was expecting by the way was: What's next? Because i think cloud native is a way of going forward. But i heard through the grapevines that there's already some integration elements with machine learning maybe? Some other stuff going on? So maybe you can talk a little bit about that? Yeah there's a lot of stuff going on. So we do along the way indeed we also implemented some machine learning models. Traditionally we do a lot of econometrics. But we amended that with machine learning. And also we apply the
Azure ML platform for instance for appraising residential real estate like all the objects here in Amsterdam. That's a nice one. I think it's a half million objects you have to appraise manually otherwise. But our software is doing that and that's also fueled by AI models trained in Azure ML. I know a lot of my colleagues are going to be really happy to hear
this and want to know more about this. So expect some calls from my colleagues about this one. So it will influence how they levy your tax so I'm not sure... Hey I don't live in Amsterdam, so I don't see the issue :-) We might have to tune the model. I think this guy even he lives in the northern part of the Netherlands so he doesn't have anything ....
But what's currently fun to share is that we do have a strong high performance computing need. So we have a flagship product that utilizes Microsoft HPC pack and we are currently in the process of prototyping how these type of workloads run in ARO With Argo workflow. That's fantastic. And that's a very fun project. Really nice. We're still I'm not sure with the English term but, we're still with our hands in the dirt. Feed in the mud. Yeah with that project. But we have contact with the Argo engineers. And also with the fast track engineers. To be able to move our workloads from from a Microsoft HPC to ARO. And then we also heavily rely on the auto scaling capabilities.
Is it with the open data hub as well? Open data hub utilizes Argo as well. It's a Red Hat project. I'm also involved in Linux Foundation Umbrella project called OSC climate. What my team contributes is we build models that connect financial risk and climate risk. Because for long-term investors a 30, 50 or even 100 years horizon is very important. Now take climate into account then. Also that's driven by OpenShift.
By being involved in a lot of open source projects that's also how we get to learn a lot of these technologies. That's how we got to learn Argo. I think that's what I like again. You know collaboration, sharing, openness. I think you know we need to see if we can find some... You know I want to continue this conversation big time but
I think we're running out of time right now. But one remaining question from my side; I think in the audience there are a lot of people that will start on this journey. And what we've learned from you this is evolution to evolution to evolution. This is a continuous journey that you're setting up yourself. If you need needed to advise people that will start this cloud native journey. Can you describe in a couple of sentences what they need to do? Key elements? I think key success factors include: create internally sandbox environment. Sufficient room to not be constrained in in technology decisions. But also in organizational decisions.
And draw the process up front. And get an agreement with your executives. I think that that's key. Having access to knowledge and support. I think it's also crucial. And also, most importantly, have a dynamic plan. Don't think you can waterfall this. You will learn along the way and there's also no upfront solution that works best for you. You have to find out yourself. It not really depends on your culture. On your team topologies. And the level of change you can handle. The level of responsibilities you can bare. Yeah I like it. Exec sponsorship that's key.
Without that it's a disaster. Make sure that you get in touch with people that have done this before and I think you know in this case the partner HCS did a tremendous job in supporting you and making sure that they share that knowledge with you. And the last part; this is gonna be a cloudy road. You don't know what the direction of the road is going to be. So be flexible and have an open mindset. Stay curious. Yeah. Is that's a good summary? I think so. Cool. Anything to share from your side? No I'm very happy that we did this and I'm looking forward to the next episode. Well on behalf again of this whole team HCS., Otec Finance
and also on behalf of Microsoft, thanks for tuning in and we sincerely hope that you find this webinar beneficial. Any questions whatsoever feel free to reach out to us. All of us are on LinkedIn so reach out to us in case of any questions. Thanks for your attention and hope to see you soon. Bye bye!
2022-01-18 06:05
