Fierce's Cloud 101 Q&A series goes back to basics, aiming to help readers build in-depth knowledge about key cloud concepts and the overall market through progressive interviews with industry experts.
This week's interview features Amol Phadke, managing director for Global Telecom Solutions at Google Cloud. The interview transcript has been edited for length and clarity.
Fierce Telecom: Where does the idea of the cloud have its roots?
Amol Phadke: If you think about how enterprises globally used to manage their infrastructure and their IT systems, it was essentially every single company in the world having their own data centers. It became quickly evident that these enterprises, each of them, not only had to buy their own infrastructure, but it was not core to their business. So, that became a huge cost drain on enterprises worldwide. They started to understand it's not just a one-off cost, it's the maintenance costs, it's the operational costs, it's the keeping an IT team in your company.
There were several cloud computing companies, including Google Cloud, who sort of started looking at this and said, how about we build the same infrastructure, but at planet-wide scale so that enterprises don't have to buy computers and IT infrastructure for themselves, they could simply lease that infrastructure.
So, the origins of cloud really is around economies of scale, and the cost attractiveness of having leased storage, compute and networking infrastructure in a secure way from a very large organization or a cloud company that does this as their core business. That also drives a lot of advantages because if it's my core business, I would ensure that it's state of the art.
FT: What exactly is the ‘cloud’ made up of?
AP: Essential components are always three – storage, compute and networking – for any cloud infrastructure to scale, and that’s repeated over and over again to create essentially the whole data center.
Google Cloud Data Centers, for instance…have racks and racks of storage, compute infrastructure as well as networking, which means cables, servers, hard disks. Of course, they also need the basic capabilities such as power and cooling and so on, as well as security, isolation. Several other capabilities are deployed at the data center, in Google Cloud’s case, to really offer all of the applications that that enterprises need.
RELATED: Google Cloud notches another telco win with Canada's Telus
Various connectivity options are available. So, for instance, if you look at the Google Cloud connectivity options that we have provided…basically what we are trying to do is offer a wide range of connectivity options to enterprises trying to get to cloud. On the left-hand side of the spectrum is internet access, and on the right-hand side is direct fiber interconnects into cloud. Obviously, the type of connection that you buy gives you the right level of service but also has the right cost, the right security posture, and so on and so forth. The other very important point to understand is we also partner with CSPs or telecom operators worldwide, because in some cases, you would actually use the telecom operator’s infrastructure to get to the cloud.
FT: What types of cloud architecture are there? How is cloud architecture different from traditional telco network architecture?
AP: If you look at Google Cloud's footprint...we have 25 regions globally. These are massive data centers in critical locations around the world, and we serve as many clients as we can to those locations. In some cases, that is not enough for a client, so in that case what happens is…we would have certain facilities that we call our edge locations where a subset of the infrastructure is available for our clients to consume, but it is much closer to the client. So whereas there’s 25 regions, there is probably close to 200 edge locations that Google has as the boundary of our network.
Then we have the next level of distribution which is what we call edge cloud, and here we have almost 3,000 locations worldwide that actually are not in Google facilities. They are in either an operator facility, or they are in some other facility. But the key point there being that those locations are also used to store some of the cloud infrastructure, most notably caching and storage services needed for traffic such as video downloads that enterprises or consumers may want to access.
This is very complementary to how telecom infrastructure is built. If you're in North America, you would have the telecom operators in North America that would build deep in-country networks. Cloud providers typically have global, broad networks. So, they partner with operators to get the depth needed to get to the enterprises or the consumers, which is why I said the infrastructures are quite complimentary. So, in the telecom operator’s case, their core network sits inside a country, their access network sits inside the country, and their last mile distribution connects homes and enterprise buildings to their core network, and then from their core network there is a handoff to cloud networks.
FT: From a telco perspective, what types of tasks are best suited to the cloud? Is there anything that shouldn’t be put in the cloud?
AP: I think the selection of the types of applications that can sit on the cloud is really a very broad conversation, because there's a number of elements involved. There is security, which is a very important dimension, but then there's also privacy requirements that operators have always complied with for specific geographies or countries.
There aren't really applications that cannot run on cloud, because at the end of the day, applications need compute, storage and networking capabilities, and what you can do inside your enterprise can be done in the cloud. It's more about what are the commercial reasons or business model reasons or privacy, regulatory reasons, which is why certain applications may migrate to cloud later and certain applications may move to the cloud much sooner.
So, it's more about timing. The only exception is if you have very high-speed, transactional-type applications where you really want security, privacy, and on top of that, you need applications that really run in the core of your infrastructure. It might actually not be prudent to move those to cloud because the migration itself will take so much cost that it may not be worth the benefit that you would get.
FT: How does the development process for cloud applications work? How long does it usually take?
AP: Application development in a cloud environment is not really a finite thing in the sense that we have this concept called CI-CD, continuous integration, continuous development. What that really means is an application is constantly being built by its developer community, to make it better and better and add more and more features. So, it's not really ‘oh, this application was started building at X date and finished building at Y date, and we're not going to touch it again.’
Having said that, the cycles of development get shorter and shorter as you move applications to the cloud because you can publish them instantly and test them instantly and review their performance instantly. So, we are moving toward a continuous methodology of development…and we have the concept of having agile pace, which means every three weeks or every six weeks, you will have a deployment happening in the cloud, whereas previously it used to take weeks or months.
FT: What is currently the biggest barrier to cloud adoption? What can be done to help overcome this?
AP: I think as more and more clients started adopting Google Cloud and cloud paradigm to move their applications, there were some perceived barriers, initially, such as how secure is it, how resilient is it, how much control would I get on the applications, how much data protection do I get.
Those barriers have largely disappeared. One barrier still remains which is culture, fear of the unknown, a mindset change. Obviously, you're used to running applications in your own environment where you had this sort of control on that. So, that will still take some time to change, and that's more of a culture shift, as opposed to any technological reason.