Join a real-life journey on the road to cloud-native

Join a real-life journey on the road to cloud-native

Show Video

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

Show Video

Other news