Transcript
Porcelli: I would like to invite the panelists to introduce themselves.
Crispim: I'm Camilla. I'm based in São Paulo, Brazil. I've worked for ThoughtWorks since 2013. ThoughtWorks is a global software consultancy. My background includes working as a software developer, tech lead, and software architect. Now I play the tech director role. Between other things, I ensure tech excellence across all the teams in the portfolio that I work with. Also, I'm humbled to be part of the Technology Advisory Board for ThoughtWorks. I co-create the ThoughtWorks Technology Radar along with other luminaries in the industry.
Porcelli: I think you bring a wider view of the market, not just the financial institution, so we can benchmark.
Rettori: I'm Dio Rettori. I work at JPMorgan Chase, within the asset and wealth management business unit. It's one of the four business units within JPMorgan Chase. My responsibility is to lead the cloud adoption program for our LOB. That's what I do every day is assist teams and humans to move workloads to cloud environments, both public and private.
Porcelli: When you think about traditional financial institutions, I think JPMorgan is very easily associated with that role.
Cavalcanti: I'm Lucas Cavalcanti. I am based in São Paulo, Brazil. I've worked for Nubank since 2013. Before Nubank was launched, I participated on the whole trajectory of the company. Now I'm a Principal Engineer at Nubank, mostly handling the credit card product. Probably everywhere in the company, I have some opinions there.
Porcelli: You bring out this freshness FinTech, not just a FinTech, a very successful FinTech, considered the most valuable digital bank in the world.
Challenges to Handling Data in Motion
To kick off this conversation, I want to use Ricardo's session about data and streaming. One aspect that Ricardo mentioned that opened my eyes is when talking about batch processing and streaming. What I always had in my mind, batch is like the traditional window, batch process that financial institutions were well known for, in the past. It goes beyond that, how the data flows through your systems creates this latency that becomes a new batch. I'd love to hear from you, your challenges, what you're seeing in the market, to bring more agility to handle data, to handle this fluid data in motion that we see.
Cavalcanti: I think the financial services domain, it requires a lot of processing that don't necessarily have to be shown to the customers, real time, and so on. I think this batch processing, in like, I need to create a loan, or to run a renegotiation, or to transfer money between accounts, it's already expected not to be real-time. We do try to put it real-time for the customers. At least the customer side, it is ok for having this latency for most cases, and for the analysis part. Also, there are a few analysis that we would like to have in real time, but most of them, we look at the past a lot for analysis. Ingesting data from the batches to analysis, is also something that is usually ok to wait a day after or a week after to have the data.
Dealing with Large Amounts of Data
Porcelli: Dio, you're dealing with a huge cloud migration. How do you deal with this data, because I bet there's a lot of data there?
Rettori: The data that you have will be used for different purposes, and within that, different data protection guidelines apply, and data access needs apply, and latency needs apply. You want to specialize for all of those in order to be very effective. Our challenge is most of the challenge that we have, by the globally distributed nature, it's not whether or not we can create effective streams. More, can we effectively protect the data that's in the streams given the various places where they could land, or should land, or could not land by any means? It's hard to generalize about this. You would have to know exactly what data you are talking about, to then make a recommendation. Not generalizing, and being specific, it's probably a lot of the hard work. It's getting [inaudible 00:08:15] that allow you to see what work needs to be done, versus abstract conversations that don't do much. I provided an abstract answer. I understand it, but it's like, you need to be specific. Otherwise, it's just a meeting that could have been not even an email, when those conversations are happening. Not all data needs to be available right away. That's something interesting. Most of our business do not require single digit millisecond availability, but it does require the guaranteed delivery, for sure. That's the thing that's critical.
Porcelli: Lucas has just answered what case you do not need, since there are a lot of cases, and Lucas already brought up a few cases that you don't need the real time aspect of the data.
Where Streaming is Most Utilized
Where is streaming most used out there?
Crispim: It came to mind one of the cases that we had with one client and it was about fraud detection. I think this might be one of the cases where you want to have a quick answer. I don't know all the details about the project, but we were working with a huge amount of data and machine learning as well. The interesting part about this was we were dependent on a third-party vendor. We had to see how to be more independent on the third party, and be able to update more quickly the models of the machine learning so we could respond quicker and faster to the business needs. We were, in fact, using continuous delivery for machine learning in that case, in order to be able to evolve the solution. This is one of the use case that I think it's worth having a quicker response in financial services. I'm not an expert in financial services. I'm just picking one case where we had a good experience, and details about the solution.
The Impact of Cloud Architectures
Porcelli: Let's shift gears to cloud architectures. We have two sides here, the FinTech side and the traditional one. Both are talking about public clouds. That is something that's interesting, connecting a highly regulated environment. Lucas, you were born in the cloud, but now Dio is bringing these workloads to the cloud. What's the deep impact that you're seeing in your organizations?
Rettori: A tremendous advantage in telling developers, that the technologies they're working with, and the knowledge that they have, is valid outside of the firm. The more you build things in-house, the more developers feel that the technical knowledge, while organizational knowledge will go, the more you just use the things that you've built yourself, I think developers have the feeling that what I'm learning here is only useful within this firm. That's one of the obvious scale benefits that we have, is that, this thing that we are using with you, and we're training you and investing our resources so that you get good at, you're building your career, it's good for you. It's going to be good ever. Which isn't necessarily the case, or still isn't completely the case for some other thing. That is one obvious advantage.
The other is it makes [inaudible 00:13:33] folks that have been accustomed to public cloud world. On the architecture, it [inaudible 00:13:41] to allow you to retaining new architectures. It's the fact that migration or public cloud adoption is strategic for the firm, developers use that also as an opportunity to review and face a lot of tech debt that's not necessarily in public cloud, that's like around the ecosystem. Sometimes it's [inaudible 00:14:09]. Sometimes it's operational procedures. It's giving the opportunity to have those conversations, and adding that under this organization umbrella. Actual architectural differences, there are some but not many. We've been heavy users of containers. Our LOB has around 35,000 containers running production work across Kubernetes and Cloud Foundry. Folks understand that part, the ability to instantiate a workload anytime they want, scale up, scale down, and all that, so that's the benefit they have, but still they felt that wasn't really much intriguing.
Cavalcanti: Nubank was born in the cloud, so we didn't have to convince anyone to go to the cloud. The founders already saw the benefits of doing that. We started in a domain, in an industry that was not born in the cloud, like the financial services. In Brazil, Nubank was one of the first companies in the financial services that was born into the cloud. It took some convincing on the central bank, the regulators, to accept that we were saving financial data from people in a cloud, managed by AWS, that's not a Brazilian company. Sometimes the data will be moved. There was some gray area, whether or not we could store data just in São Paulo region, or if we could use the U.S. regions or not. It took some time from convincing the regulators that it was ok to run the services on cloud. That opened the door for probably all the other FinTechs in Brazil to also either be created on the cloud or migrate to the cloud.
Crispim: I do have a lot of thoughts on multi-cloud, public cloud, and things like that. I hear both sides, Dio and Lucas, there are financial services institutions who are indeed asked by the regulators to be in a multi-cloud environment. There are others that don't. There are many reasons why you should be in the multi-cloud, or you should pursue a multi-cloud strategy. We used to say that if you are in a startup mode, if you're trying to prove your business case, maybe multi-cloud is not for you. Maybe you should start in one cloud, and then see if your product proves itself. If it does, then you have a long term vision, ok, it's going to live 5, 10 years. You might want to look at the multi-cloud strategy.
When I say we, it's not only my own opinion, I bring the opinion of the group as well, because we do discuss that in the TAB, the Technology Advisory Board a lot. We don't see that you're going to have multi-cloud in the sense of having ability and portability capability to run in multiple clouds, for every single application that you have in your business. You're going to do that to applications that are business critical that you can't afford to have downtime, or you can't afford to have issues with the regulators and things like that. There is also like, maybe analysis that you're going to do in your business, application by application, and see whether the multi-cloud strategy applies, and what is it.
I see a lot of hype around multi-cloud, but I'd say, be cautious. Multi-cloud is not for everyone. It's costly as well to build portability within the applications, even though it's what Dio said. We do have containers. We do have the ability to do that in CI/CD pipelines. We do have the well-known software engineer practices in the architecture, like encapsulation, abilities to split the responsibilities. Those things are well known in the industry. It is costly. It's not going to be like days or weeks to do that. You must understand the tradeoffs of your investment upfront, or maybe when the time comes to see, ok, now it's time to go to another cloud. The risks need to be very well thought as well.
Kubernetes, the Front Runner
Porcelli: We are talking about single cloud, multi-cloud, on-prem, whatever, but there is one common topic among all these things, Kubernetes. Did Kubernetes win? This is the standard for the new generation that we are building now in technology.
Cavalcanti: I'm not sure how definitive is Kubernetes winning. I think at least using containers win, whatever that technology. We've been over the past decade moving through several technologies of adopting cloud and containerization, like from baking EC2 images on AWS to now Docker containers. The thing about Kubernetes is that it's not just Kubernetes, it's the whole ecosystem it created. By just using Kubernetes, you have that huge amount of plugins and tools that you can already use. That's pretty powerful. It is not a new idea. The Java power is also like that. You had a huge ecosystem around Java that you could leverage. You have every possible tool available for you to just download and use. That's the same thing about Kubernetes. It is winning so far, because it increases the creation and collaboration between the tools. The ecosystem is pretty powerful.
Crispim: For me, as a good consultant, I would ask why you want to use Kubernetes as a first question. Then if you're trying to use Kubernetes to avoid locking, it helps, but you might be locked in Kubernetes itself, and its ecosystem. You need to think about where you want to be locked in, if it's not for free. I echo what Lucas said. The ecosystem has grown. We have a lot of tools. It does help tons with developer productivity. It's definitely a good tool for container orchestration, the manager of the services in Google, and AWS as well. You get a lot of leverage when you're using it. I can't say whether it's won or lost. It's definitely well-established nowadays. I can't say about the future. Usually, I don't do bets like that. I just can't.
Cavalcanti: Just like any other technology, the answer to, should I use Kubernetes then everywhere? Is always no. There are always cases where this is not best technology to use. Don't use just because you want to use it. You have to have a reason. You have to know why you're using Kubernetes. Why do you need that complexity?
Crispim: It does add a lot of complexity. You don't want to add Kubernetes, because your competitors are doing so, or because people at QCon are talking about Kubernetes. You must have a good business case and a good reason to do so. Because yes, you're going to deal with a lot of complexity, is it worth? I'm not going against Kubernetes here, I'm just asking questions as a good consultant.
Rettori: I think my take is that what I like about the Kubernetes ecosystem is that it brought more attention to fixing our CI/CD and implementing automation. That's what I like. It's not about Kube itself. Of course, there's a lot of good things in it. It makes us ask the question, how much of the rest of my infrastructure or process is as automatable or as self-servicing or as capable as Kubernetes is today? That's what I like. I think, of course, there's a lot of myths, like Kubernetes portability. No, you're still tied to the base image. Base image should still be compatible with your host OS. It's not a guarantee that that's going to work if you move. Those myths of portability and compatibility are very interesting to be discussed.
It generated a very healthy conversation on fixing everybody else's CI/CD. That's because you need to be able to push images and push configuration at a healthy pace in order to effectively use that. You can't survive a manual implementation of Kubernetes. I think that healthy push to fix other parts of the pipe, it's been very important. Then you can think about how you want to work on CD later. You are able to, at a minimum, look back at all the things that need to be implemented. It's just another way of saying things like, you still have to implement firewall policies. They're called network policies today. All the same things are there. All the good practices they have to have before like, it's a new API, a new name, a new packaging format.
My point may be agreeing a lot with Lucas. Containerization is actually really good, because it forced the conversation between Dev and Ops. What was like a WAR file thrown over the wall to be picked up by an Ops team, to be put into an app server, and then implemented, now you formalize what the deployment package looks like. That deployment package has things that were Ops concern, and were Dev concern. Why? Because there's operating system dependencies that are in that deployment package, and they have the app in that thing. It forced that healthy conversation towards a DevOps model in the packaging itself. That's another thing that I like.
Cavalcanti: Kubernetes is good when you're in a microservices architecture as well. If you're on a monolith, if you're using Kubernetes, you're just adding a layer of complexity for very little gain. Infrastructure as a service solutions like Heroku, or Beanstalk on Amazon, like the way you just give them a container and then they deploy it. If your architecture is not microservices, Kubernetes is not probably a good tool for you.
Keeping Up with the Technology Pace
Porcelli: How to keep up with the technology pace. You are delivering business. You are in the financial sector. You are adding value on the financial aspect. Especially, like a FinTech, it's like there is this tech that is a very powerful word around this space. Of course, this is also critical for the incumbent, like the traditional ones, because I think no better sector understood that every company is a software company, than the financial sector. I'd love to hear how you keep up with the technology in the business.
Cavalcanti: The new and shiny technologies, they have several benefits, but they also have costs. Especially if we already have a company running, there is the migration cost that is very relevant. We don't just adopt a new technology just because it's new, and just because everyone is using. You need to get a clear benefit. We did get a good benefit from going from EC2 images to Kubernetes. It was a clear gain, or from CloudFormation to Kubernetes, it was a clear gain. Changing the whole architecture or the whole infrastructure, it's a huge impact. It's a huge cost. We need to have a huge benefit as well. A bigger benefit than the cost to justify. In a microservice architecture, you can always experiment with technology in a small scope, in a single service, especially if you're using Kubernetes. You can use whatever technology or containers allow you to use whatever technology you want to, into the same cloud deployments or Kubernetes deployments that you used to. You might need to solve for how to do some service to service integration sometimes. I think that'll be the thing, is only adopting a full scale technology when there's a very clear benefit, but experimenting on smaller scopes.
Rettori: If it's a huge change, there has to be a huge value and a huge benefit to it. There has to be someone that looks at that. While we're comfortable playing around with a few things here and there, as a pet project, or a weekend project, making the call, it's a big call to be made and you just don't make it irresponsibly.
Crispim: I can give you my two cents from a standpoint of looking at the Tech Radar. We do look at everything that's happening, or mostly what's happening across our projects across the globe. We do have like the assess ring, which is like, you should assess. Do a POC, and see, does it bring value? For me, the biggest learning is, it doesn't matter if you use the shiny, new thing. The point is how you use it, because what we are seeing a lot is how people use the new thing and recreate antipatterns from the past. I can give you one example, which is using API gateways to recreate ESB antipatterns, for example. We do see that a lot, creating a lot of integration issues. That, for me, is the main problem there. I'm very keen on the lean principles. You go with small changes. You don't try to change everything at once. Imagine Dio trying to change everything at JPMorgan, it's not going to work. You go in small cycles, and then you get whatever you learned. Then you apply better next time. Then you go conquering. Sponsorship is definitely something that needs to happen. It is indeed important.
Alex, you said something about financial services being one of the spaces that figure out that every company is a software company. I challenge that a little bit. I think the FinTechs, they definitely do. We still see traditional firms, as well as startups that sometimes don't have what we call tech at core. They are not tech at core. The business is not technology. They sometimes treat technology as commodity. They don't value developers. They don't value the voice of technology, and maybe they're not so successful because of that. I'm not saying it is, but maybe it is. This is definitely a mindset that needs to happen, not only in the financial services industry, but in every industry, otherwise, they're not going to survive in the long term.
Cavalcanti: I think at least looking at the landscape in Brazil, the big banks, the incumbents, they figure out that if they don't invest in technology, they will die very quickly. They are seeing the FinTechs take 20% of their customers in 2 years. Customers that they took 30 years to get, the FinTechs are getting in a matter of 1 year, or 2 years, 3 years. If they don't invest in technology, they will pretty much die slowly or fast, like blockbusters that did.
The Legacy Tech Connection
Porcelli: Adding to your challenges, I see that there is a connection about legacy technology or how you invest to update the technology. You're talking about Brazil, or whatever, you see IT world. A big piece of IT has been around financial services. All these big banks have invested on IT being on new shiny things, or more legacy mainframe aspects of the things. They're always investing in this area. They understand that, the numbers are just some bits and bytes somewhere that you are transacting, that's another layer of bits and bytes. I think that's what brings to these interests a little bit, a different perspective on IT, early days, then considered more traditional that would handle retail. You have a piece of thing that you will handle here and there. That's a little bit different. That was my perspective on that.
Rettori: I think what happened, fortunately, is that large financial services companies, for sure, but it happened everywhere, they realized that with the extreme waves of business outsourcing, they were outsourcing innovation, and that wasn't working. The other thing that happened is like, great, we can definitely take advantage of expert knowledge on technologies here and there. We're not going to transfer how we innovate to someone else. I see here in the firm we have a strong bias towards not having third party, because we want to own our innovation. To rely on third party, on the expertise that they have, most often a technical expertise, but to allow our group to innovate ourselves and have the ideas, and implement the ideas.
The business of outsourcing, from my little knowledge, is about doing the exact same thing at smaller costs every time. That's not certainly how it is sold, but from what I've seen, how it's been implemented. I think the investment to be better needs to be acknowledged. I'm happy for the healthy movement that I see. Companies need to figure out that they need to invest in tech. Lucas said, a bank losing 20% of the customers for a company that they didn't think it was going to fly a couple years back, that's a very strong signal that's being sent there. As much as the technology systems that banks have are large, I do not use the word legacy anymore. Because if you buy a new car, you don't call your old car, your legacy car. It's just your car. Your current systems might need to be improved. I think that the mess that exists when a large financial institution wants to make a change is also very large, because it's moving a large mess.
See more presentations with transcripts
