Q&A: Adam Stipkovits, Global Aluminum Manufacturing Company

(Editor's Note: We conduct regular Q&As with cloud technology leaders as part of our Cloud Tracker Pro service. We are offering this Q&A for a limited time, before it goes behind the CTP paywall.)

Adam Stipkovits is a cloud and network architect with a strong background in cloud networking security. Over the course of his career, he has designed secure and scalable network architectures for many of the world’s largest enterprises, including firms such as Citi and Deutsche Telekom. With expertise in Azure, AWS, Google Cloud, and Oracle Cloud he’s been in demand as a contractor as well as working as a full-time employee. His work as a senior multicloud solution architect for Aviatrix led to that company honoring him as a “cloud networking hero” on the Nasdaq billboard this summer in Times Square, New York.

Futuriom’s Mary Jander interviewed Adam on August 6, 2024.

Adam Stipkovits

Futuriom: You’re an expert in multicloud technology from both the vendor and end-user perspectives. What are the biggest challenges in multicloud right now from each perspective?

AS: When looking at the vendor’s perspective, I would say the biggest challenge is staying relevant. If you have a product that overarches multiple clouds and multiple CSPs [cloud service providers], and all those CSPs are developing their products at a very fast pace, it’s not easy to keep all your integrations up to date and stay relevant. I think that’s one of the challenges—how you bring additional value on top of what the CSP brings while basically still giving your users the best of what the CSP has to offer. And that’s probably the biggest challenge from the vendor’s perspective.

When looking at an end-user perspective, I believe that even if you have multicloud tools they are very fragmented. There is nothing like the AWS console, where you have everything there for AWS. There’s going to be different verticals, there’s going to be security tools, there’s going to be networking tools, there’s going to be other tools. There is no one big tool that you buy or you use and then everybody in your organization just goes for that. It’s going to be fragmented, and different teams are going to use different tools and they’re not necessarily going to be aware of what the other teams are using, so this kind of fragmentation can pose a challenge.

Futuriom: What can multicloud vendors do to help out with these challenges?

AS: They have to add additional value. Just doing what the CSPs do from a single portal is a small value. The value comes from additional services building on top of CSP services. I think that’s very much required. And what many vendors do not necessarily consider—even if they do they don’t necessarily have the resources—is that most of the big enterprises are hybrid cloud users. So it’s not just about the cloud, it’s also about on-premises and integrating with on-premises.

You have to be able to view it holistically, you have to understand what’s in the cloud, and then you have to understand how that all connects to on-premises and how it all ties together into one big architecture.

I think not many multicloud vendors are good at extending this kind of visibility or understanding to on-premises and it means that there will still be a significant fragmentation in technology.

Futuriom: Speaking of on-premises, we hear a lot about hybrid cloud and repatriation and that organizations are maintaining substantial on-premises estates.

AS: I think for big enterprises on-premises is almost always going to be there. For tech companies maybe not, but for other companies such as those in manufacturing, you simply can’t put everything in a cloud. There’s always going to be systems that need to be physically collocated with your plant and there is no way to move that into the cloud.

Other companies—think about financial institutions—there’s always going to be on-premises requirements for these big enterprises. It’s never going to go away, there’s going to be significant on-premises, the amount will depend on a company’s size and vertical. Now whether on-premises is growing or shrinking I think it again depends on the company.

I have not seen directly any company I worked for or worked with who started cloud repatriation. I think repatriation is more likely a thing for companies who are tech-focused, where their product is technology. For most companies their product is not technology, and for them I think the cloud makes a lot of sense, even if it’s a bit more expensive. Companies are finding out now that it’s more expensive than on-premises in many cases, but you save a lot on reduced complexity of infrastructure, and there are a lot of things that the CSP does for you. And as an enterprise that’s not building a tech product, for you IT is just a cost center that you want to keep as simple as possible.

For tech companies it might be different, because technology for them is a competitive edge. They have a lot of tech talent onboarded. That’s where I think there’s more room for repatriation. If your product is a tech product you probably know how to do it better than the CSP because you can tailor it to your specific needs and it’s probably going to be more efficient and cheaper on-premises, depending on the application of course.

Futuriom: I wanted to ask you about AI and how you see it affecting the multicloud environment in general.

AS: Everybody wants AI today and companies go to the CSP that has the best AI. Everybody wants to have their AI requirements served. If the business comes with AI use cases we need to fulfill those. And if the AI service is available in another cloud region then we have to go there. If the AI services would be available in a different cloud, we would probably go there. So, it’s influencing the deployment of the infrastructure to some extent. But in the operation of the infrastructure, I have not seen too much use of AI as of yet.

Futuriom: This multicloud field seems to demand an incredible amount of expertise. If you were to advise engineers about how to pursue a career like yours, what would you suggest are the necessary requirements?

AS: I think first you have to choose a vertical. I think anybody who says they understand everything in a multicloud environment, like multiple clouds, multiple verticals, they are either geniuses or they are lying. For me, also, I understand the network well, network security pretty well in multiple clouds, but I don’t understand everything else in those clouds. There are blind spots for me as well.

First I would say there is a vertical that you would have to choose to understand best. And then you’ve got to start somewhere, you must pick what’s going to be your main area of expertise. For me, I started from on-premises. I started out as an on-premises network architect and then I grew into the cloud.

So, choose a vertical, choose a main cloud or platform, then grow from there. Choose a strategy and path and try to learn something really well then expand into other areas. That’s my strategy and that’s what I would recommend to others as well.

Futuriom: You mentioned networking. That seems to be the most difficult challenge in any kind of cloud environment but the most important technology to understand in the multicloud environment.

AS: It is but there’s a lot of other technologies that are just as challenging. The cloud is just like any other datacenter—it’s all about networking, storage, and compute. The difference is that most of the cloud architects don’t come from the network, and they don’t come with networking backgrounds. They come mostly from operating on-premises infrastructure. They were server administrators or developers in most cases, and so they know the compute and the storage well, but they don’t necessarily understand the networking piece.

Most of the cloud architects out there don’t have deep networking knowledge, and then the networking in the cloud is also very different from on-premises as well. That’s why I believe it’s a missing skill set. If you interview people for cloud engineer, cloud architect jobs, most people say yeah, I can do anything, except for the network because I don’t like it, I don’t understand it. There are very few people who are willing to move from on-premises network expertise into cloud networking expertise at this point I believe.

Futuriom: Interesting. I’d like to shift gears and ask you about managing vendors. That’s been part of your career. What’s your approach to managing multiple vendors? What are some tips?

AS: There has to be one main vendor. Even if you’re saying we’re multicloud, it’s highly unlikely there’s going to be multiple clouds of the same size, the same importance for the organization. Maybe for the biggest enterprises, but most enterprises have a main cloud and there are one or two "spare clouds," where you go either because you don’t get the same service in your main cloud or you get it significantly cheaper or because of disaster recovery reasons. Those are the main drivers for going to another cloud.

And when we’re talking about pricing, it’s not necessarily going to be a pricing decision either because even if a service is more expensive in your main cloud, just because you’re there big time you’re going to get better discounts.

I believe it’s pretty hard to have a really good relationship and vendor management with multiple CSPs, so I would focus most of my efforts on one vendor and have one or two additional vendors a little bit on the back burner. Make sure your main CSP environment is healthy and your relationship is healthy there and that you have the right focus on your main CSP.

On the second CSP, you still should have some communication, but since your deployment is not as big there it’s highly unlikely that they would also give you huge focus unless they want you to go over to them.

So, what I would say is that unless you’re really really big and you can afford to manage multiple vendors at the same level, it’s just better to focus on one of those and leave the other on the back burner.

Futuriom: How do I decide which vendor will be my main one in a multicloud environment?

AS: There’s a lot of factors. You have to look at your location and their locations. Proximity for sure matters. Then the services you need to run in there, that matters for sure. You need to look at your existing partnerships and contracts because maybe you have something big already with a vendor and you can start from a better position when you’re talking to them, when it comes to the commercial terms.

Then you also have to look at what your people understand, so if you already have some people in the company who did cloud or are doing cloud, you need to know what those people understand best. If you have a third party operating your environment, what do they understand? I think those would probably be the main factors. There are of course a lot of other, smaller factors.

Futuriom: I want to ask you about data sovereignty. I know that’s been an issue geographically. How do you support that if you have to and what are some of your suggestions about the topic?

AS: It's going to be your legal team telling you what data needs to go where. You need to provide an infrastructure for that. For an enterprise that’s global, it’s going to mean that you’re going to have to onboard multiple cloud regions. And when you’re onboarding those regions you have to consider data sovereignty, among many other factors. So, you have to decide where you’re going to put your workloads, and this has to be one of the deciding factors. In general, it’s best if you can limit your cloud usage in a specific geographic area to a limited amount of regions, because using a lot of regions can be fairly expensive with all the basic infrastructure required just to onboard it.

To be fair, so far I haven’t come across data sovereignty as the main deciding factor, at least not in the companies I’ve worked with. But these have been European companies and most of the data is kept within Europe. I think it’s a bigger challenge if you’re a U.S. company and you have data from EU users that you need to store in the EU instead of the U.S.

Some financial institutions, some countries—Germany, for instance—have even stricter laws, so Azure and others are developing specific regions just for this purpose. The EU laws are not necessarily as strict as those in Germany.

Futuriom: A final question: When you look at the tech market in general, what are the main trends you have your eye on?

AS: Of course, AI is something to watch out for, but I think it’s too early to draw conclusions. Everybody is jumping on it now, but I have yet to see some really mature solutions, especially in the network or security areas. There are some trials, but I would say I don’t yet see where it’s going to evolve, but it’s definitely something to watch out for.

In the cloud and networking space, I would say the development of the network-as-a service [NaaS] models, and how that’s going to evolve. Multiple companies are saying they are NaaS vendors now and they have different levels of services. And also, the zero trust network architecture and zero trust in general—that’s something that’s getting more and more mature. It’s been around for many years but it’s still evolving and there’s a lot of development there.

Futuriom: What about the network edge?

AS: I don’t see big changes there these days. Edge is also becoming a service offering instead of you operating it. I see that as a trend. Depending on which vendor you talk to—either the cloud vendor tries to extend their edge to the premises, or your on-premises vendor tries to extend their edge out to the cloud.

If you are mainly an on-premises company, you will likely extend your edge from on-premises into the cloud with an on-premises vendor. If you’re more cloud-native, you might extend your edge from the cloud into on-premises with your cloud vendor.

Futuriom: Thank you Adam.