At OpsNow, we build products and services around FinOps. But before we discuss what we offer, we need to ask ourselves a fundamental question: Do we truly understand what FinOps means?

We hear phrases like, “FinOps is essential”, “It's a must-have”, and “You can't live without it”, these are often thrown around internally. But perhaps the right place to start is by asking: Is FinOps truly necessary?

Even as the member of OpsNow, I've asked myself, “Do we really need OpsNow FinOps to reduce cloud costs?” And honestly, my answer is “No” but I also believe that FinOps is absolutely necessary.

It may sound contradictory, but I'll explain why—not based on theory, but on experience. I'm not claiming to have all the answers, but I'd like to walk you through some of the thoughts and lessons that brought me here.

This post is based on personal experience. It's not the absolute truth, nor a one-size-fits-all solution, but it is real. And sometimes, real experiences reveal more than theoretical perfection ever could.

‍

The Utopian Start: When the Cloud Meant Infinite Scale

Since 2012, I have led the development and operations of a cloud team at one of the most well-known companies in Korea. The team was established to drive the company’s future growth. My first impression of the cloud world was that it felt like a utopia.

Before leading the development and operations of the cloud team, I worked as a kernel systems engineer—battling over every single byte of memory and chasing every second of performance improvement. I was stuck in the often-overlooked, shadowy world of low-level development. But when I entered the world of cloud computing, everything changed. If there was a memory issue, the solution wasn’t to dig deep and fix the root cause—it was to just add more servers. If there was a performance problem, you simply upgraded the specs. It felt like I had stepped into a whole new world. Only those who’ve worked in the trenches of low-level development can truly understand the joy of entering this kind of "paradise."

When we first launched the cloud team, none of us—including myself—had much experience with the cloud. We started from scratch, alongside a few new team members who had worked with cloud technologies elsewhere. As we grew together, so did the team, the organization, and even the company as a whole. I remember leading several cost-efficiency task forces, introducing in-house solutions to boost productivity, and ultimately helping the company save a significant amount of money.

Drawing from those experiences, I want to reflect on how we approached cost optimization and streamlined our operations back then—and how those practices connect to what we now call "FinOps." I'll explore how our efforts not only made cloud spending more efficient, but also influenced broader collaboration across teams and functions.

‍

2011–2013: The Golden Age of Cloud Growth

Between 2011 and 2013, the term “FinOps” didn’t even exist. As we migrated to the cloud, we hit an inflection point—costs began to rise significantly. At the time, the cloud was perceived as a cheap alternative. But once we started managing large-scale infrastructure with our own modules, processing millions of data transactions per hour, and operating in petabyte-scale environments, the cloud quickly became expensive.

And we didn’t question it. We simply thought, “This is just how it is.” I believe we operated under that assumption until around 2015.

But was it simply our lack of cloud knowledge that led to those high costs?

In reality, managing file transfers and image delivery for tens of millions of users—while handling both development and operations—was a massive technical challenge. It required deep expertise in large-scale systems and data processing. At the time, the industry was shifting rapidly to the cloud. Everyone was experimenting with performance, scalability, and availability. Money wasn’t the priority—scalability was. It was the golden age of “just go for it,” even if we didn’t fully understand what we were building.

And it worked—because, honestly, nobody really understood the cloud yet. The teams managing budgets didn’t fully understand infrastructure. The engineers didn’t fully understand finance. That gap made it easier to get approval from both executives and finance teams.

I still remember how we had no concept of microservices architecture. When an issue occurred, we just added more servers or bumped up the specs. We didn’t truly understand why databases mattered. It was the age of “cover one issue with another.”

‍

Painful Lessons and Operational Maturity

I went through all kinds of experiences back then. I remember trying to handle massive traffic with simple, naive assumptions like, “Isn’t it just a matter of running the right query?” We often believed development alone could solve any problem—and we largely ignored operations.

One of the most unforgettable moments came right before a major service launch. Someone pushed a code change without any coordination. The service wasn’t stable even on launch day. The result? A full-scale outage that lasted three days. The service nearly died before it was even born.

Yes, the code issue was fixed quickly—but we didn’t realize that the backlog of incoming traffic would keep causing problems until it cleared. That’s when I learned a critical lesson: real operational skill lies in knowing when to take a service offline and when to bring it back up. It took us three full days to make that call.

Looking back, those painful experiences shaped who I am today. I’m not a cloud “expert,” but I became a hardened practitioner. I’ve run and maintained countless services. I learned just how easy it is to overspend in the name of scale—and how to convince upper management to approve those decisions.

‍

Enterprise-Wide Cloud Cost Reduction in 2014 – Initiation of Activities Similar to the FinOps Concept

Starting in 2014, due to global economic uncertainty and other factors, company-wide efforts to reduce cloud costs began in earnest under the overarching theme of 'cost reduction.' At that time, I remember that the primary goal was simply a 30% reduction in costs compared to the budget, which marked the beginning of more structured cost-cutting activities.

In the midst of these cost-reduction efforts, the complex cost structure of the cloud began to stand out more clearly. This is because the cloud operated under a completely different set of principles compared to traditional accounting or finance practices. In accounting or finance, costs are typically managed within an annual budget, but in a cloud environment, usage fluctuates in real-time, making it difficult to accurately predict costs and budgets. During a time when cloud usage and costs were skyrocketing, this characteristic led to the repeated challenge of maintaining excessively high specifications to ensure service quality, or continuing to operate without optimizing the initial design due to the difficulty of making structural changes to improve costs.

At the time, the executives and finance department referred to these costs as 'inevitable expenditures'—what we called the 'Grey Zone'—accepting them as unavoidable. It felt like pouring water into a leaky bucket, constantly spending without seeing real returns. Finance would set the budget with the assumption that everything would be fine, but once spending began, unexpected costs kept arising. It was only then that the severity of the situation became clear. Back then, there was still a strong perception that these were 'investments,' and even if there were complaints, the general attitude was to just move on and accept it.

Amidst this, the pressure for intense cost-cutting across the organization grew under the keyword 'emergency management’. Even though I was part of the cloud team at the time, the concept of FinOps didn’t exist yet. Instead, under the general goals of management innovation and cost reduction, we were asked to achieve a blanket 30% cut. The pressure increased when it was made clear that failing to meet this target would impact executives' KPIs and evaluations, which prompted the organization to start paying closer attention to costs.

The first step in the cost-reduction efforts was to assess the current situation. We began by identifying whether there was anyone responsible for managing costs and resources, and how those resources were being used. Due to the complex relationships between departments, this information-gathering process took several months. At the time, even cloud service providers (CSPs) were unable to clearly provide users with detailed information on cost and resource usage.

Recognizing the limitations of internal capabilities, we decided to also engage in external assessments. As a result, we began implementing an external Cloud Management Platform (CMP), along with Proof of Concept (POC) trials for several similar tools and in-house development. Consulting firms like McKinsey and Accenture were brought in to conduct a comprehensive evaluation, reviewing 300–400 different metrics. It was a time when we spread out hundreds of Excel files and relentlessly questioned department heads about their usage details. Looking back, while these actions weren’t entirely without merit, the conversations often felt one-sided, especially when we didn’t fully understand the services in question. This approach also deepened the divide between the diagnosing department and others. It was a time when the sentiment of “Do you even understand this service?” was very much in the air.

As mentioned earlier, the first step in the cost-reduction efforts was to understand the current situation. Anyone who has used the cloud within an organization knows that in an unmanaged cloud environment, all you can do is check the cost invoices—making it difficult to gain detailed insights, which leads to significant confusion. Given this background, we began by collecting and organizing this information as our first step.

During this process, the concept of 'entrenched interests' began to form. The organization that was quickest to assess the situation and report to the executives gained greater influence, effectively taking on a 'dominant' position. As this structure became more established, it sometimes led to a breakdown in trust, creating deeper divisions. Watching this unfold was, at the time, quite an interesting experience.

Once the information gathering was complete, we moved on to the critical question: “Are we spending these costs effectively?” Theoretically, we analyzed the usage of resources such as memory, I/O, and CPU. Any resources with low usage were deemed wasteful, and we took steps to reduce or delete effectively. However, the initial design wasn’t properly suited for cloud operations, and reducing resources without a deep understanding of the service and its domain knowledge could lead to major service outages. In particular, approaching it without fully understanding the essence of the service became a key cause of unexpected issues. As mentioned earlier, the problem often created a vicious cycle, where one issue was simply covered up by another.

After drastically cutting resources, service outages occurred, and department heads strongly opposed the budget-controlling team. “If you cut costs, can you take responsibility for these service outages?” was a common question, leading to frequent conflicts. In the end, the organization was forced to choose between two options: either make cost reductions with an appropriate compromise or give in to the resistance.

Amidst all this, there was an incident where a relatively successful service was discontinued. On the other hand, another service, which was the highest cost driver, continued to be maintained despite having many areas that could be reduced, due to its future investment value and various stakeholder interests. I understand that this service is still running successfully today.

‍

2015–2018: Cost Distribution Through Multi-Cloud and Negotiating Discounts with CSPs

Between 2015 and 2018, the approach to cost reduction began to change due to a lack of understanding of services and complex stakeholder interests, all centered around the word 'cost.' This is just my personal opinion, but I believe this change can be divided into two approaches.

The first approach was negotiating discounts with Cloud Service Providers (CSPs), which helped offset some of the internal management difficulties through these discounts. This was a feasible strategy because large enterprises were generating significant revenue for the CSPs.

The second approach was applying discounts through Reserved Instances (RIs). This was before the introduction of Savings Plans (SP), so the central team managed the RIs and distributed them across departments as a cost-saving measure. However, the complexity of managing RIs and the dissatisfaction of departments excluded from the benefits became significant issues. Especially in the beginning, without proper expertise, mismanaged RIs and low coverage sometimes led to cost explosions. This experience highlights why items like RIs and SPs are crucial to be automatically managed in current FinOps practices.

Ultimately, the cost management strategy evolved into cost distribution through multi-cloud and negotiations with Cloud Service Providers (CSPs). While this approach aligns with today’s FinOps strategy, at the time, employees' maturity in cloud and cost management was insufficient, leading to a lot of complaints.

Additionally, thanks to the credit benefits offered by major CSPs like AWS when introducing new services, some organizations occasionally attempted to switch solutions. While this series of events provided a great opportunity for technical growth as we encountered various new solutions and multi-cloud environments we hadn’t experienced before, from a personal perspective, I believe the biggest beneficiaries were the CSPs. This was because, at that time, very few companies were actually operating large-scale traffic and data, so for CSPs, it was an excellent opportunity to gain real-world experience. Based on these experiences, CSPs made rapid progress.

Meanwhile, the usage and data of cloud services continued to increase, and despite various cost-saving efforts, the phenomenon of rising costs began to emerge again. Eventually, with the exception of major services, there was increasing pressure to reduce costs for services with MAU (monthly active users) below a certain level or with low revenue contribution. As a result, the operations and development teams began to intensively consider architecture and performance improvements for survival, and infrastructure and development innovations began to take place within the constraints of a limited budget. (Operations were also included).

Starting from this period, some organizations began the full-scale transition to more advanced cloud architectures, including the adoption of ChatOps, EKS-based advanced structures, Terraform utilization, the use of external SaaS solutions, and the shift to serverless architectures. The effort to reduce costs while ensuring performance was, quite literally, a 'crazy level of persistence’.

Until then, the structure was mostly led by a few technical leaders, and there were significant gaps in cloud maturity across the organization. However, starting from this period, the overall maturity of service owners—in terms of development, operations, and cost management—began to rise rapidly. Under constant pressure, including zero-downtime operations, user complaints, failed attempts to adopt new features or solutions, late nights due to operational failures, and being called in by the finance team, teams began developing real, survival-driven strategies. In other words, development started shifting toward operations-focused engineering.

And as we kept pushing forward, we naturally came to realize just how inefficiently we had been using our resources and manpower. That awareness ultimately led us toward what we called “ruthless automation.” This marked the beginning of full-scale innovation in both technology and operations for automation. The reason was simple—if we didn’t automate, the workload would become unbearable, and we’d eventually collapse under the weight of it.

These hard-earned experiences led to deeper technical exchanges for survival and what we jokingly called "tech showboating" between teams. It eventually evolved into interdepartmental competition and pressure. Teams began to compete with claims like, “We do it better,” “We run stable services with fewer people,” or “We operate at lower costs.”

‍

2019 Major Cloud Cost Reduction Project – The Beginning of Full-Scale FinOps Activities

A few years later, a company-wide project for major cloud cost reduction was launched as a top executive mandate. Simply put, it was a directive to “cut costs because we’re spending too much.” This marked the true beginning of full-scale FinOps activities. At first, it felt overwhelming, but we pulled every possible lever—optimization, efficiency improvements, the adoption of RI/SP, and EDP negotiations.

As the initiative ran into challenges due to conflicting interests across different departments, we implemented a two-pronged strategy. First, a team of cloud experts was assembled to thoroughly review each service’s architecture. Second, the finance team began enforcing the use of FinOps-like tools to ensure transparent data collection and launched diagnostic efforts based on those insights.

At first, we approached the problem with common methods like removing unused resources and applying right-sizing techniques—typical FinOps practices. However, with the organization’s growing cloud maturity and increasing accountability for service quality, these basic approaches eventually hit a wall. No matter how compelling the data looked, the moment we faced teams with deep understanding and ownership of their services, any pressure to cut costs lost its momentum. 

It became clear that a new approach was needed. That’s when we began developing internal capabilities for resource scheduling and spot instance management which are features that are now standard offerings from most CSPs.

To validate these tools, we launched what was essentially a trial project. It is a "sacrificial lamb" and spent three months preparing baseline data to test whether things would work. Honestly, whether it worked or not wasn’t the key point. What we really needed was a vehicle to promote FinOps adoption across the organization. We did our best to build a solid solution in a short time, but as many of you know, such quick builds often come with downstream challenges and require immense patience to stabilize. 

Despite this, we forged ahead and developed various optimization tools—such as custom-built scheduling systems and spot instance management features (heavily modified from open source tools like spot.inst at the time). We then aggressively tested them on a project internally developed and operated by our team. After three months of intensive optimization, we used the resulting data to enforce tool adoption across other teams. This also led to fundamental service architecture redesigns and assessments of staffing efficiency. 

Though we publicly credited FinOps tools for these successes, the real cost savings came from deeper architectural changes—data structure transformations, modernization efforts, and workforce realignment. Ultimately, this transition pushed me, who had previously focused only on cloud service development, into a full-blown operational role—marking the turning point where I moved into the “attacker” position.

Based on this experience, we realized that it wasn’t necessary to move the entire organization at once. Instead, we focused on driving change within a few key teams. Using their success as a case study, we presented cost-saving outcomes and forecast models to senior management and the finance team. Then, we assigned cost reduction KPIs to each division head, effectively mandating participation. The diagnostic team placed heavy emphasis on building deep expertise in cloud services and establishing technical credibility. With this foundation, they offered tailored strategies and tools to higher-level departments. This approach aligns closely with the core philosophy of FinOps today.

In reality, the most significant cost reductions didn’t come from using FinOps tools themselves, but from the broader organizational changes triggered by those tools, like architecture modernization and workforce optimization. One of the toughest challenges we faced was the constant questioning:
“Does this save more than RI/SP?” and “Is this approach really more effective than EDP discounts?”.

In some cases, the numbers were actually reversed, and we saw worse results compared to traditional pricing models. But what truly mattered wasn’t the present—it was the long-term savings resulting from future structural changes. This led to intense debates and an uphill battle for buy-in. The impact of these changes became visible gradually.

However, if not backed by continued management, the results could easily collapse. If you miss the right moment for managing workloads, it can lead to a return to the old ways, an accumulation of technical debt, and unstable costs. Once a team experiences a failure like that, distrust takes over. Organizations that have gone through this tend to strongly oppose any future FinOps initiatives, especially those proposed by external parties. 

It’s like a yo-yo dieting: without continuous effort and discipline, the system rebounds. This is one of the most crucial points in the FinOps ecosystem. 

No matter how well you're managing costs internally, external factors can often make your efforts meaningless. If you're looking for the most common example, it would be exchange rates.

For example, by 2021, we were able to see some rewards for our efforts in efficiency optimization and structural changes. However, there were times when those efforts were diluted due to factors like currency fluctuations. 

After successfully reducing costs by 1 billion KRW per month, we’d often see those savings reversed due to exchange rate increases. This would lead to frequent, one-sided communication from finance, questioning whether the cost reduction was actually achieved (In these situations, it often leads to a vicious cycle of layoffs.) Given the current global economic conditions and fluctuations in the Korean exchange rate, I believe we’ll start to see similar cases again. History tends to repeat itself.

Anyway, the story so far is based on past experiences. To sum it up, it always starts with the leadership’s sense of crisis, which sparks pressure and accountability. When the organization doesn't act, it begins to move under the control of KPIs and budgets. Of course, there are also organizations that manage themselves very well. In those cases, there was no need to force external tools or methods—since they were already doing a great job, it was better not to interfere and disrupt their momentum.

Additionally, various functional methods such as cost analysis, anomaly detection, recommendations, resource comparisons, multi-cloud comparisons, performance analysis, and network diagnostics have become standardized and are familiar to all of us, serving as the starting point when tackling a problem.

‍

Cost-Cutting in Single vs. Multi-Service Management Organizations

Now, let's take a look at how cost reduction actually happens in the real world, based on past experiences. Do we truly understand this process? This is where the story begins.

As mentioned earlier, there is always a trigger. Whether it's from the management or anyone else, someone raises concerns about costs and resource usage. If you're lucky, when the issue is pointed out, you can understand it correctly and respond voluntarily. However, unfortunately, in most cases, this is not the case and people usually tend to avoid it.

The reason for this is clear: the work increases, and there's a chance of being criticized. Plus, everyone already knows, while it’s easy to spend, reducing costs is incredibly difficult.

So, in the end, this task revolves around three basic pillars: the person who executes, the one who diagnoses and analyzes, and the one who evaluates and makes decisions. Expanding on this, the roles become more detailed, much like the current personas outlined by the FinOps Foundation.

So, let me give you an example,

“If we have to cut this month’s budget by 20%, start with cloud costs.”

When a directive like this comes down, what do the teams do first?

“Bring me all the cloud spending data from the past 3 months, 6 months, and one year.”

That’s usually where it starts, regardless of whether costs have actually increased or not, the conversation begins with the data.

At this point, the approach differs depending on whether the organization runs a single service or operates multiple business units.

For organizations with a single service, the first step is to analyze which resources are consuming the most cost. Then comes the question: “Can we actually reduce this right now?”

‍
The areas with high costs are usually predictable, like databases or network charges. To take action, most teams begin by checking for unused resources. But in reality, the cost savings from this approach are often smaller than expected. Sometimes, you might get lucky and discover an expensive resource that wasn’t being managed—but that’s more about luck than strategy.

‍
Next comes the task of generating a list. You carefully identify which resources can be modernized, in other words, right-sized.

You dig into the data thinking, “If I reduce this, maybe I can say we’ve saved some costs.” You prepare with that in mind, but then the doubts start to appear.

“Won’t this cause a shortage in RI/SP coverage?”

“What if we break our EDP terms and get hit with a shortfall?”

“When do our RIs or SPs expire? Can we even make this change in time?”

‍

When these concerns come up, the previous options start to feel too difficult, so we go back to reviewing all the accounts we’re using, which are production, development, and so on.

The order may vary, but in the end, every single account gets examined one by one.

Once the accounts are somewhat organized, the report typically goes like this, proudly:

"If we continue reducing like this, we can effectively cut costs". It’s the usual, one-dimensional report. But in reality, cutting more than 20% is not easy. And now, you’re at a crossroad.

"Should we really shut down unnecessary services?” Or “should we reduce the workforce allocated to them?"

But either way, neither choice is an easy one.

So, someone with experience in both development and operations will begin to think about the core issue here:

“This is tied to revenue, so from an ROI perspective, shouldn’t we reconsider our architecture or design?”

At this point, structural changes in development and operations begin. If this discussion isn’t held, it will eventually be left in the 'inevitable cost expenditure' grey zone, and the organization will continue to maintain that status quo.

______________________________________________________________________________________________________________________________________

For an organization managing multiple services, the flow is similar, but the starting point is slightly different. 

Most organizations start with the question, “Which organization is spending the most?” 

This approach directly connects to the organization with the highest costs and the person responsible for managing it. Even if the high costs are justified, relatively well-managed organizations can still end up being the ones that get cut, in order to meet overall targets.

In most cases, the approach mentioned earlier—creating a list, organizing resources, checking accounts, etc.—is followed. However, even in this case, operational differences such as RI/SP management or favoritism toward certain organizations can easily lead to conflicts between teams. In fact, these issues often escalate into situations where responsibility gets shifted to a specific person.

At this point, the organization starts to re-evaluate the cost allocation structure, and debates begin over budgeting and distribution details for each department. Of course, not everyone may have complaints. In fact, some organizations may welcome this change.

________________________________________________________________________________________________________________________________________

However, with some experience in both development and operations, the fundamental questions arise. Since this is directly tied to revenue, one starts to consider ROI and whether there’s a point at which the architecture or design itself needs to be fundamentally reduced. This is when changes in development and operations begin. If that’s not the case, it can remain as 'inevitable cost expenditure,' continuing in its current state and potentially evolving into a long-term grey zone.

On the other hand, if we simply maintain the status quo without such consideration, under the pretext of “unavoidable expense expenditure,” we will enter an increasingly persistent gray zone, and the problem will only become more complicated.

________________________________________________________________________________________________________________________________________

The scenario above is something that anyone has probably experienced at least once.

The department implementing the changes may try to hide things or work hard, but the receiving side will only look at the numbers. They won’t care about the efforts; it’s all about whether the numbers meet the target or not.

At this point, disharmony begins to emerge within the organization.

If, despite all the effort, decisions are made solely based on the numbers, then it comes down to two options: either inflating the figures in anticipation of future cost cuts, or figuring out how to maintain the current state.

At this point, organizations begin to adjust their resource and cost analysis along with the current status.

Based on this example, FinOps is not just about cost reduction. Rather, it starts with assessing whether we are doing things well and operating with the appropriate level of efficiency. The goal is to understand the current state and then convince relevant departments. This process can be seen as a continuous loop, much like a Möbius strip.

Now, the constant question is: Can we truly assess how well we are spending costs with data on things like Right Sizing, Unused Resources, Modernization, etc.? 

The answer is yes. 

However, if you ask whether we can immediately enforce this on actively running services, the answer is no. This is often an easy topic to discuss for departments that are not responsible for operations and services.

Service operations are very conservative, and issues that arise in operations are always accompanied by the heavy word 'responsibility.' It often feels like it's easier to just spend more money. As a result, there are cases where costs increase due to infrastructure expansion.

This cycle repeats itself, and to avoid this, the only option becomes to purchase things like EDP and RI&SP in advance to save costs, without affecting service operations. In more advanced scenarios, they even consider options like scheduling unused servers to shut down during off-hours or switching to cheaper resources like Spot Instances.

However, this is still constrained by the responsibilities tied to service operations. Of course, in more mature organizations, these aspects can be automated, allowing people to focus on more strategic tasks.

The next approach is assigning responsibility. Whether it’s controlling or investing, the task is to delegate responsibility to the department in charge. Why? Because it’s the easiest way. There’s nothing more convenient than saying 'If you can't do it, take responsibility.' So, how do you do this? You can do it through Excel, looking at each resource one by one, documenting and organizing it. This is feasible when resources or the organization are small.

To manage this well, tags are introduced to categorize and manage everything clearly. This way, it becomes easier to analyze which organization is using resources effectively, distinguishing them clearly from a vast amount of data. 

However, if you ask whether this will directly lead to cost reduction, the answer is both yes and no. Ultimately, for any action to take place, every action requires human involvement, and when individuals feel they’re no longer responsible, the effort often gets abandoned midway. So, the organization began linking KPIs, aligning them with missions and budget controls. Without proper control, these initiatives can become meaningless, which is why many organizations focus on tying them to measurable outcomes.

I have seen many cases where it leads to failure, so the focus shifts to performance within the organization. In such situations, internal discussions begin about how to reduce costs. How can services be provided with minimal costs? How can operational management be more efficient? 

To do this, there must be an understanding of the service and awareness of how expensive the resources being used are, which eventually leads to unit economics. 

Then, at some point, discussions about human efficiency begin to emerge. Ultimately, someone has to take responsibility and act. But just taking responsibility doesn’t guarantee smooth operations. Outcomes vary, depending on that person’s authority and willingness. Moreover, these efforts might be short-term or take a long time to see results. 

However, since it’s difficult for an organization to move organically before its culture is established, there’s a tendency to try to distribute responsibility. In a positive light, when people don’t want to fight, they say, ‘Let’s work together and cooperate.’ But when they become rivals, they start making excuses. 

I believe this is the reason why the recent FinOps framework is shifting from being technology-based to focusing on business performance metrics of the company.

Also, for the departments responsible for finances, understanding the trustworthiness of this data and the work process is crucial. It has become increasingly important to persuade the organization on how well they are spending based on budget plans and forecasts. Depending on the reliability of this data, each department may gain more autonomy. Furthermore, as this process develops, communication between departments sharing common missions and execution will become the most important aspect. 

There’s a saying: ‘You need to understand to use it well.’ The departments that develop, operate, and manage services are the ones who know it best.   As mentioned earlier, I think the recent changes in the FinOps Foundation's framework reflect this. In other words, if you don’t know much about it, you won’t understand why something is used a lot. In the past, when the term "cost" was mentioned, there was room to reduce expenses from a financial perspective. However, nowadays, it's one of the key reasons why the teams managing and developing services need to understand it the most.

That is, under the premise of FinOps, various departments are superficially identifying and improving waste, but ultimately, we need to help them understand this and improve it to use resources more effectively in terms of ROI. In this context, I believe the FinOps tools are the basic means of communicating with common language, bringing together time, effort, and multiple users. 

Some people only look at how much is being spent, others focus solely on technical terms, and some are interested only in KPI achievement numbers. But the base data used to achieve these goals is all the same. Regardless of what it is, payment for services hasn’t changed, and the logic behind calculating the costs of these services also remains the same.

The tools in FinOps, like OpsNow, each have distinct functionalities, but these features should not be seen as being created for a single purpose. They are, instead, part of an integrated system that serves as a means to provide a unified language. While the functional usability of these tools can vary greatly and the reports generated might differ based on what each department is looking to track, the ultimate goal remains the same: helping organizations assess if they are using resources effectively and whether there’s room for improvement. From different perspectives, the data might be interpreted in various ways, but at the end of the day, it must tell a cohesive story. The key is ensuring that everyone agrees that we are using resources properly, and most importantly, we're speaking the same language.

Therefore, OpsNow is now in a position where it can help organizations understand and adopt FinOps. The choice of tool is secondary; what matters is how accurately the concept of FinOps is understood. To implement FinOps successfully, it's crucial to first assess how well the organization understands the principles of FinOps. Only then should any tool be introduced as a means to facilitate this process. 

As I mentioned in a previous personal example, I tried it even without knowing the FinOps theory. Countless failures and successes were experienced along the way, and now I frame it under the term “FinOps.”. The issue for most organizations isn't a lack of theoretical knowledge, but rather the absence of internal experience, the will to take on challenges, operational insight, understanding of each service’s core, and deep reflections on how teams should collaborate. The theory is well-organized on Google, but simply knowing the theory and pretending to understand has its limits.

Fortunately, OpsNow has grown based on extensive operational experience and customer demands encountered through its MSP parent company, Bespin Global. Building on this foundation, OpsNow continues to evolve with the goal of speaking with a unified voice in the realm of FinOps. While there is still a long way to go, the platform is steadily advancing its services under the valuable asset of real-world experience.

However, for those managing FinOps efforts internally, it's essential to  examine how many of those working in FinOps are genuinely involved in development—especially when cost control and efficiency are at stake. While it's easy to say things are going well, there’s a clear gap between those who’ve truly lived the experience and those who haven’t.

In the past, OpsNow’s cloud cost reduction efforts focused mainly on showcasing product features. But now, it’s evolving into something deeper: a process of building a narrative—one that clearly conveys the necessity and context behind each function, and enables organizations to take meaningful action based on reliable data. What used to be a feature-driven solution is now becoming a unified service that speaks a common language across the organization. It’s moving toward a direction where understanding and clear communication are just as important as technical capabilities.

We’re at a crossroads, where it’s important to ask ourselves whether we’ve truly built an environment that enables effective cloud analysis, cost management, and meaningful savings within the organization. From the standpoint of delivering products and services, a deep understanding and hands-on experience in this area are essential. OpsNow FinOps isn’t just about showcasing features—it’s about thorough understanding of FinOps, putting it into practice, continuously evaluating it, and leading organizations forward in that journey.

The fundamental starting point of FinOps is understanding and gaining control over unmanaged cloud costs. Many organizations adopt FinOps with the expectation of maximizing cost savings, but in reality, it's often treated as an optional tool rather than a core necessity. The truth is, most companies are already implementing cost-saving measures in various ways—what we're doing may not be particularly unique or exceptional.

There are various methodologies for reducing costs. Negotiating large-scale discounts with cloud service providers (EDPs), utilizing Reserved Instances (RIs) or Savings Plans (SPs), and implementing resource optimization and efficiency improvements are all fundamental approaches—and these can be done even without a FinOps tool. In some cases, they can simply be replaced with manual effort. However, these processes become far more effective when supported by time, effort, and a deep understanding of the business domain and services. If an organization has the right capabilities, re-architecting service structures and optimizing performance can fundamentally improve both cost efficiency and overall operations.

So why is the philosophy of FinOps necessary and why are tools like OpsNow essential? This question requires fundamental reflection. As cloud environments become more complex and organizations scale, cost management becomes increasingly difficult. Responsibility often becomes unclear, and cloud usage can end up being neglected. Due to the nature of cloud costs, problems are often discovered only after the situation has worsened —requiring significant time and effort to fix. Consistent effort is critical for FinOps to function effectively, and that’s exactly why FinOps is needed in the first place: it provides the foundation for getting started with that continuous discipline.

FinOps allows for the regular monitoring of costs and resources, enabling early detection of issues and minimizing risks. This is the first step towards resource efficiency and cost optimization. During this process, it’s crucial to have transparent data management, budget control, governance, and comprehensive reporting within the organization to clearly understand the flow of costs. Beyond this stage, the essence of FinOps lies in creating methodologies and collaborative frameworks for efficient, systematic management.

The ideal stage is to introduce automation and ensure that the entire organization can communicate in a unified language. Furthermore, a continuous cycle must be established. If it’s just a one-time effort, then FinOps or FinOps tools are unnecessary. OpsNow’s FinOps must focus on solving these problems in a way that supports continuous activity, rather than simply developing features and saying, “We have that feature too”.

There is still much we need to do and many paths we must take. Technology trends are changing rapidly compared to the past, and it's up to us to address these changes. However, if we fail to understand the essence of things beyond just functionality and technology within our own organization, even the adoption of cutting-edge tools like AI could backfire. We might face a reversal where we are outpaced in the new AI era — and I believe this is already happening. Moreover, in an era where cloud maturity has evenly developed compared to the past, to remain competitive with high-quality services and products, we must first have a deep understanding of this essence from within.

OpsNow is in the process of establishing itself as the leader in FinOps among domestic CMPs. In the past, the focus was solely on technology, but through acquiring various FinOps qualifications and obtaining the FinOps Certified Platform, it has evolved into a solution and service that is now reflecting on how to communicate the actual message effectively.

As services evolve and become more convenient, most people, unlike in the past, no longer understand how things work or how they are implemented; they simply use them as they are. As mentioned earlier, in the past, resource scheduling and Spot functionality weren’t basic features, but now they are seen as default offerings. In other words, while technological advancements have enhanced user convenience, it has also further distanced users from understanding and managing the underlying operations. Even now, as cloud services become more convenient, people tend to focus only on what’s visible, rarely trying to understand how things work behind the scenes. This is the area that we, as service providers, need to dig into.

The more you know, the more you can see. Even though we now live in a world where AI brings greater convenience, the role of people who understand these processes and provide accurate information is diminishing. This is where I believe the starting point of OpsNow FinOps lies. What we’ve taken for granted wasn’t always the case. Just as automated management of RI/SP is becoming a standard feature, I believe we are the ones who need to create and provide that new standard of service.

Curious how OpsNow can help you get more out of your cloud? We’ve got just the thing.

Download the FinOps White Paper – Get practical tips and insights to start saving smarter.

‍