ºÚÁÏÃÅ

Podcast Transcript

Alexey Boas:

Hello, and welcome to the ºÚÁÏÃÅ technology podcast. My name is Alexey. I'm the head of technology for ºÚÁÏÃÅ Brazil, and I'm going to be one of your hosts this time together with Ashok.

Ashok Subramanian:

Hello everyone. I am Ashok Subramanian. I'm the head of technology for ºÚÁÏÃÅ in the UK. And thank you Alexey.

Alexey Boas:

And this time we're here with Alexandre Goedert. He's head of technology for ºÚÁÏÃÅ Chile. Hello, Alexandre. Would you mind introducing yourself?

Alexandre Goedert:

Alexey, sure. Well, it's a pleasure for me to be here recording this podcast, and thanks for the invitation. Just a quick introduction. So I've been working at ºÚÁÏÃÅ for the past four years. Started in Brazil, stayed there for two years. Started as a developer there and then moved to Chile. Continued with some projects here in Chile as a developer as well. And now, I'm in this role of head of technology of the region.

Alexey Boas:

Okay, great. Thank you for being here with us.

Alexandre Goedert:

Thank you.

Alexey Boas:

Now, you have a ton of experience making the dreams of cloud migration come to true. And I know we've been hearing a lot of buzz about that from our clients or from the market in general. So what do you usually see relates to cloud migration, or what are people looking for?

Alexandre Goedert:

Right. Yeah, I think there's, in general, a lot of buzz in the markets and especially here in Chile and South America. And it's kind of interesting because it all started a while ago. So when we talk about Netflix, for example, and in 2008 they were the pioneers of this move. So they quickly realized that they couldn't scale vertically anymore. So they had some single points of failure, like database, and because of their business model, that that wasn't working. So they had to move. They used Amazon at that time. So I think it took some time until it gained traction in other regions. So what we're experiencing here in Chile specifically nowadays is that there is some sort of cloud running happening. So a lot of big companies, they want to move the majority of their infrastructure many times from on premise to the cloud or from private clouds to public cloud. Well, so it's keeping us busy here.

Alexey Boas:

Okay. So it's not just a cost play. It also relates to looking at these more innovative companies and trying to become digital to some extent as well.

Alexandre Goedert:

I guess so. I try to avoid this word of digital transformation, but the thing is clouds usually is part of this kind of initiative. So of course there's a lot of opportunity in cost reduction, especially if you use things like, for instance, out of scaling and if you try to just use the bare minimal resources that you need for your application. So you have this possibility when you go to the cloud. But oftentimes, it does not pay off to just look to this cost reduction objectives. So companies, they try to... What's happening in general is that they are losing competition to other companies or it's usually smaller companies that are born digital natives. So what happens is they try to use cloud and the movement, the cloud migration, to be more agile to be able to expose their internal assets that they acquired in years of customer relationship with the business like building their own business. And so it's all combined, basically.

Ashok Subramanian:

Yeah. So you're saying this isn't just like a trend because other people are doing it? Companies are seeing this as necessary for their survival almost?

Alexandre Goedert:

Yes, I think so. It has an important role in this transformation process, and I think companies are realizing that. And we're going to talk, I think, later on types of migration. But oftentimes, it's not just enough to do a lift and shift. So companies, they try to think what's going to be the best architecture when they move to the cloud, how they can gain more agility in delivering their pipelines and their applications, how they can gain more time to market, how they can react faster to changes in the market. So I think when you move to the cloud, you have better tooling to help you achieve those objectives.

Ashok Subramanian:

Alexandre, you mentioned a lift and shift as a term and there. I know that can mean different things. So when you're sort of describing lift and shift, can you give a bit more color to that term and say what have you seen in your experience organizations tend to do?

Alexandre Goedert:

Sure. And that's something interesting. So lift and shift's one you would talk about as a concept. It's what's the minimum way for you to move your current application that is sitting in your bare metal infrastructure or on different clouds to a target cloud? Yeah, usually a public one, but could be another private cloud as well. When you do this movement, the minimum configuration required is you try to mimic what you have already in the source system in the target one. So for example, for an application that is living in a certain machine type, you can just replicate the same machine type in the cloud by creating a virtual machine or a similar configuration and just move the same application.

Alexandre Goedert:

You can have some gains. For example, perhaps your target infrastructure is more stable and you have better support. But oftentimes, you have a broader amount of options in the cloud, in target one. So you have to analyze better if lift and shift is really what you need. And people, often they don't consider the effort of doing lift and shift by itself. Of course, it's simpler than much other options. When we think about all the dependencies you have in the source system, it's already complex to detach them and to do a lift and shift. So sometimes the work of doing these partial migrations could be better invested in rearchitecting or re-platforming and some other strategies. So that's what we usually analyze when we started doing called migrations.

Alexey Boas:

Yeah. It's interesting because it you talked about several different business benefits of going to the cloud, so from cost reduction to the ability to do innovation in a different way. And it's really a very nuanced strategic decision. So it's not just now we're on the cloud, but it does mean how have the applications evolved to be the on the cloud, and have the architectures evolved, et cetera. So it's not just a matter of rehosting and changing the infrastructure, but you also have to look at how do you want to evolve the applications as part of this process. Is that right?

Alexandre Goedert:

Sure. I think usually it's some sort of a journey. So sometimes this journey starts with a lift and shift. And you have to think of how this journey will continue it once you are ready in the cloud. Nowadays, for example, it's very tempting to... When you look into the scenario. So we have three major cloud providers, and they are starting to offer very similar solutions. So there's a lot of competition and many times they offer a huge discount when you want to move from one cloud to the other. And usually this discount comes together with a lift and shift scenario. "So I promise you a 30%, 40% discount if you just move quickly in a matter of months." So this might sound tempting, but what happens is that the efforts that companies take to do this lift and shift could be better invested.

Alexandre Goedert:

And I think, in general, it's better to do some better analysis when we start a cloud migration to see which kind of application you can lift and shift, which kind of application you can replatform, or which kind of application you want to rearchitecture and rewrite the whole thing. And it's sorry and a shock. So as we mentioned, also, just to connect with this journey. So that's the first step and then afterwards, so how can you keep putting more applications in the cloud? So what's the level of infrastructure you're going to use? How will you enable a platform for the company that takes advantage over the tooling that you have in the cloud? So I think that would be more like the second step.

Ashok Subramanian:

Okay. So in your experience, this is much more like a multistep journey to get to actually moving and migrating to the cloud, where lift and shift might be potentially a first step for some part of the application landscape.

Alexandre Goedert:

Yeah. I think it might be a first step when you think about the reasons why the companies are moving to the cloud. So many times, the companies are having some infrastructure problems, so they cannot scale anymore. They cannot wait for a rearchitecting strategy. And perhaps some critical parts of their systems, they have to be moved faster than others. So I think this should be part of the analysis as well. That doesn't mean that after you move some critical systems because of an availability problem, you cannot change them afterwards. So I think that this is all connected. And there's the different timing for every system. You have to analyze the dependencies they have. So these might play an important role in the decision-making process.

Ashok Subramanian:

Okay.

Alexey Boas:

And how about dependencies? So especially when we lift and shift things or applications without re-architecting, does that pull the dependencies into the cloud as well? Does that become a mess or...

Alexandre Goedert:

Yeah. That's an interesting pain point when we talk about cloud migration and migration migrations in general. So a once a lot of that has come on, many companies they have, or they used to have, a centralized database. And with the centralized databases there was the figure of a database administrator. So usually, when we talk about cloud-native architectures, we want applications that are more independently deployable. So if possible, we would like to deploy in more microservices architecture with independent databases, and then this creates a lot of problems. So people have usually two different approaches. One of them, you can nowadays create mechanisms. You can replicate a database instance, like in a master/slave scheme, for example. And then you can have your databases spread across multiple clouds. That could alleviate the problem at first. So if you were in a rush, you could use that approach, of course.

Alexey Boas:

You're going to still have to tackle that dependence on the centralized database at some point. Right?

Alexandre Goedert:

Absolutely. So that doesn't fix the problem. And again, I think this is part of the same analysis. So do you have time to move it properly and to fix the coupling problem when you do this move because it might pay off? You are already doing a lot of work so it might pay off to already decouple things a bit. And then we have some other strategies. So we tend to like the usage of events and messaging as a more agnostic way of synchronizing things. But it's important to know that this is usually a transitory period, so you cannot, of course, move the whole thing at once. So you have to select parts of the system that you want to move first, and you might need to synchronize things a bit until you finish a big chunk of the systems in the cloud. So this is another cleaner approach, but it's essentially a trade off.

Ashok Subramanian:

So there isn't a necessarily a target end state, but more like the part of evolution that you're sort of describing. So you need to be very aware of the sort of different architectural paradigms that exist between on prem and on the cloud. And as you're going through that transition, those tensions are something that you have to deal with on an ongoing basis.

Alexandre Goedert:

Correct. I think moving to the cloud is a huge architectural exercise at the end. So you cannot just try to use a silver bullet to solve your problem and both ways. You don't have the time and resources to do a complete rearchitecture, usually, and in other hands, you do want to do a lift and shift and finish having legacy in a cloud. So we have to find out what's the middle ground. And I think there's not a clear end state. But when we think about cloud-native architectures, I think there's a couple of guidelines that we can use. So for example, when we talk about the twelve-factor app that was started by Heroku a couple of years ago, these kind of things are guidelines that we can use to architect our applications in a way that is more natural to the distributive nature of the cloud.

Alexandre Goedert:

When we talk about things like I want to have the clarity performance for my deployments or I want to externalize state, externalize configuration. For example, there's a lot of things about fault tolerance. So I have much more failing points. I need to be able to live with fault. So it might make sense to implement things like circuit breakers, for instance, for example, to survive these scenarios. And I think there's a lot of things that we can explore, and that could be a desired end state. But it's a journey. So you have to plan carefully how do you want to go to that end state.

Alexey Boas:

And the end state is also dependent on the specific context that you have and the architectural needs that you'll have for those systems at the end of it.

Alexandre Goedert:

Exactly. Yeah.

Alexey Boas:

Now, Alexandre, you did mention different vendors and different features and also aggressive commercial strategies from them. We've been talking in ºÚÁÏÃÅ about clouds' stickiness for awhile. So it's lock in to a specific cloud vendor. How do you see that? Are there tools that help us avoid that? Or to what extent do you really need to embrace whatever the cloud provider offers you?

Alexandre Goedert:

Mm-hmm (affirmative). Yeah. That's a good point. Nowadays, we have a very varying level of infrastructure available in the cloud. Well, I think it's common sense from the main vendors that you can choose things that are closer to the bare metal, like creating your own virtual machines, dealing with network, having more control over the infrastructure. In the other side you have things like serverless, so you have functions or lambdas. So you put in that piece of code and you don't know where it's running, how is running, if it's just a server that is appearing and being spawned for you. So you have no control over the thing. So usually the left side of the spectrum is cheaper, so you have more control, and the right side is more expensive.

Alexandre Goedert:

And so I think about stickiness that is interesting because there is a movement nowadays about Kubernetes, for example. That's something that, of course, started with Google when we think about their own infrastructure. They had this product called Borg. It was their own implementation of the Kubernetes' principles. Then this thing became open-sourced. And the interesting thing is that the three main vendors nowadays, they support Kubernetes in a native form. So this shows a tendency. So what we tend to say to our customers is if they want to have this level of influence over infrastructure, they want to do fine tuning, they want to do outscaling policies and stuff like that, we think Kubernetes's a good approach because they keep compatible in the long run. So Kubernetes has been actively maintained, for example. That doesn't mean that people should not use App Engine or in the case of a Google App Engine or Functions. It's just they need to know that if they go to that path, it is stickier than the others. So I think it's analysis that people have to do as well.

Ashok Subramanian:

You had mentioned about sort of managing this and sort of making decisions, especially on configuring and so on. Clearly, each of the cloud providers have their own specific ways of managing the infrastructure as well. Is there something to look at how to avoid the sort of lock-in in terms of infrastructure management?

Alexandre Goedert:

Right. One tool that we actually use, and I think it's growing in popularity, is Terraform. It actually appeared in the doctoring in our tech rater. Our experience with Terraform was being nice in the sense that, well, first of all, it's a declarative approach to infrastructure. So when you look to the people that are often involved with this cloud migration work, there's a lot of people that are used to deal with infrastructure already and they know things like Chef, Puppet, Ansible. For them, it's a natural scenario to move to Terraform and to continue doing that in a declarative way. So in this sense, I think it's more agnostic if you considered all the providers that are being written for Terraform. So it's supporting the majority of cloud providers nowadays, and it's another way of becoming an agnostic.

Alexandre Goedert:

I think the problem sometimes comes when we use Terraform too much. So we saw, and I think it was famous on the internet a couple of months ago, an example of that. A person created a Terraform module to order pizza online as a joke. But that's the point. So many teams there are trying to do everything with Terraform, and sometimes it's not just the right tool to do it. Of course, it has limitations because it's declarative. But you have to wonder if you need actually some different tool depending on the product problem you're solving. So I would say it's good to use it but without any kind of abuse.

Alexey Boas:

Makes sense. Makes sense. And how about security Alexandre? So we hear lots of concerned people about security. On the other hand, the strongest argument is are you able to replicate all the security measures that your cloud provider has for their infrastructure? And the answer is usually no. So how do you see that balance these days?

Alexandre Goedert:

Yeah, security is something that sometimes is a misconception because people, especially very sensitive industries like banking or insurance, they have a tendency of look to the cloud with some sort of apprehension because of security. So the thing about cloud is if you think about, for example, Google, they run their own infrastructure in the clouds, in their own cloud. So they have to secure it. So when you think about the different layers of security you have... So in case of Google, you started from the hardware. So you have security mechanisms in the chips themselves. And these goes up all the layers into the application.

Alexandre Goedert:

The problem with the cloud is that the application layer has a huge surface attack. So we've seen happening some cases where it's easy to happen when you... And nowadays, with the advent of YouTube, they create service accounts that are like system credentials for cloud providers. And they create them and they then can by mistake, commit in their YouTube accounts. And nowadays, we have bots that in a matter of minutes, they just find the service accounts, and they start mining Bitcoins, for example. And this is a very realistic scenario. We saw it happening. So I think if people pay attention to the application layer, I think they can be well covered for the others. So it's just a matter of having security in the core of the team. Then it should not be a concern.

Ashok Subramanian:

So you had mentioned the transformation as one of the thing, clearly. And this is a big shift for organizations as they go through, and we spoke about some of the technical aspects and the technology choices that are available to people and some of the architectural concerns. But from a people and capability point of view, what is your take on that? What have you seen organizations having to do to try and adopt themselves and their capabilities and the practices to make sure that they can respond to this, the change?

Alexandre Goedert:

right, right. That's a very good question. I think it depends on the organization, of course. But here in our region, what we see is that when we have more traditional companies and they move to the cloud, especially when they have already a lot of infrastructure engineers that are used to deal with on premise infrastructure, they tried too many times to mimic the same approaches in the cloud. So for example, people might be used to dealing with a specific network topology of distributing IP addresses according to specific rules of the business, and these kind of things, they don't necessarily need to happen in the cloud. So when you talk about network in the cloud, usually it's a logical concept. It's not very often to have IP clashes and stuff like you have when you're dealing with your infrastructure when you talk about VPCs and the kind of network they provide. So I think that's the first problem. So people need to be aware of what is changing and not try to just mimic what they know because it's safer. This is one part of the change.

Alexandre Goedert:

The other part, I think, is usually people that are dealing with machine provisioning, people that are , they are skilled in Unix and shell. They know Puppet, Ansible, and things like that. Many times they're not familiar with engineering practices like, for example, continuous delivery or TDD or testing and stuff. And I think the interesting part of this movement is when we start using tools like Terraform, for example, infrastructure becomes code. It becomes much closer to the code. And because it's code, you can take advantage of the same engineering practices.

Alexandre Goedert:

So for me, it's a very interesting cultural change because if you imagine, for example, SID means usually they are doing support for developers. The developers are the people that are annoying them with their problems. "I cannot SSH into server. Help me please." And the Sidmeans have this image. "Oh, those dumb developers." And this is a very siloed idea and mindset, of course. But when you need to change this cultural aspect of Sidmeans, they need to become closer to developer practices. Sometimes it's not easy. So some of Sidmeans, they have years of experience, of course, and we need it. But how do you change his mindset? Especially if we want to talk about DevOps. So you might need teams that are multidisciplinary. They have a mix of different skills. So people that are coming aboard this new way of working, they need to embrace the new concepts. So I think that's an interesting thing that is not always easy.

Ashok Subramanian:

Yeah, it makes sense.

Alexey Boas:

All right. So we talked a lot about challenges of going to the cloud and some of the things you have to do to especially make the first steps. But you also mentioned being in the cloud will enable innovation and give you more possibilities from a technical perspective to evolve the technical system. So where to go from here? So once you are on the cloud or starting to do that or the beginning of the journey, what are the next steps in that journey?

Alexandre Goedert:

Right. We tend to frame this cloud migration idea with the concept that we call a platform thinking or platform strategy. So the thing is, usually, people want to move to the cloud as a big project first, and that we have to analyze all those things that we have been commencing here. But afterwards, what we really want to do is I want to create a platform for development teams to be able to go to the markets. So for example, it has many different aspects. So the first one is delivery infrastructure itself. So I want to be able to spawn your machines quickly to use resources like memory, CPU, easily. And of course, when we think about cloud, you already have very good tooling and very good developer experience, usually. But that doesn't mean that if you have 50 development teams in your company, you want to do 50 different configurations of the infrastructure for a very similar problem. This is very complicated.

Alexandre Goedert:

So when I talk about platform, I think this kind of idea. So we want to create some standards that are not in the way of the devs. So if people want to, for example, create a front end application that has only static files, I can easily put these in a bucket in the cloud and that would be the easy solution. Okay. So what part of my platform can provide it. And when I have like 50 teams that need the same thing, how can I enable this quickly for them? And the same thing for, I don't know, I need a server-side application, and I need to do fine tuning of the amount of pieces I need, the type of focus scaling I want to configure. So for example, I could use like an option with a Kubernetes cluster for them. This is the first aspect.

Alexandre Goedert:

I think the second one is once I have all these things in place, how can I have an API ecosystem on top of my infrastructure? And this is not very trivial. So it's easy to build an API in isolation in different teams, but it's not that easy to understand which domains and subdomains you need to expose in your organization as an API. So this is more like an architectural job that needs to be done in conjunction with the teams. So we think that the platform can help with that. So for example, if I have an API management, too, that is provided by the platform, I can build in mechanisms that can help teams to expose new APIs. So for example, I can use an open I as a specification. I can have a pipeline that will verify automatically the specification to see if it's according to the standards of my company. And all these things we can bake into the platform. It's a very long topic that we can maybe tackle later, but I think that's the whole idea.

Alexey Boas:

Yeah, that sounds, well, a part two to this discussion.

Alexandre Goedert:

Certainly.

Alexey Boas:

Okay. Well, unfortunately we're coming to the end of the episode. It was a great conversation and great to have you all with us. Thank you very much for joining.

Alexandre Goedert:

Thank you for the opportunity as well.

Alexey Boas:

This episode is in loving memory of our dear colleague and friend Rafa Nunes. While the circumstances did not allow for him to be with us during this conversation, he taught us so much about these and other topics. Thank you so much for all the friendship and the lessons dear Rafa. It's been an honor and a joy.