I sat down to speak about open supply and improvement with Jindrich Kubat, the Head of Development and the Chief of Engineers (COE) at Komerční banka (KB) within the Czech Republic.
Ben Rometsch: What is your official function at KB?
Jindrich Kubat: My official function is Head of Development, COE (middle of experience) at Komerční banka.
Ben: What precisely is your space of duty and day-to-day?
Jindrich: As the Development COE lead, I contemplate the experience, construction and capabilities wanted to make software program improvement profitable throughout a whole bunch of builders. We have roughly 600 individuals within the broader improvement crew, however I’m in a roundabout way answerable for managing them. I’m answerable for defining how they’ll do their job. So for improvement finest practices, requirements unification and so forth.
Ben: What’s your predominant focus at present at KB?
Jindrich: Our transformation challenge. We have the present financial institution, which is constructed on typical legacy banking programs which might be big, distributed monolithic structure programs. That is the place most of our builders (round 400) are working day-to-day because it generates the majority of the income for the financial institution.
Alongside the legacy functions, we determined to utterly modernize to one thing that we name “Digital Hub” which is changing the financial institution’s present infrastructure. The front-end functions are native cell and internet functions.
The Digital Hub and new front-end functions are constructed completely on microservices so we have now to revamp a variety of issues and introduce new tips for individuals. All of this collectively is what we name the “New Digital Bank”. It’s an enormous challenge!
Ben: Does this transformation cease in some unspecified time in the future?
Jindrich: We take into consideration the transformation in two predominant elements:
- “The New Digital Bank” initiative is deliberate for five years and we’re about 2.5 years into it already. It began small with a couple of groups that have been able to undertake probably the most trendy improvement approaches and it’s rising yearly. Today we have now about 180 engineers break up amongst 50 groups. Those groups have been employed externally or transferred over from the legacy programs. They are devoted 100% to “The New Bank” effort.
- The different aspect is tradition transformation. We name this “Agile 2.0” which hits the entire crew (each legacy programs and new programs groups). Adopting Agile and DevOps is all about adopting a brand new means of working. This shift is one thing that we’re driving with our legacy system groups as properly. While the constructing will come to an finish in some unspecified time in the future, the hope is that the brand new tradition will take maintain and be the brand new means of working at KB.
[ Read next: Agile adoption: 6 strategic steps ]
Ben: Beyond agile, have you ever adopted any new approaches?
Jindrich: Yes, there are three new approaches that we adopted:
- Moving to OKRs which aligns properly to Agile.
- We adopted a collaborative chat utility for all conferences, which has helped with distant work.
- We have practical “tribes” containing individuals and expertise that every tribe must develop and run its personal tasks or its personal functions. This aligns properly to the microservice structure we’re transferring in direction of.
Ben: What about tooling, languages and infrastructure? How do you handle that throughout so many individuals and groups?
Jindrich: As the COE, we’re principally answerable for the unification of how individuals work. We are fairly rigorous on this. We developed our personal KB framework, which we name Speed which is split into three elements:
- First is a Java SDK, constructed on prime of Spring Boot, which is a framework for constructing cloud functions.
- Then CI and CD Pipelines are used to automate deployment. This is constructed on Jenkins and Argo CD.
- Kubernetes is used the place we’re deploying and operating our functions.
We constructed our personal cloud infrastructure, so the whole lot must be on-premise at present. If a crew wants one thing, they should ask for it and it’s reviewed by my crew. If we have now one thing that solves their drawback, then we ask them to make use of that. If not, I’m open to adopting a brand new know-how.
We began with the Speedy Framework two or three years in the past and it’s nonetheless evolving. The first model was constructed for monolithic functions and monolithic works. We are on model 4 now. The microservice method was carried out in model 3.
The drawback is that we have now to observe some product updates and life cycles which is absolutely painful for us. Kubernetes, for instance, has three main variations per 12 months.
Going ahead we need to make it extra unbiased of those cycles and automate upgrades sooner or later. Interestingly, our dad or mum firm adopted OpenShift, which we’re maintaining a tally of. We’ll see if we unify the frameworks or not sooner or later.
Ben: It seems like you might be utilizing a variety of open supply applied sciences within the new platform. Have you all the time accomplished that?
Jindrich Kubat: No, we used a variety of the everyday merchandise like Oracle and Sun Microsystems. For the brand new digital financial institution we determined to undertake extra open supply applied sciences like Kafka and Flagsmith. This is nice as a result of they’re free, however we’re answerable for protecting it up and operating. This is a totally new mindset for groups.
Ben: Did it’s a must to struggle to make use of these merchandise internally?
Jindrich: No, they kind of simply accepted that as a result of they know the explanations. If we present them the contract with Oracle, how costly it’s, there’s an enormous enterprise case to undertake open supply. Even if it’s a must to have a couple of extra individuals to handle the infrastructure, it has a optimistic impression on our prices.
Ben: What about characteristic flags? Was that one thing that you just knew you wanted earlier than you began?
Jindrich: That’s an excellent query as a result of, you realize, even in present banks (legacy programs), individuals are utilizing characteristic flags, however they’ve developed their very own programs. They’re quite simple programs that handle the configuration file. And it was simply because the legacy system was solely deployed 3 occasions per 12 months. So you’ll be able to think about how troublesome it was to maintain all the guarantees from different groups. So they have been actually simply there to maintain the enterprise launch administration and testing on time and coordinated. It was simple to change on or change off some options that weren’t prepared for deployment.
But for the New Digital Bank we have now microservices and steady integration. We deploy each day to non-production environments. Interestingly, we solely have two non-production environments. One of them is just for testing in the course of the construct and the opposite is the ultimate non-production atmosphere (staging).
Ben: Was it a acutely aware resolution to have fewer environments?
Jindrich: Yes, that is an method I delivered to the financial institution the place we utterly redesigned some environments, and the way we deploy them. The purpose is to get to manufacturing as quick as potential to maintain manufacturing and non-production as shut as potential.
Ben: The “holy grail” is to have only one atmosphere— manufacturing. Surely that is not potential in your enterprise?
Jindrich: I’ve some expertise with that, the place you simply take a look at the whole lot in manufacturing. But in banking, that is unimaginable. A number of our builders cannot even entry the manufacturing atmosphere. There are laws. For instance, one regulation says which you could’t have a testing account in manufacturing since you are working with actual cash. Everything have to be “real” in manufacturing.
Ben: What do you do to mitigate that?
Jindrich: You have the smallest variety of non-production environments as potential.
Ben: When you have been choosing a characteristic flagging system, did you contemplate SaaS companies or was that one thing that you just instantly dominated out?
Jindrich: Yeah, we determined to guage three programs. Flagsmith, LaunchDarkly, and constructing it ourselves. We did three “proof of concepts”. First was with LaunchDarkly, then Flagsmith after which we checked out our personal homebuilt system. We selected Flagsmith not simply due to the system’s flexibility, but in addition the good help. The truth that you just guys are open supply and the good documentation additionally helped in our resolution.
Ben: How are issues going at present with characteristic flags?
Jindrich: We have been utilizing characteristic flags for one 12 months in our non-production environments which has been working nice. As for the manufacturing atmosphere, it took some time from a safety perspective to implement characteristic flags in our manufacturing atmosphere. The cause it took so lengthy is as a result of the particular person initially answerable for bringing characteristic flags to KB left. Then the safety crew modified their standards for analysis. Finally on the third time, we received it into manufacturing after passing all the penetration testing and necessities!
Ben: Making adjustments at a financial institution isn’t for the faint of coronary heart!
Jindrich: Yes, due to the safety requirements your complete banking business is absolutely delicate to this. Now we’re up and operating, specializing in the permission fashions, and logging the whole lot so it’s auditable.
Ben: Has it modified your workflow?
Jindrich: Yes! We determined to start out with the frontend, particularly cell groups. People have been ready for this functionality as a result of they’ve used characteristic flags in earlier roles. We have individuals on the crew pushing to undertake as a result of and not using a characteristic flag system, the whole lot has to attend till it’s absolutely completed. Now they’ll deploy to manufacturing and extra groups are onboarding to The New Bank. For these groups in a microservice set-up, it’s essential for groups to be extra unbiased.
So far, we have now about 85 engineers working with Flagsmith in manufacturing. That is sort of half of The New Digital Bank already!
Ben: Are you utilizing flags on server-side as properly or simply the frontend?
Jindrich: So far simply on the frontend, however we’re on the brink of roll that out with the backend programs that leverage microservices. That can be very quickly!
Ben: Are there any methods you need to use Flagsmith sooner or later?
Jindrich: Yes. We’re integrating the Flagsmith API into our bug tracker, with the ability to drive issues upstream, and have the ability to preserve the QA groups aligned with the product homeowners.
