Episode transcript:
Jose
Hello and welcome to the smooth scaling podcast, where we talk with industry experts to uncover how to design, build and run scalable and resilient systems.
I'm your host, Jose Quaresma, and today we have Usman Mir with us. He is the SRE team lead here at Queue-it and has been working for over 10 years in automation and multi-cloud solutions.
We had a great chat about the considerations and challenges of implementing hybrid cloud solutions and multi-cloud solutions. A highlight for me was the different stories and experiences that he shared. Enjoy.
Welcome, Usman. It's great to have you on the podcast.
Usman
Thank you, Jose. Thank you for having me. It's going to be good to finally sit down with you for more than just a couple of minutes at a time.
Jose
That's true. And so, of course, for the listeners out there, I've actually had the privilege of working with you before. Before both of us joined Queue-it, back in our consulting lives.
And it's a pleasure to both have you on the podcast and to talk about this topic, which is multi-cloud and hybrid cloud and something that we worked quite a bit with back in the day. I'm happy to delve into that again.
Usman
Yeah. So, some of our old stories together as well, the things we did a little bit while apart. You were off for new adventures, and I was dealing with multi and hybrid cloud situations. So yeah, it would be fun to reminisce as well as talk a little bit about what has been going on here and go into considerations of where we want to take Queue-it in the future.
Jose
Awesome. So let's get started. Maybe before we go into the topic, into multi-cloud, can you share a little bit about yourself?
Usman
Yeah, well I've always been someone who has loved IT. So I grew up with the Commodore 64. So back when you actually borrowed books from the library, especially computer games books, where you took every page and coded it into your basic. All the way to becoming an IT professional 15 years ago, starting out as a Java developer, moving into a little bit of consultancy, as well as slowly witnessing the transition of when servers used to be in some client's closet or in their private data centers to migrating that to what we would call the modern cloud, or back then they still started out as data centers that had that branding. And then seeing how technology evolved from: how do you deal with hosting services or clients when they're on physical machines to virtual machines and then moving into the new containerized world that we now live in?
Jose
That's a good journey following all that progress, exciting. And let's start with multi-cloud. I mean, sometimes I still get confused. There's multi-cloud, there's private cloud, there's hybrid cloud. Can you try to help us a little bit with some very quick definitions or some kind of finger rules for what is what?
Usman
So it is a word that has been abused a lot in general: cloud. Because what is cloud? Cloud, in its basic essence, is still just a data center. But it has this buzzword where we say we are using the cloud. That usually means that you're using some cloud providers who can come up with some compute resources, perhaps some software as a service for your business to actually put in your business logic and run your business on.
Now, that one cloud can, of course, be distributed so you have some form of reliance there. You can have it in different regions. However, you're still relying on a single cloud provider. Also, you still have solutions that are running in your old school data centers. It could be that you are in an industry that is highly regulated or there are some legal terms that you are not allowed to put it into a public cloud. That would be, you know, your old school data centers.
And so there are a lot of: is that actually a cloud? Yes, kind of, because you can also use the same technologies, cloud native technologies on your local data center. But that wouldn't really be a public cloud.
So we have to introduce public cloud and private cloud as terms. Now, multi-cloud. You could say that, hey, I'm using multiple solutions in one cloud provider. That's not really multi-cloud, even though you're perhaps hosting it in different locations within that cloud provider's availability zones. That is not something that I would define as multi-cloud, that would still be using a single cloud.
However, when you're using multiple cloud providers that have their own infrastructures, then we can dive into the term; then you're actually using multi-cloud. Whether it's the same application that is spanning those different clouds or it's different sets of your business applications that are running on each, that's more of, you know, nitpicking.
And of course, going back to the example of having something still running in a private data center, if you actually use that as well as a public cloud and integrate them somehow, then I would say that you're actually running a hybrid cloud setup.
Jose
Okay, so private and public cloud, it's more around who has access to that data center or to resources in the data center. Then multi-cloud is how many providers you are relying on. And then you add hybrid as in are you having applications that are crossing in between that barrier between your private cloud and public cloud?
Usman
Yes. And again, these terms are a little bit stretchy so you can have that your application can be completely separated depending on which cloud they are. Or you can have services that are dependent on microservices services from various external parties.
So again, these would be the rough definitions of it. But there's always, you know, there is always a little bit leeway of saying, when you’re multi-cloud, when you're hybrid cloud, and things like that.
Jose
Has anything changed in the last year? I mean, is there any trend on how to use them? How often do we see customers and companies really on multi-cloud? Has anything changed there?
Usman
Yes. So, this goes for both the hybrid cloud concept as well as the multi-cloud concept, because we saw when cloud was first booming, that there was a huge push to get everything off your private data centers, reducing your CAPEX, and moving everything to OPX, and pushing it towards some of the cloud providers.
And that has a lot of benefits. You have your scalability. You don't have to manage your hardware. You can refocus on your actual business cases. However, it does come with the caveats that now there are coming legal frameworks that determine what you can actually put out there. You also have some consideration in regard to cost. Just because you have moved everything away from CAPEX doesn't mean that it's always optimal for that.
So the hybrid cloud scenario is an interesting one, especially in these very delicate times where there is both political turmoil, as well as legal frameworks coming in, especially here in the EU, where there are very strong data protection laws.
So there is very much a push to actually pull out of the public clouds and make more hybrid cloud solutions where you're not putting data that could be sensitive into the public cloud.
Now, multi-cloud. Well, again, there are several good reasons for actually taking such an approach, and I've seen that companies are realizing that there is a good reason beyond just: we're using cloud. This can be anything from financial: because using a cloud provider can maybe lock you into some contracts or financial situations where you say, “hey, we don't really have a good option to go out of here, but we have to keep paying these terms that we originally signed on.” So there can be an incentive to spread out across cloud that might be specialized in different ways where you can take different offers into consideration.
Then there is also the aspect of which cloud providers you are using. Are you using some that are within regulations of foreign nations that might come in and block you from optimally using your cloud provider? Or you can risk that some of them are ordered to deliver your sensitive data to their governments. So you might want to go for a multi-cloud solution where you're also using something that is within your sovereignty.
Then there is the question of reliability, which when we're speaking today, we just saw a big incident happen with the Cloudflare yesterday. And I would say from my perspective, that has been probably the most relevant for the clients that I've seen in my consulting days, is that people are very much focused on that: “hey, cloud is not reliable. Even the biggest hyperscalers are actually not up all the time.” And then it becomes an evaluation of: are we actually able to take the loss of relying on a single cloud, compared to what it would cost us to have either a cold setup in a different cloud provider or maybe run with a hot hot setup?
Jose
And can you maybe, before you can you maybe explain a little bit, a cold setup and a hot, hot setup? How does that work?
Usman
So if you have a service and you want to host it in different setups, so different clouds, you could, have it like you have it only active on your main cloud while you're taking backups and having a recovery feature being available on your secondary cloud, which is not active. So it's not burning off your money on compute resources. It might just be using whatever it takes to take backup storage. It might have some reserved instances that are shut down and not costing you too much.
While a hot-hot setup is that you are basically running your services on both or multiple clouds at the same time. And maybe you're load balancing between them or your directing specific users to specific clouds. So there can be various strategies and reasons to use that. It could be that in one region of the world, you are hosting on one specific cloud provider, but in a different region of the world, you're using another cloud provider entirely. Again, this could be a price reason, or this could be political or legal reasons.
Jose
As with a lot of things—and we've also in the previous episode of the podcast about resiliency—it feels like there's a strong balance to be thought about here in terms of multi-cloud and hybrid cloud, which is kind of back to: how much risk are you willing to take? And how much time and money are you willing to put into reducing that risk? And how much do you want to reduce it, right?
It feels like, when looking at hybrid and multi-cloud, that's a big part of the consideration. How much are you willing to reduce the risk, I guess to acceptable levels, right? Then there's the definition of what is an acceptable level, right?
Having a cold setup will be cheaper, but then I guess it would take longer than if you were hot hot to recover, right, or to get the system up and running again. So is that something that you've seen often having those discussions?
Usman
Yes, because in the end, at least for the private sector, it's very much a cost exercise. So it's really about, well, “what does it cost us to run a resilient setup versus having a risk? And that risk, how much would that cost us if there is a disaster? And what is our recovery time from that disaster?”
So in the end, it is about making that cost exercise, going in, analyzing how long can your business be out of order, to what degree, compared to the cost of having either a hot hot, or a hot, cold setup.
But then we then move away from private business and move into, for example, the public sector or private business that has to live up to certain legal requirements. For example, the financial sector might be one of them. Then you also are, you know, having to consider what is the legal framework that your business can exist at all, because there might be, especially here in the EU, there are actually regulations in place as well as regulation coming up that will impose stricter resiliency demands on your business to have in place, especially financial institutions.
Jose
When we're talking about kind of hot-hot setup and hot cold, part of it is also the portability aspect of your system, right?
So I guess in a multi-cloud setting, if you really want to run hot-hot, ideally you do have a fully portable setup that you just can deploy to one cloud and to the other and just run. How do you see that? Because I think we have been discussing this in the IT world for a long time with containers and with Kubernetes. Are we really there? Or is it also a matter of to really get there, there's also some cost?
Usman
So from a technical perspective, the options are there. But it is something that every business has to take into consideration of how much of their legacy frameworks they need to modernize. And this is unfortunately not trivial, because there is a lot of technical depth that might go into any product that a business runs that would not be easily transferred over to an optimal containerized environment.
But it is where everyone is moving towards. And we see more and more that everything is being containerized. There are still some holdouts. I would say that I'm shocked to this day that there are still some recommendations of very fundamental software where the recommendation is not containerization. Whoever the consultancies or third-party vendors, I see that are still running off more old-school. Sure, it's still a virtual machine, and you can still image that. You can still build up your whole deployment process and configuration, so you can get up and running as quick as possible. But it's still not admired in old-school ways of doing it and mitigating issues, rather than taking advantage of the more cloud-native technology we are using like containerization. But I would expect that we will move towards full containerization within the upcoming years.
Jose
Is there anything missing to really get to that place? I don't know if it's this ideal world of full portability within containerization. I feel like the tools are all out there. Then the question is, are you willing to, some of them you do have to pay for? So is that where we are or do you think there's more progress to be made?
Usman
It is a more of again, time and cost perspective because there is the matter of training your experts to get to a level where they're… because they're expert in what they've been working on for several years. However, cloud native technologies like containerization, while it has been here for some years, it's still a new technology. It's a new way of doing things.
So there can be a lot of holdouts, and it can simply just take time to take your old way of doing things and deploying things and moving it over. So it becomes, again, a cost exercise, do you want to invest in using more modern technologies? Do you want to invest in solving the issues?
Because I'm not going to lie. It's not going to be without issues to taking applications and containerizing them if they've never been built for that. Also, you have to distinguish between do you have something that is stateful or stateless?
Stateless? That's easier for us to just containerize and run that. But if you have to manage state and meaning that you have to have something that saves data, it becomes a little bit more complicated, especially when we're dealing with something that has to be distributed or multi-cloud, because you want to make sure that your state or your stored data is available to any location that you might be deploying to or serving from. And then we're dealing with physics with, “hey, you have X amount of data, and it needs to be available in Y amount of places within Z amount of time.” So are you able to make sure that that replicate happens in a latency-friendly enough time depending on your application? Are you able to be able to survive that some regions go down and you might have a little bit of conflict? Have you thought that into your architecture? So it is a process that we will get to. I see all businesses moving towards that, but it's not trivial.
Jose
Very interesting. And we’ve talked quite a bit about containers. How do you see then the more the DevOps world or side of things and the way of thinking? Do you see that as a requirement for multi-cloud? How do you see those interacting?
Usman
So I would say it's not a strict requirement, because IT people will find some hacky solution and make it work for them and basically that's what we do. We find a solution to make life easier for us even though we might spend an enormous amount of time doing some automation for something that would only have taken us five minutes to do. But it is something where it's being refined.
So sure, you might have your old school Jenkins setups that are deploying through a pipeline, and then you have to manually copy. I've seen that in companies where the process is basically, “yes, we'll compile this on this server, and then we'll zip it and then manually copy it over to these servers and so on.” But yeah, we are also moving towards more modern development pipelines, where we're simply, you know, pushing things from there. But again, it takes time.
Then there's also the mentality of, well, should we be pushing this manually or should this be automatic by some GitOps approach where you're maintaining your state and having an application ensure that your live state is reflected on your configuration?
So, yeah, there is a lot going on there. but I'm seeing companies in various stages of where they are. Again, it is something that is coming. I don't think we can avoid it, which is a good thing because it also reduces error as far as I've seen. It will introduce a lot of new errors, but at least it will reduce the errors that we're seeing with a lot of the manual processes and more old-school push processes.
Jose
So if we have someone out there listening, and they're maybe in one cloud, or maybe they are still on data center, on private cloud potentially. So getting a little bit to the how of multi-cloud, right? So how would you suggest that they go about kind of considering a multi-cloud or hybrid cloud approach and then how would they go about it? I know I'm asking about a very complex process, and it sounds very easy maybe to summarize, but are there any main pointers that you would share when people start thinking about it?
Usman
Well, first of all, it comes down to making an analysis of what do you have and what would it cost you to… or are you even able to move this setup that you have currently to another data center? Just to see, “hey, if we have a one-to-one move, can we even do that?” Because that would be, you know, the first thing to consider it.
Then there is the question of, all right, “are we in a phase where we want to modernize our infrastructure stock as well as our application stack?” Because then it makes it easier to consider in, “well, we might be moving technologies anyway. So let's ensure that the new technology that we choose is something that is more cloud native.”
Once you then have identified those areas, I would probably do it iteratively. So, you know, everyone wants to take the whole block of your services and application and move them over. That's optimistic. You will have to take it in an iterative approach, identifying these, the easy wins like, here we can containerize this and create a service from that. Great. Let's for a time run a little bit of a hybrid architecture where we still have something running on old school virtual machines or even bare metal and some of it, we might be putting into containers and running as services alongside.”
So a step-by-step analysis of that and of course in the end every project fails if you don't take the economics into consideration. So, yes you want to go to the ivory tower of everything is containerized, self-healing, no-touch operations, all that. But It's not an easy journey. It's not a trivial journey because there is a lot of time that must be spent making sure that every little bit of your business still is resilient and is working. So, yes.
Sorry, it wasn't a good answer, but it isn't something that is one size fits all.
Jose
And I mean, I think it was a good answer. It's also very, I guess it's hard to make it in simpler terms when it's such a complex issue as well, right?
But one thing then when thing about multi-cloud and is, I guess we touch a little bit upon it, which is kind of the vendor lock-in part, right? So do you think that that's something that people should also be considering from the beginning? And where do you see kind of the main pros and cons of that?
Usman
So vendor lock-in is, especially for the cloud, has become a serious problem when you unfortunately have to take into consideration that it's not only technical issues that might be plaguing your business. There might be these days, political reasons to be able to move from one specific cloud to another.
So that means that the way that you design your new infrastructure to run the cloud should be portable from the start if you're starting on that journey. So you should have a plan where you move, iteratively, but move towards implementation that is easily migratable from one cloud to the other.
And fortunately, the technology that we're using these days with containers, Kubernetes, things like that, are very portable from the start. Sure, that might be the last couple of percentages that you need to reconfigure or remodify because you're using another vendor or another solution and things like that. But we're not where we were 10 years ago, where we were heavily locked into specific ways of doing things.
Jose
That's a good point. And I think maybe the last percentage point, maybe that will never be fully portable, right? Because then I guess there's also a balancing dose as well that, okay, maybe if I go to something that is less portable and more specific to a specific cloud provider, maybe you get the better performance or better cost in that area.
But as long as you are conscious of that and know what's the cost of move it and what you would move it to if you'd have to move to a different cloud, I think I guess you'd be in a good place, right?
Usman
Yes. And you will have to accept that the solutions that each cloud provider provides are not equal. Sure, they might be feature completely equal. But in most cases, there will always be, “hey, we offer this little bit of extra bonus” or “we're a little bit better than the other guys.”
So it's going to be a little bit of pros and cons, but we are in a fortunate state where if you're using more cloud native technology, it should nearly not matter. Again, it will be the last percentages. And of course, one thing that might be of concern is how locked in are you with specific cloud vendors, who own many services, and do you need to start working out solutions where it is more independent of those. Because not all cloud providers will have the same amount or the same types of managed services.
Jose
I think that's some good points to think about when I guess starting this journey or for people on this journey that might are thinking about all those different things.
You said you've been in this world for 15 years, maybe not in the container world, but in this IT world. Do you have any kind of specific stories that come to mind? Maybe we could start with things done in a very good way, some really good examples of a migration kind of towards cloud, anything that comes to mind?
Usman
Well, there are a couple of stories. Let me see how I can frame them in a way so we can actually talk about them, because a lot of times this is a process where that has had a long time underway. So I've been part of deliveries where we had to, you know, look at where the client is today? How much work is it?
And for example, taking a telecom. They might be wanting to utilize that, hey, we have some services. We're hosting it ourselves, but we might have a couple of things where we're not able to deliver that ourselves, but for our clients, we need to also have our management service run on something where they want it locally or in a region-restricted cloud vendor.
So we had to take into consideration in our architecture to see, £all right, where are you today? Oh, you're running old school virtual machines. Let's take a look and see what do you have here?”
So step by step, what we did was identify each of their application stacks, how much was it something that they had homebrewed. That makes it a little bit easier for us to help them transition towards a more container-based environment.
But then we also had to take into consideration they were also using software bought by a vendor and that wasn't supported in a containerized manner, and they might not be in compliance with the licensing if we just containerized that.
So the approach was kind of a hybrid approach where we couldn't take everything and containerize that. However, what we could do was take that application, split out the part where we either had the license or it was self-built, containerize that, put it onto a Kubernetes cluster in the two targeted environments that we're going for. And then seeing, well, all right, can we take this old-school application stack and redeploy that to these two data centers?
I would say it was that due to some requirements, it could only land in one center, and we had to create connectivity between the various services that were hosting the other cloud. But we did manage to get through after quite some time. But, yeah, again, it wasn't trivial because it wasn't only technical concerns that we had to deal with.
Jose
I think that's often the case. One could argue that maybe the technical side is maybe the easy side. There are all the constraints—and maybe that’s an exaggeration.
But yeah, I was thinking about multi-cloud and hybrid cloud in my experience as well. And one of the things that I remember being talked about is from a hybrid cloud perspective, this idea that you can have the best of both worlds, right?
That you have the application running with a baseline in terms of from a load perspective, right, that you have that running in your private data center, but then when you have peaks, you kind of, in a very smooth and automatic way, extend the resources you have by leveraging the public cloud.
So have you ever seen that really work? Because I've heard about that quite a bit, but I've never experienced that myself. So I'm just curious if you've seen that.
Usman
So I haven't seen a solution where you have done it that way, specifically. However, I have helped design such solutions that unfortunately weren't put into practice due to other reasons.
But it is very much about being able to detect your incoming load, and then making sure that you direct it correctly because you can always just put a cap on what you're directing towards your private data center where you have limited scalability and then directing the rest of your traffic towards the public cloud where you can scale up as much as you want.
But again, you have to consider your stateful data and ensure that is consistent across… especially if you have a, an application where the user itself is not tied into a specific cloud location. Because there are some types of implementations where it's basically a little bit more random where you end up.
So unless you can lock that specific sessions end up in a specific data store… And that is doable. It does take a little bit of consideration into, “oh, we have to make sure that this is directed, but do we then want those clouds to be completely independent so that they have their own data sets that are not dependent on each other?” And maybe you do some post-processing on, a copy of that.
So in this case that I was dealing with, unfortunately, there were some other ramifications that put a stop to it, but these were some of the concerns we had to think of is, “well, all right, do we keep the data separate or do we have a cross-region approach here?”
Jose
And so, starting to wrap up the episode here. So one thing that I would also like to ask about, so you've joined Queue-it now three months ago? But is there anything new that you've already learned since you have joined, or something that you had to unlearn since you have joined. Anything comes to mind?
Usman
Well, every time you join a new project you have to take into consideration the history of the place and why are things done in the way they are. Even if you come in and say “hey I've seen this been done in a newer way, or a more what I might personally consider a better way,” you still have to take into consideration that there is actually historical reasons for why it's done like this.
Sure we're not using some of those modern processes that I've seen in other projects, but there's actually very good reasons for this. They might be tied up to specific implementations that are running very well, or they're supporting a lot of clients end users and things are just running optimally and messing around with that can break a lot of things.
So it is something where I have to take a step back and say “this is done like this, great, I want to get to a place that involves improvements on that. How do I make the plans that we move towards that?” That might be something that is done over maybe a couple of months, or it might be something where I say, “all right, we have to take it in an approach where we, in a year or two, are closer to having that maturity.”
But again, maturity is also a relative term because it has to support not only the business processes, but also ensure that your development departments are following along with that. Because in the end, it's their product that has to be supported by a platform team. And it can be the platform team is driving how the development team is designing the product, but they can influence how to support it.
Jose
And I do know that kind of cloud and multi-cloud is something that you're thinking a lot about these days and maybe doing some work on. I hope that in a few months I'll be able to invite you again. And I think I can do that, so that you can come back and share a little bit more about maybe our own journey and our own considerations when thinking about this.
Usman
Definitely. And in a couple of months, we will be that much wiser. I won't promise that we have achieved the ivory tower of a multi-cloud approach, but we will be on the way. We will have some ideas of how do we improve our process of moving towards that? What is it that we need? And are there considerations that are, you know, holding us back? That might be very good considerations.
Jose
Awesome. Love it. I'm looking forward to that.
And before we wrap up, I do have a couple of quick hits.
So the first one and just don't think too much about it. And if it's a short answer, great.
So the first one, scalability is:
Usman
Extremely important for us.
Jose
Another one: is there a specific kind of resource, and by resource, I mean book or podcast or, blog or person out there that you would suggest anyone to follow or read or?
Usman
I very much like Jeff Gerling's blog.
Jose
What are the main things that he covers?
Usman
So I like that he covers things like automation, which is a subject near and dear to my heart.
But also, he tinkers with. various things like raspberry pies and make some mini projects, which sometimes it's just fun to get invested in, you know, technology that is a little bit of a toy, but still is something where you say, “hmm, how can I apply this?” Because it just opens up, sure, it might be very different from my day-to-day work, but it still gives me a couple of ideas, maybe just keeps that enthusiasm for technology alive.
Jose
I don't follow the blog, so I think I'll have to do it myself as well.
Last question. Which advice would you give to your younger self, or maybe to someone at a kind of starting a career in this area right now?
Usman
Failing is always a good way of learning things, and remember, it's always the most fun when it's burning.
Jose
Very good. Awesome. Thank you so much for coming by.
Usman
Thank you for having me.
Jose
And that's it for this episode of the Smooth Scaling podcast. Thank you so much for listening. If you enjoyed, consider subscribing and perhaps share it with a friend or colleague. If you want to share any thoughts or comments with us, send them to smoothscaling@queue-it.com.
This podcast is researched by Joseph Thwaites, produced by Perseu Mandillo, and brought to you by Queue-it, your virtual wedding room partner. I'm your host, Jose Quaresma. Until next time, keep it smooth, keep it scalable.
[This transcript was generated using AI and may contain errors.]