For far too long, managing employee expenses has been a time-consuming process that requires manual data entry and reconciliation to bridge the gap between business bank accounts and ERP systems. In the absence of an integrated workflow, finance teams use multiple systems to manage credit card and cash payments, and finding receipts. In most cases, they also lack real-time visibility into company spending.

The complexity grows exponentially as businesses expand, especially into new regions. Extra administration required to manage new bank accounts, card issuers, and local accounting systems impedes decision making and negatively impacts revenues and growth. Businesses of all sizes struggle with this, but it can be especially challenging for medium to large enterprises.

Payhawk set out to help businesses overcome these challenges when we founded the company in 2018. We combine VISA company cards, reimbursable expenses, and accounts payable into a single product. Our customers can automate manual processes, maximize efficiency, and accelerate business expansion.

Setting up our first cloud cluster in less than a week

To support growth and attract investment we were keen to launch our solution on a scalable, future-proof IT architecture that didn’t require extensive technical support. This is where Google Cloud made a big impression, especially the user interface and documentation which massively reduces the resources required to set up clusters and put them into production.

I’m a CTO, not a DevOps specialist, but in less than a week I was able to set up a secure, reliable operating infrastructure. This enabled us to fast-track our application development and we were able to issue our first card in just eight months. Our Google Cloud partner, Cloud Office also gave us valuable assistance, guiding us through the deployment process and advising on Google Cloud’s extensive range of solutions.

Google Kubernetes Engine (GKE) played a critical role, accelerating the deployment and management of our cloud native applications. We use Cloud SQL as our database while other important tools include Cloud Memorystore, Vision AI, Cloud Storage and Artifact Registry for our wider data storage and application needs. With Firebase we’ve been able to build a notification system for mobile devices.

Another incentive is that most other cloud solutions require add-on services to build and keep your product live. With Google Cloud, all the services that Payhawk needs including logging, metrics, monitoring of resources, and utilization of CPU memory come as standard.

For instance, I was really impressed by Google Cloud’s operations suite, which includes Cloud Logging and Cloud Monitoring. If there are any anomalies in our cloud architecture, we can track and resolve them with minimal disruption to our operations. This also removes the need to invest in an additional observability solution.

Reliability that builds customer trust

Google Cloud also supports Payhawk’s mission to put customers at the center of our organization. Thanks to Google Cloud error reporting and tracking and Google Cloud single sign on, Payhawk’s engineering team can anticipate customer issues and correct them in less than one hour. Trust is everything, and Google Cloud gives us the tools to boost customer satisfaction and build long-term relationships.

As a young business, managing costs is also a priority. The Google for Startups Cloud Program, which includes credits for Google software and tools, enabled us to push the business forward without having to worry about financing our infrastructure, especially in the first year. This gave us breathing room to work through funding, application development, and the onboarding of our first customers.

In addition, Google Cloud gives us confidence that we can grow the business fast. In most months we have seen more than 10% growth — in some cases it’s been 20%. In the first half of 2022, the business doubled in size, but Google Cloud gave us the flexibility to scale our infrastructure, adding storage, memory, and processing power as we onboarded new customers. The pricing model is also generous so that we can grow our revenues while keeping control of operational expenditure.

Since launch we have acquired a valuable mix of customers from startups to large businesses that want to reduce the costs of their expenses programs and increase employee satisfaction. They include ATU, a German automobile servicing company, which has successfully digitized its entire procurement process, and Discordia, a Bulgarian logistics business with 10,000 trucks, which has issued Payhawk cards to all its drivers.

Looking to the future, it’s no exaggeration to say that Google Cloud is a foundation of our business and has given investors confidence in our operations. From a first seeding round of €3 million, early this year we closed a Series B extension of $100 million. This gives us a valuation of $1bn and makes Payhawk the first ever Bulgarian unicorn.

We now operate in 32 countries in Europe and the US, and plan to double our team by the end of the year. It feels like we’ve come a long way since we first started using Google Cloud, and I’m thrilled that we have Google Cloud as a global technology partner supporting our mission to transform expense management and financial operations worldwide.

If you want to learn more about how Google Cloud can help your startup, visit our page here to get more information about our program, and sign up for our communications to get a look at our community activities, digital events, special offers, and more.

There’s never been a better time to talk about multicloud, and the Google Cloud Multicloud Mindset series on Twitter Spaces was created to do just that! This series takes place once every two weeks and features live conversations with top experts about the latest multicloud topics. You can join the 15-minute Q&A to ask your top questions and listen to episodes later offline for up to 30 days after we chat.

If you happened to miss our last few episodes, we recommend checking out our introduction blog to the series for what you missed. Let’s dive into our latest episodes, discussing the impact of open source and novel security challenges in multicloud environments.

Episode #5: ‘The intersection of open source and multicloud’

Open source technology has been an integral part of computing since its earliest era, predating even the birth of technology hubs like Silicon Valley. Open source projects have been responsible for giving us some of the most popular software in the world, such as Mozilla Firefox and the operating system Linux.

In the fifth episode, we sat down with Mike Coleman, Cloud Developer Advocate at Google Cloud, and took a closer look into the history of open source technologies, the role they play in a multicloud world, and the developer perspective on using these technologies to do their work.

The concept of multicloud anchors on the ability to run workloads across clouds and being able to pick the providers that are best suited for specific parts of workloads. Adopting open source technologies and languages empower companies to use the tools they need, regardless of cloud provider, without the fear of getting locked into a specific provider.

“As you think about moving across different environments, whether that be cloud to cloud, or developer desktop to ultimate destination, whether that be your data center or the cloud. Open source software allows you to do that…and multicloud is just an extension of that. This idea that I need to run the same software wherever I go.” — Mike Coleman, Cloud Developer Advocate at Google Cloud

If you’ve ever wanted a developer’s take on the impact of multicloud and the influence of open source in software development and digital transformation trends, you’ll want to tune into this episode.

You can access the full conversation on Twitter Spaces.

Episode #6: ‘Novel challenges in security with multicloud’

In the sixth episode of the series, we chatted with Dr. Anton Chuvakin, Security Advisor at Office of the CISO at Google Cloud, about how security leaders and architects are shifting away from traditional security models, which are increasingly insufficient for multicloud environments.

As more organizations adopt multicloud approaches, the question of how to maintain security in these complex environments and the increasing burden on SecOps teams is top of mind. As Dr. Chuvakin noted, the challenges in the cloud facing more traditional teams range from types of telemetry and logs to volumes and lack of clarity on detection use cases. However, these issues intensify when extended to include multiple clouds, where learning how to do something on one provider may be completely different on another.

“If you end up multicloud, you need to know public cloud and how it works at a better level than you would if you’re going to a single provider. Just like if you’re trying to repair three cars, you need to first learn how to repair cars. You need to have more cloud knowledge to do multicloud, not less. You need to have more powerful superpowers in the public cloud computing area because you can’t just learn one provider and call it a day.” — Dr. Anton Chuvakin, Security Advisor at Office of the CISO at Google Cloud

During the discussion, he offered three tips for tackling multicloud security:

1. Learn cloud more, not less if you’re going multicloud. Multicloud requires more cloud knowledge because you can’t learn a single provider and call it a day. You’ll need to understand the differences in order to be able to secure multiple cloud environments.
2. Focus on learning cloud identity management and how it compares to your traditional identity management service functions. Start with identifying the differences and similarities in what you see in one cloud and then continue with other clouds you use.
3. Explore where your threat areas change in cloud environments when you plan detection and response activities to understand if your detection is covered across clouds.

If your organization is embracing multicloud, this is a great episode to listen and learn more about cloud security, the primary considerations and challenges facing security teams, and some helpful best practices for thinking about security in multicloud environments.

We’ll be sharing the latest topics and episodes with you every month in this blog series. Until next time.

Communication services providers (CSPs) are experiencing a period of disruption. Overall revenue growth is decelerating and is projected to remain below 1 percent per year, following a trend that started even before the pandemic.¹ At the same time, driven by the pandemic, data consumption in 2020 increased by 30 percent relative to 2019, with some operators even reporting increases of 60 percent.² 

The combination of pressure on revenues with rising data traffic costs is forcing operators to innovate in three fundamental ways. First, operators are looking to establish new sources of revenue. Second, increased network utilization must be met with a reduction in network cost. And third, there is an opportunity to gain new customers by improving the customer experience.

Fortunately, 5G offers a path forward across each of these three areas. Concepts such as network slicing and private networks allow CSPs to offer differentiated network services to public sector and enterprise customers. The disaggregation of hardware and software allows new vendors with unique strengths to enter the market and to enable CSPs to build, deploy, and operate networks in fundamentally new ways. And the ability to place workloads at the edge permits CSPs to offer compelling experiences to consumers and businesses alike. In this blog, we will discuss how CSPs can create a solid foundation for their cloud networks. 

Understanding telecommunications networks

First, it is useful to consider the way telecommunications networks were traditionally built. Initially, networks were built using physical network functions (PNFs) — appliances that used a tight combination of hardware and software to perform a specific function. PNFs offered the benefit of being purpose-built for a specific application, but they were inflexible and difficult to upgrade. As an example, deploying new features frequently required replacing the entire PNF, i.e., deploying a new hardware appliance.

The first step in improving deployment agility came with the concept of virtualized network functions (VNFs), software workloads designed to operate on commercial off-the-shelf (COTS) hardware. Rather than utilizing an integrated hardware and software appliance, VNFs disaggregated the hardware from the software. As such, it became possible to procure the hardware from one vendor and the software from another. It also became possible to separate the hardware and software upgrade cycles. 

However, while VNFs offered advantages over PNFs, VNFs were still an intermediate step. First, they typically needed to be run within a virtual machine (VM), and as such required a hypervisor to interface between the host operating system (OS) and the guest OS inside the VM. The hypervisor consumed CPU cycles and added inefficiency. Second, the VNF itself was frequently designed as a monolithic function. This meant that while it was possible to upgrade the VNF separately from the hardware, such an upgrade, even for a feature that affected only a portion of the VNF, required deployment of the entire large VNF. This created risk and operational complexity, which in turn meant that upgrades were delayed just as they were with PNFs.

Creating the foundation for cloud networks

The trick to establishing your cloud based network resides in the challenge of moving from VNFs to containerized network functions (CNFs) — network functions organized as containers as a collection of small programs, each of which can be independently operated. 

The concept of containers is not new. In fact, Google has been using containerized workloads for over 15 years. Kubernetes, which Google developed and open-sourced, is the world’s most popular container orchestration system, and is based on Borg, Google’s internal container management system.³ There are lots of benefits to using containers, but fundamentally, it frees developers from worrying about resource scheduling, interprocess communication, security, self-healing, load balancing, and many other tedious (but important!) tasks. 

Consider just a couple examples of benefits that containerization brings to network functions. First, when upgrading the network function to implement new features, you no longer need to re-deploy the entire network function. Instead, you only need to re-deploy the containers that are affected by the upgrade. This improves developer velocity and reduces the risk of the upgrade because, rather than infrequent upgrades that each introduce substantial changes, you can now have frequent upgrades that each deploy small changes. Small changes are less risky because they are easier to understand and to roll back in case of anomaly. Incidentally, this also improves your security posture because it reduces the time between when a security vulnerability is discovered and when a patch is deployed.

Speaking of security, another example of the benefits that containerization brings to network functions is an automatic zero-trust security posture. In Kubernetes, the communication among microservices can be handled by a service mesh, which manages mundane aspects of inter-services communication such as retries in case of failure and providing observability into communication. It can also manage other essential aspects such as security. For example, Anthos Service Mesh, which is a fully-managed implementation of the open-source Istio service mesh (also co-developed by Google), includes the ability to authenticate and encrypt all communications using mutual TLS (mTLS) and to deploy fine-grained access control for each individual microservice.

Automation and orchestration for cloud networks

CNFs bring tremendous benefits, but they also bring challenges. In place of a relatively small number of network appliances, we now have a large number of containers, each of which requires configuration, management, and maintenance. In the past, many of these processes were accomplished using manual techniques, but this is impossible to accomplish economically and reliably at the scale required by CNFs.

Fortunately, there are cloud-native approaches to solving these challenges. First, consider the problem of autonomously deploying and maintaining CNFs. The ideal way is to use the concept of Configuration as Data. Unlike imperative techniques such as Infrastructure as Code, which provide a detailed description of a sequence of steps that need to be executed to achieve an objective, Configuration as Data is a declarative method whereby the user specifies the desired end state (i.e., the actual desired configuration) and relies on automated controllers to continuously drive the infrastructure to achieve that state. Kubernetes includes such automated controllers, and the great news is that this method can be used not just for infrastructure but also for the applications residing on top of it, including CNFs. This cloud-native technique frees you from the toil and associated risk of writing detailed configuration procedures, so you can focus on the business logic of your applications.

As another example, consider the problem of understanding your network performance, including anomaly detection, root cause analysis, and resolution. The cloud-native approach starts with creating a data platform where both infrastructure and CNF monitoring data can be ingested, regularized, processed, and stored. You can then correlate data sets against each other to detect anomalies, and with AI/ML techniques, you can even anticipate anomalies before they happen. AI/ML is likewise indispensable in gaining an understanding of why the anomaly is happening, i.e. performing root cause analysis, and automated closed-loop controllers can be developed to correct the problem, ideally before it even happens.

Architecting for the edge

The transition from VNFs to CNFs is a critical piece in addressing the challenge that CSPs face today, but it alone is not enough. CNFs need infrastructure to run on, and not all infrastructure is created equal. 

Consider a typical 5G network. There are some functions, such as those associated with an access network, that need to be deployed at the edge. These functions require low latency, high throughput, or even a combination of the two. In 5G networks, examples of such functions include the radio unit (RU), distributed unit (DU), centralized unit (CU), and the user plane function (UPF). The first three are components of the radio access network (RAN), while the last is a component of the 5G core. At the same time, there are some other control plane functions such as the session management function (SMF) or the authentication and mobility management function (AMF) that do not have such tight latency and high throughput requirements and can thus be placed in a more centralized data center. Furthermore, consider an AI/ML use case where a particular model (perhaps for radio traffic steering) needs to run at the network edge because of its latency requirements. While the model itself needs to run at the edge, model training (i.e., generating the model coefficients) is frequently a compute-intensive exercise that is latency-insensitive and is thus more optimal to run in a public cloud region.

All of these use cases have one thing in common: they call for a hybrid deployment environment. Some applications must be deployed at the edge as close to the user as possible. Others can be deployed in a more centralized environment. Still others can be deployed in a public cloud region to take advantage of the large amount of compute and economies of scale available therein. Wouldn’t it be convenient — if not transformational — if you could use a single environment for deploying at the edge, in a private datacenter, and in public cloud, with a consistent set of security, lifecycle management, policy, and orchestration resources across all such locations? This is indeed what Google Distributed Cloud, enabled by Anthos, brings to the table.

With Google Distributed Cloud, you can architect a 5G network deployment such as the one shown below.

Business benefits of cloud networks

Beyond the technical benefits, consider the business benefits of such an architecture. First, by following the best practices of hardware and software disaggregation, it permits the CSP to procure the infrastructure and the network functions from different vendors, spurring competition among vendors. Second, each workload is placed in precisely the right location, enabling efficient utilization of hardware resources and offering compelling low-latency, high-throughput services to users. Third, because the architecture utilizes a common hybrid platform (Anthos), it makes it easy to move workloads across infrastructure locations. Fourth, the separation of workloads into microservices accelerates time-to-market when developing new features or applications, such as those enabling enterprise use cases. And finally, the container management platform supports the simultaneous deployment of both network functions and edge applications on the same infrastructure, allowing the operator to deploy new experiences such as AR/VR directly on bare metal as close to the user as possible.

The next generation cloud network is now

There is a lot more we could say, but perhaps the most important takeaway is that this architecture is not a future dream. It exists today, and Google is working with leading CSPs and network vendor partners to deploy it, helping them realize the promise of 5G to deliver new revenues, reduce operating costs, and enable new customer experiences.

To learn more, watch the video series on the cloudification of CSP networks.

Discover what’s happening at the edge: How CSPs Can Innovate at the Edge.

^{1.Statista, Forecast growth worldwide telecom services spending from 2019 to 2024
2 PricewaterhouseCoopers, Global entertainment and media outlook 2021-2025
3. Borg: The Predecessor to Kubernetes}