In this podcast, Google Cloud Customer Engineer, Karim Atek demonstrates the fundamentals of Google Cloud Platform and Application Modernization.
Listen to this podcast to hear insights on:
Speaker 1: On behalf of Google Cloud and Carahsoft, we would like to welcome you to today's podcast focused around Securely Modernizing Your Workloads with Karim Atek, customer engineer at Google Cloud. We'll discuss the fundamentals of the Google Cloud Platform and application modernization.
Karim Atek: Hello, everyone. So, I am a customer engineer, which means in our world solution architect on the Google Cloud side. I support public sector customers. My focus area is in the Midwest, but I deal with public sector entities, East of the Mississippi, right? So, that's the customers that I've been working with and the prospects that I've been working with as well. So, without further ado, I'll dive right in. So, from a high level, we're going to talk about VM migration, potentially moving your VMs to the cloud. Does it make sense from a financial perspective? What's the overview of VMs in the cloud? How does it look there? Pivoting over to a more specific feature is app modernization, right? VMs are good in one aspect, but hey, maybe you're modernizing a number of different applications.
App modernization is an approach to piecemeal those applications and also move it into the cloud. The third topic we're going to be getting into is BigQuery, which is Google's point of view on data analytics and warehousing. The fourth topic is AI and ML. So, how Google has built these industry wide solutions and how we've taken everything that we built for the consumer world, Google Assistant, all the cool stuff that you see with Google, Google Photos, Natural Language, Translation, all that stuff, and how we've productized it to the enterprise and how we've productized that as well in the commercial space.
And then the last thing and this is unique to Google is the public sector subscription agreement, which is a financial agreement. It's a hybrid of an OPEX-CAPEX model that can help fulfill whatever your needs are from a budgetary perspective, because the public sector looks at using cloud services, a lot of times they're just hesitant, because of the fact that it is consumption based, but we address this specifically with the public sector subscription agreement. So, Google Cloud is we deem it to be the best partner for your journey. It's a linear journey, right?
We can join you in any part of that journey, whether it's new workloads, building cloud native applications on our cloud, whether it's moving, so moving on-prem applications or on-prem VMs to our cloud or whether it's entirely a digital transformation. So, how can we approach the current systems that we have on-premise, the current systems that we may have in general, maybe the tail end of some legacy systems that we've procured years ago? How can we take a holistic view at this and modernize it? So, Google Cloud solves for you the migration from on-premise to the cloud. The first topic we're getting into is actually moving those VMs into the cloud, right?
So, Google, inherently is a cloud company. It's been a cloud company for almost 16 years. It's confusing, because people are like, "Hey, Google hasn't been in the space, offering cloud services for the last six years," but the reality is we've had to build our solutions to meet scale. The way we've done that is with cloud readiness in mind. So, we've only exposed commercially all the innovation that we built around 7, 8 years ago, but we've been doing this for the last 15, 16 years. And then we approach the stack holistically, right?
So, from a software perspective, the top of the stack, from the networking and operations all the way to the hardware and software, we manage all of that ourselves, right? So, you may or may not know, Google is one of the largest server manufacturers in the world. We don't sell any of that, right? That's server manufacturing for us. We build it specific for us. We build the chips specific for us. So, that we're able to control the whole stack from the bottom up.
So, how do we approach what legacy IT is, right? From a high level, it is difficult to maintain. Frankly, it may be easier from an operational standpoint to continue to pay a legacy vendor millions of dollars than potentially make the move over to a cloud solution, because there may be some security fears. There may be some compliance fears. Can what we do in the cloud imitate or even be improved process to what we have on-premise? Those are the topics that we hear a lot whenever we do have discussions with the public sector side.
But what are the components that makes sense for a government entity to move some of its services or all the services to cloud, right? So, this is just from a high level, lowering costs. Chances are there's no possible way that you'll be able to run a VM network or anything as efficiently as Google runs it. Now, if you look at cloud storage costs, that storage costs are probably the most affordable thing and they're continuously getting more affordable. Buying like a SAN or NAS on-premise is now becoming a very large financial investment when compared to something on the cloud. Pennies on the dollar, frankly.
The reduction in maintenance and management, whenever we do roll out VMs in our cloud, what we want you to focus on is you do the development. We will manage the instances. We will manage the patches, the updates. You don't have to worry. Your organization doesn't have to worry about the nuances of the next update of Microsoft Windows Server, so on and so forth. We're doing those automatic patching stuff for you as well.
Increase agility, once you move those applications to the cloud, you open up a whole gamut of different services that are available to you. I got to have a poster board looking at all the Google services. It has over 150 services, whether they're managed services or serverless services that you'd be able to take advantage of once those applications are actually moved to cloud.
Improving security, we'll walk through that as well. Easier means to innovate, right? So, if you already have something existing in the cloud, it's easier to pivot it and be like, "Hey, we're going to have a bunch of data in one of these components, one of these managed services. Can we run a machine learning model to predict forecasting for staffing for next year, so on and so forth?" And then faster access to newer technology, keeping up the cutting edge.
There's also a lot of reasons on-premise to move to the cloud, right? Capacity demand, I mean, we saw this in COVID all over the place, right? States came to us. They're like, "Hey, our systems are inundated. Our mainframes are inundated with a number of requests," whether it's the Department of Labor, any system that was adversely affected. I'd probably go as far as saying most systems were adversely affected by COVID. So, meeting those capacity needs.
Licensing and support, right? Are you double paying? Do you have active-active servers? Are you double paying for that? Is that something that we would need to set up if we have a high availability plan? Innovation as a whole, being able to rationalize costs. What are your hardware refresh cycles? Does it make sense to have a three- or five-year hardware refresh cycle on-premise? How does that compare to the costs of the cloud?
Contracts, I'll get more into this later, but we just had a very large city in the US move entirely to Google Cloud, because of the fact that they had a contract that was ending with a Colo, right? They were actually leasing the entire Colo facility. Their lease was coming to an end. So, they're like, "Hey, does it make sense for us to look at other options?" It did. They ended up moving to the cloud.
Refresh cycles, acquisitions and compliance and security, this is what we want to eliminate. I don't think I've met one IT staff that doesn't say that they're strained or they're overprovisioned. We're helping alleviate the requests that IT has. We're here to make your job a little bit easier, right? I know how difficult it is now especially. So, if we can do anything to make that role easier, we're at your beck and call.
And then how do we make that migration easy? So, we have a number of different tools to do so, right? So, we have free discovery, the assessment tools, depending on which hypervisor you're using. We'll suggest something for discovery. What this discovery application does is we would install it. It would look at your on-premise resources, see what's over utilized or underutilized, and then give you an apples-to-apples comparison of what it would cost to run on our cloud.
Migration tools, right? Once we've set the foundation of what VMs you have, it doesn't make sense to move to the cloud, we have migration tools that automate that process to push those workloads into the cloud. Also, cost reduction and management. Cost efficiency, how does cost efficiency look like? I don't necessarily like to get too deep into it, but from a cost perspective in general, who is the most affordable cloud in the market today regardless of the size of the workload, right? So, small, medium, large, x-large. I won't dive too deep into the slide.
This is an actual report that was pulled for a customer. So, this was for 617 VMs. So, we gave them the one-year cost, the three-year cost. I mean, the biggest thing that you see here in this chart is cost of storage on-premise and how it converts into storage on GCP, right? It goes from this large blob into the thin line. It continues, right? The more and more you go, the more and more you're adding storage, you can see here, it continues to be a small line.
Compute is competitive. For the most part, we still are cheaper, but storage is really where you save a ton of money. We have migration expertise, right? So, we've been migrating workloads for the last seven, eight years. We've done this with thousands of customers. Whenever we do these processes to empower the customer, we don't necessarily want to put the customer in a black box, have everything done and be like, "Here's the keys."
We want you to be engaged in the process. We want you to be able to look over our shoulder as we're developing these things, as we're migrating. We will be doing the hand holding with you as well and running enablement sessions after to be like, "Hey, how can you best utilize these tools? How can you take advantage of what you have? How can I make my staff comfortable with Google's tools?" This is stuff that we all offer as a part of our migration plan.
So, pivoting over from VM migration, I'm going to get into application modernization, right? This is a more specific field to legacy systems, right? So, legacy systems in general hinder business agility. I won't read the slide, but this is relevant to, I would say, probably every public sector organization today. So, if you have a legacy system today, don't feel bad. You're not unique. Every public sector entity has that.
So, the technical debt that we're assuming by 2025... It's funny. When I would look at 2025, I would be like, "Wow, that's so far away." It's actually four years away at this point, right? Based on our estimates and based on Gartner's estimate, it's going to be around 40% of the current IT budget, which is a legacy system that you're just paying maintenance on. You have to keep up because it's running some critical application, whether or not it's built on COBOL or Fortran or anything, but we need to have it up because it is mission critical.
So, what is application modernization? How does Google approach that topic? So, we do it in four different ways. We do application architecture, right? This is the previous way that code was written in the past. It was written in a monolithic way, right? Thousands, ten thousands, tens of thousands, hundreds of thousands of lines. There was no real good way whenever you would be able to isolate a problem or change up the code.
How to ensure that it doesn't break the entire code? How do you isolate? Whenever you're debugging code, how are you isolating appropriately those changes? How are those changes being done from a developer's perspective, right? We see that more in the microservices world, right? Breaking up that monolithic application into individual microservices that your staff can develop on individually and isolate whenever a problem comes up.
Infrastructure abstraction, we don't want you to worry about going on site and pulling out an SSD or putting in new RAM or new storage into your on-premise servers. We want you to prioritize your time to not maintaining the systems but innovating the current systems that you have. Faster software delivery, a lot of people have moved on to the Agile world, but we still, for the most part, see a lot of waterfall approaches when it comes to software delivery.
And then Google is so confident in its services that it's made a lot of it public. So, when you're actually building an application on Google, you're not vendor locked in, right? The way we approach it is hey, we ensure that Google has such a good customer service and pleasant experience when using our tools, SLAs or certifications. But at the same time, we want to build it on open source things, right? Whether or not this is Google that's actually made it open source because a lot of the tools that you may be using today were open source in the last 15 years by Google, we want to ensure that in the case that you would want to move to a different cloud vendor, you're not locked into our solutions. That should be the approach in general, not building on proprietary legacy solutions.
So, what are two things we want to achieve, right? Migration, being able to move and modernizing being able to improve, right? Move and improve. So, what's our point of view on modernization? I mean, I can't lie. Google maybe 17, 18 years ago was built on more of a monolithic approach. Obviously, it can't scale up when you're a company like Google. So, we've pivoted at that time towards microservices, towards an architecture that's not built on one monolithic application, right? That's the way that we've perceived the market and we've kind of influenced the market to getting into, right?
Kubernetes, something that was internal to Google, it was called Borg. We've externalized it to the market as something called Kubernetes. So, when you're developing containers and orchestrating it with Kubernetes, Google actually made that public. But at the same time, if you're developing that way, you can actually take it to any number of cloud services. It ports very cleanly to any of those services. So, if you're running Kubernetes on another cloud vendor, there should be no issue.
So, what are some of the principles that come with modernization, right? The applications that we want to move initially have to have the least amount of risk and least amount of impact, right? So, stuff that you may have ancillary, we're not saying, "Flip your critical ERP systems tomorrow to Google." We want to develop a strategy with you. We want to develop a plan with you.
And then we can start targeting low hanging fruit that you have that you're like, "You know what? There's not a lot of traffic on this. We pay a bunch to keep the service alive. Would it make sense for us to modernize this application?" And then you work up, right? So, once you are comfortable with that base, you then work yourself up to moving the most impactful application and then performing the riskiest changes towards the very end.
So, what are some of the challenges for modernizing legacy applications? This is some of the things that we've heard as well in the public sector space. Rewrite is not a viable option for a lot of workloads. That's true. A lot of times, it's actually been written by Jerry retired 50 years ago. It's going to be hard to rewrite this application that was written in COBOL to something like in JavaScript. We understand that. We understand that it is a concern.
The second is... This is maybe even potentially contradicting what I was saying before. ... why not just move our VMs to the cloud? Moving your VMs to the cloud is a good landing point initially. But if you want to get the cost savings, if you want to take advantage of scalability, the resiliency and security of cloud, even if you do migrate your VMs to the cloud, you need to have in mind, "How can I convert these VMs into microservice application?"
And then the last thing is it's not a binary problem, right? We don't see it as a binary problem. There isn't just a yes/no solution to it. We have to approach your entire workload and your entire process flow holistically.
So, what's the answer for these questions? Google Cloud has been doing this for years. The partners that we work with have been doing it for years, decades. So, we're at your beck and call to help develop systems that make sense for you. So, what do those cost savings look like with something like Anthos. Anthos is a single pane of glass to run Kubernetes containerized workloads from any cloud service, right? So, you can migrate the application as is. So, you lift and shift. This is overall what it looks like from a cost savings perspective. You can look at saving around 37% doing that, but you get the true cost savings when you start refactoring and replatforming.
We've done this before in different state agencies. I personally have worked, right? So, we're doing this in a couple of Midwest states. I will say that they're not publicly referenceable yet, some Southern states as well that I've worked with where we took the Hadoop stack that cost the customer around $1 million a year to run. We entirely replatformed that in our cloud. It is currently running at around $120,000 a year. So, it was more than 90% cost savings in that perspective.
Hadoop, if you guys aren't doing big data, that's not a problem. But at the end of the day, running services on Google Cloud is much more affordable, much more scalable. The customer came to us in mind with, "We want to innovate. We don't want to necessarily just lift and shift." If they lifted and shifted their stack to our cloud, it would be around $300K, right? So, they were going from $1 million on-premise to pay $300K on Google Cloud, but they're like, "Hey, we want to skip that migration path. What we want to do is we want to modernize as we migrate." That may or may not be the best option for you, but that's what they chose, right? So, they modernized and migrated. We're able to have cost savings around 90%.
So, I'm going to pivot over to data analytics and close off the topic of application modernization. So, I'm going to pivot over to BigQuery Omni, right? So, BigQuery Omni is a new solution that we've released that's come to the market. It's our perspective on how data analytics is done, right? So, from a high level, it's a very flexible, multi-cloud analytics solution.
What we find is some of public sector customers are like, "Hey, we have a lot of services already in other clouds. How can we take advantage of our OLTP or OLAP databases that we have on other clouds? Maybe we have some stuff booked up in AWS, Athena. We have some stuff in Microsoft SQL, Azure. How can we take advantage of those things that we already had? Does it make sense for us to migrate everything?" It can, but then at the same time, we've developed BigQuery Omni to be an overlay on top of those services to be able to run it in a very easy to use accessible way with SQL.
We even have something new called BigQuery Q&A, which allows you to ask BigQuery natural language questions like, "What was the net revenue of this system from this date to this date?" You can ask a natural language question like that. It will convert that into an actual SQL query and return the results in any format you would like to see. So, if you'd like to visualize in BigQuery, you can. If you want to push it over to Tableau, you can. So, it just depends on what you would like. Looker, that's our solution around data visualization.
So, what is BigQuery though? So, we talked about BigQuery Omni, which is the higher level abstraction of being able to run queries across any data analytic system. More specifically, what is BigQuery though? BigQuery is how Google perceives data warehousing, right? So, it's our enterprise data warehouse for analytics. It was built primarily to run queries across internet-sized problems, right?
So, BigQuery has actually been working at Google for almost the last 13 years. This isn't necessarily a new product. We've externalized the innovation in the last six, seven years with a solution called BigQuery, because we at Google had to be like, "Hey, how can we search across billions of results or in some cases, trillions of results and be able to return something in an equitable, very fast, very efficient manner?" The solution to that problem was developing BigQuery, encrypted, durable, highly available.
And then these are some of the things that are unique about it. You don't have to manage any infrastructure. The cost model for this is you pay for storage, and you pay for the queries you run. You don't pay for any compute. The only compute that you pay is when you run a specific query, right? So, it's entirely serverless. So, when we say serverless, it means that you don't have to manage an actual VM. You don't have to manage networking configured with that. All you have to manage is, "What does my data schema look like in BigQuery? What are the queries that I want to run? How can I more efficiently run my queries?"
We're getting real time insights from streaming data. It is a streaming data person's paradise when it comes to these things, being able to run hundreds of thousands of rows per second into BigQuery and being able to visualize it, run queries on it within a matter of seconds. We got built-in machine learning out of the box. In the same interface that you're running your SQL queries, you can also build machine learning models, right? You can run, "Hey, I have this data set. I'd like to run a linear regression model on this." You add two extra lines of code. You create a linear regression model based on that data set that you have. Also, high speed in-memory BI engine for faster reporting in and out.
BigQuery is only one portion of how we perceive the whole data analytics world, right? So, we have everything from capturing the processing, storing, analyzing, which is here at BigQuery. Then lastly is using, right? How would you like to visualize it? You want to visualize it on a BI tool like Looker. You want to use something more user interface like Google Sheets, so on and so forth.
And then this is how Google perceives how a data warehouse should be done. This is typically where a lot of our customers are today. They're focusing a lot of their time on all these ancillary components like monitoring, performance tuning, utilization, deployment and configuration, reliability, handling growing scale, resource provisioning. They spend only a limited portion of time on actually doing analysis on the data, right? So, if you have a DBA on-premise, that person's job is ensuring that the system is up. It's not necessarily getting insights out of the data we have. Making actionable business decisions... Let me say that three times in a row, business decisions on all of the data that we have to be able to get actionable business decisions from our data.
So, our point of view is we want you and your staff to focus 100% of your time on analysis, on running analytics, insights, all that stuff, because we will manage all of these things. We'll manage monitoring, performing, performance tuning. I won't get into all of them, but we'll manage all this stuff. You just focus on the analysis portion.
From a TCO perspective, it's always cool technology, but show me the money. Does it make sense from a monetary perspective? It does. It's literally pennies on the dollar when it comes to the vast majority of systems. So, this was a comparison of legacy enterprise data warehouse. We're not making any jabs or anything, but this is a legacy enterprise warehouse on AWS. This is how much it costs, right? So, this is the cost perspective. This was a larger customer, but was going from running around $15 million all the way to $6. In your case, it may even be more, right? It may be more than 52%. It could be as large as 95%. That's something that we saw for a customer we recently deployed on as well.
So, what are some of the benefits of using something like BigQuery? Scalability, right? There's a data set that you can actually run. I would not recommend running it if you guys have Google Cloud. There's 100 petabyte public data set that you can actually run BigQuery on. It'll cost you $5,000 to run. I would not recommend. But if you want to see scalability, [inaudible 00:27:15] at all, right? So, we have humongous data sets that are actually run within BigQuery. Very simple, if your staff knows how to use SQL, if your staff knows how to ask question, then they can ask questions. They can actually ask natural language questions that then get translated into a SQL query, right?
So, the barrier of entry for using this solution is very low. You're able to share those results in a very accessible manner, security, fine-grained access. We do all the stuff, roles, permissions, data governance. And then cost saving is the last portion of that as well. This is something that I talk in specific. Public sector organizations are like, "Yeah, but how do you guys do data governance?" So, fine-grained access controls, metadata management, and data discovery. Everything is always encrypted.
If you guys have bathroom time to read some of our journals, I can send you guys a number of journals on how we do encryption and data encryption. Maybe I'm just weird and I read that stuff on the toilet. Discover classified, redact sensitive data, using our data loss prevention tools, and then sharing data sets for read-only both internally and externally at any scale, right? So, a lot of cities, a lot of counties, a lot of states have these public portal initiatives. You want to be able to expose just what the public needs to see and then expose other things to internal staff as well.
So now, I'm going to pivot over from data analytics to Google AI, right? I wasn't joking around when I was saying, we're going to be jumping into a bunch of different topics. I'll keep this as short as possible as well. So, inherently, Google is an AI company, right? We've been doing AI for the last 10 years in a number of different products.
When we started for the most part in 2012, integrating some level of machine learning in our products, we had around 400 projects that were currently running in 2012 that were using machine learning in some fashion that way. This is actually an old infographic. It's more like 20,000. So, now there's 20,000 projects that are actually using machine learning and AI in some capacity, right? This is used across a number of our different products, whether it's search, autonomous vehicles, data centers, or specifically Google machine learning companies within the Alphabet umbrella, DeepMind or AlphaGo.
So, the AI platform has a lot to offer. At the end of the day, Google has failed the consumer, has failed the enterprise if we're producing these really cool tools and not making it accessible for the masses to use, right? So, this goes into the narrative of democratizing artificial intelligence and machine learning. We can build all these tools in isolation, but if your staff aren't machine learning experts, how can they take advantage of this?
We have created the tools in mind for business users. We've created in mind the lowest level of technical ability to take advantage of all the innovation that we built. That's our story when it comes to democratizing. We build great solutions, but we build it for everyone to use regardless of whether or not you have PhD in machine learning at the end of your name, right? So, we're developing it and deploying it for everyone.
There's a lot of challenges when it comes to data science and machine learning, right? The ability to integrate the data science environment, choosing the right or flexible machine learning framework, making sense of a lot of these types of information. The way that we approach that is in three different ways, right? So, the first way and just to be honest, this is a little bit for more technical staff, which is having the ability to build your own models, right? So, this is more relevant to larger counties, states. If you're a very innovative city or small town or village, that's great as well. So, we give you the ability to actually from scratch build your own models in a managed service in our cloud.
You go more into the middle to where, "Hey, why not just take advantage of what Google has built, but provide your own data sets?" So, we have machine learning models. We have something called Vision API, right? You feed an image into Vision API and identifies what are the objects within the image. But it identifies it from a population of 30,000 logos and things that we have or maybe let's say it's relevant to your own needs that you're identifying logos that are not in the Google system or a use case that's not in the Google system or hey, we want to categorize screws based on a certain size or height or length. So, you can do that.
So, you can feed in your additional data sources into our models to improve it to give you the best of those results or even the last perspective, which is what I talked about user friendliness. This is what I talked about, right? These are just API's. So, you push the data into it. It returns the results in any format that is accessible to your own use case.
And then one specific thing that I like to talk about too is dialogue flow, right? So, dialogue flow is how Google perceives virtual agents. Dialogue flow with COVID, the last year, has been deployed across 12 states on other telephony systems and on their websites, right? The virtual agent has been deployed on state websites, county websites, city websites all over the place in addition to actually integrating it within the IVR. So, that when you would call in, it's able to kill the IVR tree, the dreaded IVR tree. Press one for this option. Press two for this option. It goes, "Press nine if you want to hear the options again." We're killing that model, right?
What we want you to do is be able to just speak in a natural way to a virtual agent and they could start any number of different conversations, resolve your issues, resolve your constituent issues within the phone. Only when those topics needs to be escalated, they can be escalated to a human agent.
So, when we talk about innovations and what we've done, this is one thing that we've done in the City of Memphis with AI, right? So, the City of Memphis was struggling to maintain visibility of vacant properties and potholes. Traditionally, they were just relying on resident reporting, but we actually developed a machine learning model that they're able to run on their buses. So, as their buses are actually moving through the city, it's identifying potholes and mapping it. So, that when the maintenance crew goes out, they know that they have these six potholes out in this intersection.
Another use case is the State of Illinois and this is specific to virtual agents, right? Department of Labor was slammed with a number of calls around unemployment insurance, all that stuff. When the pandemic started, they were receiving upwards of 2,000 to 400,000 calls a day. Their contact center was set up for 20,000, 10,000 calls. So, they weren't picking up around 99.8% of calls. So, we deployed a solution to help alleviate that issue, be able to respond to constituent's needs, be able to pick up every call.
Previously, all these calls were either being marked as busy or dropping. So, people were kept calling in and calling in and calling in. The vast majority of the time, they were just asking, "What's my claim status?", "I'd like to reset my pin," these FAQ type questions that they needed to get to a human agent to answer. What we did was we embedded the virtual agent into their telephony system. So, often a system, we're able to resolve anywhere between 70 to 90, right? It depended on the time of COVID or the priority was, but 70 to 90 of those interactions were resolved within the IVR through dialogue flow.
So, I'll just jump lastly to this. So, I can give some time for questions. So, this is a unique offering that Google only has, which is the public sector subscription agreement, right? So, it gives the customer, you, your public sector organization the right to use any Google Cloud Service unlimited for a fixed price. What does that mean? This is what the State of Illinois did as well. They worked on more of a CAPEX model. They want to be able to predict budgets, and they don't want to rely on consumption.
What we do is we sit down with you and your staff. We understand what the workload is. We estimate what the workload is going to cost to run. Obviously, Google takes on the risk. We'll obviously do our due diligence, but Google takes on the risk that even if you go above what we've previously agreed on, there's no true up fee, right?
Let's say, we quoted you a number for what it would cost to run all your VMs on our cloud. For whatever reason, there was a spike, right? There's a spike maybe during tax season. One of your systems went 600%. You exceeded our agreement by $200,000. I'm just throwing out these random numbers. But if you exceeded our agreement by that amount of money, at the end of the year, when the subscription agreement ends, you pay nothing. There's no extra costs, nothing. The second year, we would look at, "Hey, it looks like that's going to occur. Should we embed that into the cost and then go on from the second year?" We also have multi-year agreements as well.
So, there's no overage fees. We give you a predictability of cost depending on the workload that you have. Thereby Google takes on the implementation risk rather than the customer, right? So, Google has skin in the game when it comes to this exact issue, right?
So how is this different, right? The competition has fixed price, fixed quantities for the solution, reserved instances. We give you a fixed price for the entire Google Cloud solution, right? Discounts based on usage, this is the competitor side. We apply discounts on the entire thing, right? So, we're giving you a discount off of the entire agreement. There's no way to effectively budget for overages. As I talked about before, there's no overage billing, right? Tax season comes, one of your system goes up by 600%. You went $60,000 over the agreement. There's no overage billing at all.
There's no variability to the cost every year. So, it's not like yeah, we estimate that you're going to be consuming around $200,000 in VM services. Come the end of the year, you consume $400. If you were with a competitor, you would be paying that $400,000. With us, you pay exactly what we agreed upon. And then every product has a different pricing model. You have the right to use all GCP services within the console to best utilize and combat whatever issue that you have.
So how can you get started, right? So, I'm just closing it off, leaving 15 minutes. How do we get started? Now, how does an organization like ours get started? Identify a workload to move to Google Cloud, collaborate with your customer engineer who's me, right? So, I and a number of my peers support the region that you guys are calling in from. So, feel free to reach out to us. Feel free to reach out to Carahsoft. We will sit down with you and talk about your individual issues that you're having. We will tell you the best plan as to how to combat it.
And then work with your account rep, right? So, I'm more on the technical side, but we have account reps as well. We have a couple actually on the phone today, not to call any one out specifically, Mark Pulido or Joel Pingel. But work with your account rep to ensure that "Hey, we have a workflow that makes sense from a cost perspective, from a technology perspective. Can we take advantage of the public sector agreement? How can we lock that in for three years or something?" So, that's a discussion that is important to have as well.
So, let's get solving. I'll move on to the last slide and then open the floor up for questions. Joseph is the contact at Carahsoft. Feel free to reach out to him, send him all of your requests, and then he will route them appropriately as needed. Okay. So, we already have a question that came up. So, are there any limitations to analyzing any specific type of hypervisor like VMware? No. So, we partnered up with a company called CloudPhysics. We've actually purchased a company called StratoZone. CloudPhysics is focused on VMware, VMware hypervising. I don't know if that's a term. I made it up.
What we can do there is we would run an agent, right? We would run an agent on your vSphere that runs all the analysis of your resources. We can send you guys a Security FAQ if you're concerned as to what type of data is actually being scanned. It's only resource utilization data that's being scanned, no personal information, no application data, so on and so forth. So, that's what we do for VMware.
But for every other hypervisor, maybe you're using Nutanix, Hyper-V, so on and so forth, we actually purchased a company called StratoZone. We'd be able to run that agent on any hypervisor that you have. Even if you're utilizing bare metal or anything, we'd be able to run that agent on any type of hypervisor. I don't know if that answers your question.
So, we have a number of OLAP/OLTP databases on site. We would like to ingest into one solution, Oracle, Microsoft SQL. What would be the best way to aggregate that data into one source? Okay. So, there's a number of different approaches that we can have with that, right? How do you want to utilize that data within Google Cloud, right? I have all these different data silos that I have on-premise. I have a number of these different data silos on-premise. I want to be able to aggregate all of that data into one system and run aggregated SQL search against it. How do I do that?
So, we have a number of different pipeline tools today. We have something called Data Fusion. It can connect to your on-premise database systems. It can connect to your Oracle systems, Microsoft SQL. We have hundreds of different SQL, JDBC driver back-end systems that we can integrate into. And then we will be able to pull actually the data out of that and aggregate it and push it into BigQuery or any number of our cloud managed servers. So, that's one way to do it.
We also work with a number of different partners that have built specific pipelines for specific services. So, if you're talking about something like, "Hey, how do we pull in something like Athena? Well, we're using AWS Athena, we want to take advantage of some of that data and some of the cool things BigQuery has," we can use a tool from a partner company like Fivetran. All they do is build data pipelines. So, that's a tool that we can utilize. I got a probably long winded answer, but the short answer is Google has a number of different managed services that it can do for data pipelines that we also work with partners, we can also pull that data in.
We work with COTs, software vendors, I'm assuming, on compatibility yourselves or is that mostly customer driven? For example, if I purchase some piece from... Okay, yes. It depends, right? So, we do it either on a pre-sales perspective or a post-sales perspective. I understand your question, right? So, you deployed something. It was like, "Hey, a part of the deployment, you got to use something like an Oracle database for the back-end system." We actually worked with a vendor. We were actually able to qualify it. They were using Oracle on-premise. What they found out actually was there was compatibility with using MySQL. So, we actually pivoted their entire... They had actually some performance issues using Oracle on-premise.
So, we sat down with a vendor. I'm not saying it'll always be pre-sale, but it was part of a pre-sales engagement. We qualified. That's actually our managed SQL instance, which is MySQL. That was an option. So, they used the MySQL instance in our cloud, and there was no issues, right? So, it just depends on who the vendor is, our working relationship with you. We'd be more than willing to come and check that out, right? So, if you guys are using something that requires a Microsoft SQL back-end, "Does it make sense to port that?" is situational. Yeah, I would say it is a little situational. I mean, we've done a lot of deployment.
So, a lot of that stuff is standardized. So, if you say, "It's this type of solution," we can go back and turn around and be like, "Hey, has this been done before? Okay, this is the working relationship that we have with a vendor. This is what we've done before in this situation." So, I guess the short answer is yes and no. So, it is situational if it's a vendor that we haven't worked with before, but it's also a no if we have worked with them. So, we have the best practices and all that stuff.
What should we do if we want to test that one idea PLC/POP? Just talk to us, right? So, reach out to Joseph right here. We'll scope out what the PLC you have is. Depending on whether or not it makes sense, we can actually provision for you free Cloud Credits to actually test it out depending on how technical your staff is, or we can help assist you and set you up with a partner who can validate that with you. So, what we would need upfront is one of the defining success metrics. We've done this a number of different places. So, what are the defined success metrics for that PLC or Pilot?
Once we have that and have an understanding of your goal forward plan, so hey, can I have more cost savings? Can I lower my overall TCO? Can I improve reliability? Can I introduce high availability into my systems? Can I introduce a better disaster recovery plan? Once we get what those exact metrics are, then we'd be able to start the PLC with you and have completion/success points as a part of that. Just feel free to reach out. This is what I do on a day-to-day basis, right? So, I'm on the phone with customers and prospects every single day, going through what issues that they have and validating that those issues can be solved on our cloud.
Speaker 1: Thanks for listening. If you'd like more information on how Carahsoft or Google Cloud can assist your public sector agency, please visit www.carahsoft.com or email us at google-sales@carahsoft.com. Thanks again for listening and have a great day.