devopsy.kinsta.cloud

Tag: cloud

  • Busting 5 Common Database Modernization Myths

    Busting 5 Common Database Modernization Myths

    Modernizing databases is one of the best ways to improve database and application performance. However, many companies are hesitant to make major changes, even if they could lead to better outcomes. Why? Because there are prevailing myths about how database modernization projects fail to deliver on expectations. Five myths, in particular, seem to hold leaders back from pursuing modernization opportunities. We cover each of these myths in detail below:

    • Myth One: There is little performance benefit to modernizing databases in the cloud
    • Myth Two: Cloud databases won’t reduce my IT costs
    • Myth Three: I’m better off leaving my data on-premises for security and availability reasons
    • Myth Four: There’s not much I can do in cloud databases that I can’t do on-premises
    • Myth Five: Commercial databases aren’t compatible with cloud databases

    Fortunately, we’ve debunked these database modernization myths and can speak to the incredible benefits of modernizing databases on the cloud. We’ll use Amazon Web Services (AWS) cloud, specifically, as an example here, as it is a commonly used option for boosting database performance and innovation.

    Myth: There is Little Performance Benefit to Modernization of  Databases in the Cloud

    Modern cloud computing technology has advanced tremendously in recent history. With this advancement comes loftier expectations around database performance. And the truth is commercial databases are falling behind.

    Commercial databases are less scalable overall. They can struggle with latency issues, especially when supporting modern applications. Plus, finding enough processing power can be a challenge. Companies are still dealing with chip and RAM shortages related to ongoing supply chain disruption.

    Cloud providers, on the other hand, haven’t suffered as much. They buy components in bulk and have an overwhelming amount of equipment, infrastructure and memory for running cloud databases. Who benefits from this accessibility? Companies that have traded their on-premises infrastructure and commercial databases for the cloud.

    One of the best features of cloud databases is their on-demand scalability. Organizations can easily scale with customer needs. In contrast, on-premises or private cloud solutions bind engineering teams to their hardware. These constraints don’t exist for cloud users.

    Companies on the cloud can choose from a wide variety of plug-and-play solutions to optimize performance across decoupled services (AKA microservices). These microservices can each have their own database engines that scale as needed.

    Myth: Cloud Databases Won’t Reduce my IT Costs

    The second myth that holds companies back is the belief that IT costs won’t come down in the cloud. Theoretically, on-premises and cloud databases could be equally costly, but this is unlikely in real-world scenarios when you consider all factors.

    With on-premises databases, companies pay in full whether they are buying direct or through a private cloud. They also typically have to buy licenses with fixed pricing. Even if organizations don’t use the maximum resources available to them, they are still on the hook for the full cost. AWS doesn’t operate this way.

    On AWS, organizations only pay for resources consumed if they choose to go the on-demand route. IT teams can otherwise select from different savings plans if they are willing to make minimum volume commitments. Compared to fixed-price contracts, these approaches ensure that costs scale more closely with processing power. This level of elasticity is essential for modern companies that want to deploy modern applications.

    Myth: I’m Better Off Leaving my Data On-Premises for Security and Availability

    Outside of performance and pricing concerns, some still think that commercial databases are better from a security and availability standpoint. Yet, the cloud wins out here, as well. Cloud databases minimize manual work related to:

    • Encrypting data at rest
    • Encrypting data in transit
    • Defining port allowances
    • Preparing for compliance audits

    This is crucial because manual work opens the door for human errors. On-premises databases put these tasks on IT’s shoulders and make administrators responsible for ensuring data integrity. There is no room for mistakes, which is scary when managing complex applications. The good news is that cloud databases alleviate this pressure.

    For instance, Amazon Aurora maintains six copies of data across three availability zones. The solution boasts 99.99%+ durability with <30-second instance failover. Similarly, Amazon DynamoDB guarantees a reliability of up to 99.999%. AWS’ managed databases also offer 256-bit encryption with SSL certifications and rotating access keys.

    Moreover, the cloud provider offers an identity and access management (IAM) solution that simplifies authentication and role assignments for users and resources. AWS also lets users set up security groups, which take away much of the complexity associated with protecting cloud-based infrastructure.

    Myth: There’s Not Much I Can Do in Cloud Databases That I Can’t Do On-Premises

    The fourth myth that keeps leaders from modernizing databases is the idea that they aren’t missing out on much by staying on-premises. But the truth is that commercial databases fall short in significant ways when trying to elevate legacy applications. Most are monolithic by design, which is antithetical to the agile nature of the cloud.

    Organizations that want to deliver modern applications must have modern back-end infrastructure. Today, this means leveraging microservices–and having different databases for different application functions. Taking this approach allows organizations to scale distinct parts of their applications separately according to demand.

    Myth: Commercial Databases Aren’t Compatible With Cloud Databases

    The final myth that slows database modernization progress is the notion that popular commercial databases, like Oracle and SQL server, aren’t compatible with cloud databases. This isn’t true. Amazon RDS, for example, lets users run their Oracle and Microsoft SQL server workloads in a fully managed database service. Amazon Aurora is also fully compatible with MySQL and PostgreSQL databases.

    For the most part, cloud databases allow companies to continue using familiar code, drivers, applications and tools without having to do much refactoring. And should leaders decide to migrate away from commercial solutions altogether, there are import and export tools that help accelerate the process.

    Conclusion

    To summarize, much of the conventional wisdom around keeping commercial databases is outdated. The cloud offers a much more compelling and exciting path. Cloud-native solutions enable companies to take database performance to the next level without any added complexity.

  • Civo Report Surfaces Growing Cloud Lock-in Concerns

    Civo Report Surfaces Growing Cloud Lock-in Concerns

    A survey of 100 IT professionals conducted by Civo, a provider of cloud services based on Kubernetes, finds a total of 82% currently rely on either Amazon Web Services (AWS) or Microsoft for public cloud infrastructure. However, more than a third (34%) of respondents also report they now feel locked into the public cloud service provider.

    The primary reason survey respondents cited for feeling that way is data transfer costs are too expensive to move off their current cloud (65%).

    Simply inertia also seems to be a factor. A third of the total respondents (33%) said they had always used the same cloud service provider. Nearly two-thirds (62%) also noted they were concerned that alternative cloud providers would suffer more outages. At the same time, however, 45% of respondents conceded they are under growing pressure to reduce cloud costs.

    Civo CEO Mark Boost said it’s already apparent that cloud outages are not just limited to alternative cloud providers. In fact, most application workloads are relatively simple in the sense they can run equally well with the same level of resiliency on any number of cloud services at a lower cost than the major hyperscalers currently charge, he noted.

    In effect, cloud computing, except for some more complex workloads, should largely be viewed as a commodity, added Boost.

    Cloud service providers, of course, discourage migrations using exorbitant data egress charges that often make moving data off their platforms cost prohibitive. In fact, most applications are deployed on a single cloud versus in a truly hybrid cloud model because data management can become exceedingly complex. Ideally, IT organizations would like to be able to play one cloud service provider off another to reduce costs. In practice, however, once an application is deployed, it rarely moves to another platform.

    On the plus side, however, microservices-based applications deployed on Kubernetes clusters are easier to move because each instance of a Kubernetes cluster exposes a consistent set of APIs. However, stateful applications deployed in Kubernetes environments can like any other application become dependent on, for example, a proprietary database.

    The tradeoff, of course, is that each cloud platform added to an enterprise IT environment tends to increase total costs. IT staffs typically need to hire additional specialists that require tools to manage each cloud. There are, naturally, platforms that span multiple clouds but the cost of acquiring, provisioning and maintaining those platforms can be considerable. In the meantime, more organizations find themselves separately managing and attempting to secure multiple clouds simply because individual departments prefer one cloud service versus another.

    It’s not clear to what degree organizations may soon decide to consolidate cloud workloads as part of an effort to reduce costs. However, a lot of workloads in the immediate aftermath of the COVID-19 pandemic were shifted to the cloud with little regard for cost. Now that organizations are adjusting to the so-called new normal, many of those decisions are, at the very least, being re-evaluated to see what might make the most financial sense as the general economy seems to become less predictable with each passing day.

  • Tech Workers Struggle With Hybrid IT Complexity

    Tech Workers Struggle With Hybrid IT Complexity

    Confidence levels among IT workers have plummeted as tech teams’ jobs have become more complex. The reasons behind IT worker angst are unprecedented, signaling a shift paralleling other post-pandemic industries. Running applications across cloud and on-premises infrastructure, hybrid office environments with distributed workforces and the accelerated adoption of new and automated technologies have all contributed to increased IT complexity.

    In our recently-released SolarWinds IT Trends Report 2022—Getting IT Right: Managing Hybrid IT Complexity, we examined the current state of IT along with areas of opportunity for technology professionals who must manage this increased complexity as hybrid IT accelerates. “The continued shift to hybrid IT drives increased levels of IT management complexity, but tech pros feel a lack of confidence in how to best manage it,” according to the report.

    Manage Hybrid IT Complexity

    Solutions are necessary, as the research shows only 8% of tech pros surveyed for the IT trends report feel “extremely confident” in their ability to manage increasingly complex networks. More than half of the tech pros interviewed said their organization manages hybrid IT complexity by training staff and adopting IT monitoring/management tools. However, budgeting, time constraints and hybrid work environments exacerbate this challenge. These responses point to a need for intervention and assessment, as IT professionals’ work is more business-critical now than ever. Strong IT infrastructure is necessary for fundamental processes across all industries and business environments.

    Half Lack Visibility

    According to a report by market intelligence firm IDC, as more mission-critical workloads move to connected cloud architectures spanning public, private, hybrid and multi-cloud environments, enterprises recognize the need to invest in the tools which will help them ensure consistent policies and performance, despite budget and observability implementation issues. The SolarWinds IT Trends report revealed nearly half of respondents lack visibility into the majority of their organization’s apps and infrastructure.

    Indeed, visibility is increasingly becoming the clear answer for tech pros charged with managing greater levels of complexity in these diverse and distributed environments. To develop their teams and business for long-term success, organizations must set aside time and resources to upskill and train tech pros to help them properly implement observability strategies and manage hybrid IT realities more effectively.

    Effectiveness Lost Off-Site

    But some aspects of the remote revolution, including training IT workers for increasingly complex network management, brainstorming sessions, providing sensitive feedback and onboarding new employees, lose their effectiveness when done off-site. For those who’ve made the switch to teleworking, most have found more work-life balance but less connection with co-workers or consistent support from leadership, according to a Pew Research Center study.

    Software company Culdesac announced it’s moving workers online and closing its San Francisco offices. Over 14,000 Google workers worldwide moved to a new office or went fully remote during the pandemic. Other companies, like Microsoft, have said employees who want to work more than 50% of the time remotely must have their schedules approved by their managers.

    Things are quickly shifting as we enter the era of post-pandemic IT infrastructure existence.

    Standards for Automated Network Management

    Solutions are growing in availability. The Internet Engineering Task Force (IETF), an international community of network designers, operators, vendors and researchers, is working on standards for automated network management, which aim to improve and make the management of networks more efficient as they continue to increase in size and complexity.

    While organizations also lack insight into their network’s impact on ROI due to increased hybrid IT complexity, looking forward, they must re-examine their investments from the past few years. Part of this requires companies to have visibility into their IT environments to understand what’s working and not working.

    Economic Growth for Those Willing to Adapt

    Technological change could bring about economic growth and opportunity, but only for those willing to adapt. IT infrastructure is so much deeper than most businesses understand, and as the existing data confirms (and most experts in the field agree), investing in IT infrastructure is necessary. A business’ network—and its speed and security—can be the difference between satisfied or frustrated employees and customers.

    As hybrid IT acceleration has increased network complexity and lowered tech pros’ network management confidence, these post-pandemic problems are a chance for organizations to evolve. “The healthy thing to do is to look ahead, accept the reality, and start getting ready for the transition,” said Chirag Shah, an associate professor at the University of Washington Information School. “So instead of feeling the anxiety and being defensive, think of this as an opportunity for advancement.”

  • Techstrong TV: The Future of Cloud Security

    Techstrong TV: The Future of Cloud Security

     

    Check Point Software has announced the acquisition of Spectral, an Israeli start up specialized in automated code security. This further reinforces Check Point’s commitment to cloud security. The video is above and a transcript of the conversation is below.

     

    Interviewer:                Hey everyone, welcome to another segment here on Techstrong TV. I’m really happy to have as our guest on this segment TJ Gonen, and hoping I pronounce that right, from Check Point. Hey TJ, welcome to Techstrong TV.

     

    Interviewee:                Yeah, and thank you very much for having us.

     

    Interviewer:                It’s a pleasure. Is that the right way to pronounce your name?

     

    Interviewee:                No, Gonen is the right way. Yeah. TJ is the name that they changed so no one butchers it.

     

    Interviewer:                Well I hear you. It happens sometimes. Hey I really, as I mentioned to you earlier I like the 49ers, especially in a week where they had a tough game. LA, the Rams are going to the Super Bowl in LA and still it’s close.

     

    Interviewee:                Yeah, they almost made it, almost made it.

     

    Interviewer:                It was close, a lot closer than my team, so who am I to say anything. But yeah I know, good for them. Anyway we didn’t bring you on to talk football unfortunately.

     

    Interviewee:                Of course.

     

    Interviewer:                We’re going to talk security, and maybe that’s better off anyway. TJ, why don’t we start though. Why don’t you kind of give our audience a little bit of who you are, a little introduction. What you do at Check Point, stuff like t hat.

     

    Interviewee:                Yeah, sure. So TJ, originally from Israel. That’s a little bit of the accent, now in the US. I am the Vice President for Call Security at Check Point. So I run the Call Security business for Check Point, and been with Check Point for two years. Actually exactly two years since my company was acquired by Check Point a couple of years ago in the cloud security space.

     

    Interviewer:                Yeah, what company was that?

     

    Interviewee:                So we need to talk about another acquisition so it’s an interesting time.

     

    Interviewer:                Well it’s the circle of life. Right?

     

    Interviewee:                Yeah.

     

    Interviewer:                What was the company that was acquired two years ago, your company?

     

    Interviewee:                Ortega Labs. We were in the servalice security space, yeah.

     

    Interviewer:                Absolutely, and of course servalice is a huge, huge kind of growth area right now. But that was two years ago, as you said TJ, and congratulations to you on that. But we have a new Check Point act, so it’s the way of the world. We have a new Check Point acquisition to announce or talk about today. Why don’t you share with our audience a little bit?

     

    Interviewee:                Yeah, so we just a few days ago we announced the acquisition of a company called Spectral in the code security space, and it’s really our move into the developer first security world, and we’ve been very busy in the code security space for the last four years, Check Point through a series of acquisitions.

     

    Actually to call security business at Check Point started with one acquisition, a company called o9 ______ _____ ______ [crosstalk].

     

    Interviewer:                Sure. I know that 09, who was the founder of o9? Not _______.

     

    Interviewee:                Zor.

     

    Interviewer:                Zor. Yeah, I knew him when he started o9.

     

    Interviewee:                There you go, yeah. So awesome company. So that sort of started the journey, then a few acquisitions later including my company and now Spectral, that’s the fifth acquisition we’re actually doing in the code security space.

     

    So I think one of the things that we found out relatively early is that cloud security is almost trying to reinvent all of security. Reinvent it for the cloud and trying to do 30 years of security in 4 years, and it’s very hard to move without acquisitions.

     

    Interviewer:                Yes it is, and look, quite frankly my background is security, so I’ve been in security 25 plus years.

     

    Interviewee:                Yeah.  

     

    Interviewer:                It’s the reason I started devopsy.kinsta.cloud. It’s the reason I got so attracted to the whole DevOps thing, which was I really felt like it was a fresh chance for us to kind of right some past wrongs. Right?

     

    Interviewee:                Right. Yeah.

     

    Interviewer:                A new beginning, if you will. Now it’s funny, I remember in 2005 or from the first time I heard the term cloud security. The Cloud Security Alliance and Chris Hoff and a bunch of folks at RSI were doing a meeting. And back then we found that cloud security is very sort of one dimensional. Right.

     

    Interviewee:                Mm-mmm.

     

    Interviewer:                And but what we see now is it’s infinite in its variety. There is so many different aspects to securing cloud.

     

    Interviewee:                Very much.

     

    Interviewer:                And it’s important. You know, I was on with I think it was the Palo Alto folks yesterday with their latest cloud, Native Survey. For the first time their respondents, and keep in mind when you’re a hammer everything looks like a nail, TJ. Right? So their respondents are probably people in Cloud Native, because it was a Cloud Native survey.

     

    Interviewee:                Right. Right.

     

    Interviewer:                But they said 50 percent of their infrastructure – at least 50 percent was in the cloud.

     

    Interviewee:                Yeah.

     

    Interviewer:                That’s a big threshold.

     

    Interviewee:                It is a big, yeah.

     

    Interviewer:                Right. When you say okay, half of organizations’ infrastructure is in the cloud today, well cloud security really damn important then.

     

    Interviewee:                Yeah, it is very important. Yeah.

     

    Interviewer:                Yeah, and so it’s part, you know, there is reasons for it to be complicated. This acquisition is a little different than o9 or yours.

     

    Interviewee:                Yeah, it is.

     

    Interviewer:                Why is it different?

     

    Interviewee:                Yeah, so the biggest difference I say is the user, and one of the things that we found out over the last two, three years is there is a few trends that are coming down together. One of them is the shift left turn, which is very clear. That shift left is more of a security initiative. Right.

     

    A security initiative that says hey, if I can fix something, prevent vulnerabilities before they hit the ______ department I should do that. Okay. So now if you want to shift left then you are living – your tools are living inside the pipeline, the development pipeline, and they’re supposed to be suddenly used not by security people, but by developers or DevOps people.

     

    Interviewer:                Yeah, yeah, yeah.

     

    Interviewee:                So these suddenly developed tools that are supposed to be used by people first, not to insure that security is their first priority. That’s number one. Actually it’s probably not their first priority. Even if they care it’s not their first priority. Then number two they just are totally used to different environments.

     

    And you find out that the security company definitely like Check Point that’s been doing security for 30 years and yourself and myself who are older than 10 years old as you can see, at least on my side, is that we know how to develop products for security people.

     

    And to develop  products – security products for developers and DevOps people is just a different genetics. It’s a different DNA.

     

    Interviewer:                No, that it’s a different animal, man.

     

    Interviewee:                It’s a different animal. So we were looking at that and said okay, so one, we think that developer first cloud security is a real thing. I mean it’s very important and it’s going to be a very big part exactly to your point there, of the future of cloud security.

     

    So there is always going to be cloud security – security for security people, which is their own time environment, checking out their actual cloud infrastructure. Making sure that the facts are being blocked and all that good stuff. But when you are talking about developer first cloud security you’re going to have a different type of user. You’re going to need to integrate into different types of tool sets. You need to have different types of genetics.

     

    So that’s what you wanted to sell to Spectral is exactly that. So these guys, you know, I met them first time and I said literally I had a, you know, probably a moment where I said okay, that’s it. These guys just get it. They’ve built a product that developers love. They built a product that developers understand how to use.

     

    Just like the one of their customers told me. They said, you know, I ask him why do you like Spectral compared to the other alternatives like Sneak and maybe a couple of others? And he literally said with Spectral the first time I take the connect to this thing first it took me five minutes.

     

    The second thing, I started to use it, everything was exactly where I expected it to be. And he actually used the metaphor in iPhone, and I totally related to that. Where with IOS everything is you don’t know why, but everything is exactly where you want it to be. You don’t need to think.

     

    So they nailed down the developer experience, and it’s not just the user experience and they integrate with tens of tools right out of the gate. They integrate into the IT environment. It’s also one of the things that we as security people who develop products for security people take for granted that you cannot take for granted in developer world.

     

    I’ll give you just a very simple example. Because we assume we’re selling to security people we assume that they’re going to be okay with us screwing up once in a while. For example, false positives. Something will take a bit more time. It’s okay, because they’re security. That’s their job. I mean they don’t have anything else to do except waiting for you to do your job.

     

    When you are talking with developers and you are going to scan code for example, which is what Spectral does. They started the first was scanning for secrets, hard coded secrets inside code, whether it’s in the I keys and W S keys, fast ______, huge problem. I mean developers who aren’t really fast, they forget keys and secrets inside code. They find an attacker that’s easiest way in.

     

    So now you have tens of repos, hundreds of repos. _______ repositories, S stream buckets, so secrets can be everywhere. If I’m a developer and I’m pushing code and I’m waiting for you to scan, and it’s going to take two minutes I’m going crazy over it. Two minutes I’m going crazy. Five minutes I’m killing someone. Ten minutes I’m out of this.

     

    Interviewer:                I’m not doing it.

     

    Interviewee:                And finding a way to go around this.

     

    Interviewer:                Yeah, yeah, I’m not doing it no more. Yeah.

     

    Interviewer:                So this Spectral technology, that was really their core tech, which is really interesting. So they, it’s like keeping it really, really simple. They have the ability to scan huge amounts of code for problems. Now a problem can be secrets. A problem can be mis-configurations in infrastructure as code templates like _______ can be a bunch of missed spaces, but they can do that really fast.

     

    Literally we scan, when we do the due diligence we scan their entire – our entire repo, the checkpoint repo in seven seconds.

     

    Interviewer:                Wow.

     

    Interviewee:                The entire repo, 30 years worth of repo.

     

    Interviewer:                Oh shit. Oh.

     

    Interviewee:                Seven seconds.

     

    Interviewer:                Holy mackerel.

     

    Interviewee:                I know it’s an oh shit. I had an oh shit moment also. It’s so, and it’s not like that. And they were saying okay, something here is happening. Now and it was also super accurate and they found very interesting things.

     

    So once they nail down the user experience or the developer experience you understand how they work and integrated the tools. Then you solve a real, real problem, because that is a real problem and you solve it really fast. That’s why we totally like them.

     

    So we really looking at them and just to make it even more interesting to the point that we started with how different of a DNA it is. Because it’s such a different DNA we’re acting inside my unit, inside the cloud security unit we are leaving them independent. We are not touching them.

     

    I don’t want them to start talking security to security people. You guys get the developers. You understand how they work. You go,  you do you. Just keep on doing that thing. I don’t want to dirty them.

     

    Interviewer:                I got to tell you, I’m sitting here, you know the word kvelling? Have you ever heard that word in your life?

     

    Interviewee:                Yeah, I – yea.

     

    Interviewer:                Because so I started devopsy.kinsta.cloud in 2013. Right. And RSA I think 20, maybe it was 2015 RSA. I started what we call the DevSecOps Event within RSA. It was Monday of RSA week. Right.

     

    Interviewee:                Right.

     

    Interviewer:                And the idea behind it was to bring the security, the cyber whatever you want to call it, the security community together with the DevOps try with the developers. And I got to tell you the aggravation I had, you know, eight years ago. Security people, they don’t care about security, they’ll never care about security.

     

    Interviewee:                Exactly. Yeah.

     

    Interviewer:                They’re stupid. They’re this.

     

    Interviewee:                They’re the enemy. Yeah.

     

    Interviewer:                Right. And you know what the developers are. All they do is say no, they slow us down. They are a pain in the ass.

     

    Interviewee:                Exactly. Totally.

     

    Interviewer:                It was like this. It took me seven years of build, because I believed – I believed that no, security may never be their number one priority, but no developer I ever met raises their hand and says I want to develop in secure code.

     

    Interviewee:                They don’t care, no. Right. No.

     

    Interviewer:                I like crappy quality. I’m a crappy quality developer. You know what I mean? No one says that.

     

    Interviewee:                Right. Right.

     

    Interviewer:                They all, they have pride in what they do.

     

    Interviewee:                Yes, exactly.

     

    Interviewer:                The problem was, is we weren’t giving them tools that they could use.

     

    Interviewee:                Yeah.

     

    Interviewer:                They’re not CISSPs. They’re not ______ or scanning _______.

     

    Interviewee:                No, no, there were security incidents and try to do for _______.

     

    Interviewer:                No, they’re not compliance experts.

     

    Interviewee:                Yeah, exactly. You found the problem, tell me how to fix it. Be very specific. Don’t tell me how to fix it –

     

    Interviewer:                Don’t fix it because I want the quality. I want the quality. Yeah.

     

    Interviewee:                Exactly. And I think you are touching now on a very interesting point, because when you start to bundle these things or unwrap it actually let’s say, one is you’re right, it’s a new user so we talk about it. I actually think that security people today, and I can tell you now product group, that’s exactly how we think.

     

    We think about the developer and the DevOps guy and the ______ guy as a new type of user. He is a user to the security side. I need to think, I need to cater to his needs. Now what does he need? To your point earlier, he is not going to read forensic reports. He is not going to read the tax batchers. That is not his job.

     

    His job is to write quality code that is not vulnerable as much as possible. Now if you find the problem in what he does tell him how to fix it and tell him in his language. In his language. His language is not a dashboard with a search. It is not his language. It is not just a piece of code telling that piece of code is problematic. If you replace it with that piece of code you are good to go.

     

    Interviewer:                Done.

     

    Interviewee:                It’s such a different mindset. It’s like you all are security people. You’ve been around, I’ve been around. We immediately show dashboards and must moves. Who cares? The Spectral ops guys where they showed us a demo and it’s like your heart attack for any normal security person, because what do they show? A CLI.

     

    Interviewer:                Yeah.

     

    Interviewee:                They open the CLI. It’s like everything black screen CLI. Anyone from a security will say I don’t understand what they are doing, but their customers, that’s exactly what they appreciate. To integrate immediately. You are talking with the ex, that everything is API first.

     

    Yeah, there is a report somewhere that you can see in the background if you need, but everything works inside the development environment.

     

    Interviewer:                But this also goes TJ, and we’re probably over time. I apologize.

     

    Interviewee:                That is okay.

     

    Interviewer:                But this also goes that we need to redefine the relationship between the security team and the DevOps developers and the people who use this kind of tool, because what happens is look, it’s going to be the developer. Maybe the DevOps or the SRE, but it’s going to be those people who are instituting the changes to close down a vulnerability or fix something.

     

    Interviewee:                Right.

     

    Interviewer:                That doesn’t absolve the security team of responsibility. No one is saying hey security team, you’re out of a job. Or hey security team, you don’t got to worry about it anymore.

     

    Interviewee:                ______ no.

     

    Interviewer:                The security team still needs that report.

     

    Interviewee:                Exactly.

     

    Interviewer:                That forensics trail if you will, to say hey, yes this was found, this was fixed and this is how it was fixed. And that again is yet another kind of special talent to make a tool that’s easy enough or is in the DNA of the developer, but still gives the security team, the compliance team what they need to sleep well at night.

     

    Interviewee:                That’s why one of the best sentences I like and we used it also when we announced the acquisition is would invent it, people use it before, it’s security tools that developers love and security people trust. That’s the theme. Right. That is so true.

     

    Interviewer:                I may steal that from you.

     

    Interviewee:                Steal it, _______ it. It’s like ten cents a use, and I know it’s in the –

     

    Interviewer:                Okay. We’ll put you down. We’ll put you down. No, but it’s true.

     

    Interviewee:                That’s what you want. Right. That’s really where you want, because and you just described the part that what does it mean for me as a security person to trust the tool that you’re using, and to trust the work that you are doing with it. And I think it’s a very different – it’s very interesting.

     

    I’m thinking the future by the Allan, and I think you are sitting with devopsy.kinsta.cloud, just right on the money. Because the future of security looks like this. You’re going to have security people. They are going to more and more, that’s where it’s going to go. It’s not tomorrow, but that’s where it’s going to go.

     

    The traditional security people I call it the sandwich model. The traditional security people is going to be at the beginning in defining what is secure, or what does it mean to be? Is going to be at the end validating that security actually happened. The sandwich in the middle is going to be more than ever what in the future, more than today by far developers. It’s going to be cool.

     

    Security is code. Computer security people are going to define what’s needed. They are going to make sure that they are going to validate that it happened. These people in the middle are going to be more and more code people.

     

    Interviewer:                People who make it happen.

     

    Interviewee:                Code people. That’s the new security engineer. The new security engineer knows how to code. And that’s why we acquired Spectral and that’s why we are going to let them lead our developer first spot security initiatives, and we’re super excited about it.

     

    Interviewer:                I’m excited for you, and I’m glad to see Check Point coming out with this. It’s great. Hey, for people who want to get information on Spectral where do they go?

     

    Interviewer:                ______.com website. You are going to find immediately on the homepage a link to the information around the acquisition and you can also go and check out spectralops.io, the website of the company.

     

    Interviewer:                I love it. TJ, man thanks for coming on and talking with us.

     

    Interviewee:                You are welcome.

     

    Interviewer:                It was a great acquisition. We’re going to be watching others go. I think a smart move by Check Point. Hey, we’re going to take a break here on Techstrong TV. We’ll be right back with some more interviews and news and information. TJ, thanks very much.

     

    Interviewee:                Thank you very much. Thanks.

     

    [End of Audio]  

  • Who Controls Your Build Process?

    Who Controls Your Build Process?

    We have come a long way in a short time in IT, and are currently in a ‘digestive’ state, where we take a bit of a break and prepare for the next wave of changes. Okay, not really a break, just a change in what we’re looking at.

    In the old days, CPU, memory speed, network throughput and disk access times would be in constant flux; one would be the server performance bottleneck and, when that was resolved, another would be the bottleneck. We’re in that kind of relationship right now. The majority of organizations are now using DevOps and our focus is currently on DevSecOps along with multi-cloud. Along the way, by unwritten consent, vendors have started calling Kubernetes “cloud.” This is totally amusing to me as a pundit, because Kubernetes is really a “cloud killer.”

    All public clouds are based upon the premise that they will have massive lock-in. And Kubernetes breaks that premise—unless an organization uses a cloud vendor’s customized version of Kubernetes; then they have other issues. No, I’m not blind, I am well aware that there are other reasons that cloud lock-in occurs, but there is a difference between “We chose this bit of custom functionality, well aware it locked us into our chosen vendor,” and “The act of using this vendor locks us in.” Multi-cloud and repatriation are things that would not be popular enough to talk about if not for tools like Kubernetes.

    So the next bit, IMO, is that once cloud portability is an established fact at most organizations, we’ll circle back to another iteration of build management. Many organizations are still on CI/CD iteration 1.0 and using Jenkins to manage their build process. While companies like GitLab and Atlassian have taken a bite out of the Jenkins-as-build-management phenomenon, they are also solid lock-ins through value add, and both of these vendors (plus most others in wave 2.0 of DevOps-centric build management) are heavily invested in the cloud. While the ability to build in the cloud is a very good thing, the requirement that a tool which is central to your toolchain be run from the cloud is not.

    That means we’ll be circling back to visit this issue again. And probably sooner rather than later. There is no denying that budgets are going to decrease for the bulk of us in the coming months, and I have no idea when they’ll rebound. That means that recurring expenses—like mandatory monthly subscription fees—will take a hit in B2B the same as they are in B2C. Don’t shy away from those assessments. Actually look objectively at your monthly payment plans and determine the ROI of each subscription your organization uses. Years ago, organizations centralized and reduced the number of development tool subscriptions they managed; this is just a continuation of that process in modern times. Spend your organization’s money where it will reap the most rewards instead of “where we always have.”

    You also want to make sure that you trust the company in charge of your builds, and that you believe they are stable. Over the years, we’ve seen several examples of companies that appeared stable when they were not; actually making the assessment is important.

    You’re building and maintaining the systems that keep the organization online and productive. Don’t hesitate to cut the fat. And don’t hesitate to maintain control. If the tool and its lock-in are forcing the org to work in ways that don’t fit the culture, look at alternatives.

    In short: Keep your options open. We know that money will be tighter in the near future, so let’s be sure we’re set up for that and retaining control of our build process. And keep rocking it.

  • Three Key Steps To Going Multi-Cloud

    Three Key Steps To Going Multi-Cloud

    Are you considering a multi-cloud strategy for your organization? Getting this sequence of foundational steps right can make a huge difference, both economically and performance-wise. FinOps or a cloud resource optimization solution like Archera, for example, is often brought into the picture after a company has already embarked on a multi-cloud approach and is knee-deep in long-term commitments. These solutions can help organizations avoid—or get further entangled in—problematic costs and contracts. We recommend a three-step approach for organizations that are going multi-cloud. The sequence of steps is:

    Cloud zoning policy: Determine which applications, teams and projects go where—and which cloud they will reside in.

    Architecture: Draw up the blueprint for your multi-cloud infrastructure. This specifies how applications run within a cloud and/or across clouds, particularly focusing on which applications need to be portable between clouds and cannot use vendor-specific services like AWS Lambda.

    Pay for it: Typically this is called the “contracts and commitments” phase, but we strongly encourage putting off decisions on contracts until you have created an overall plan, started to roll out and forecast usage so you understand the overall financial requirements for each platform.

    Step One: Cloud Zoning

    First, is cloud zoning. Your cloud zoning choices will have a major impact on commitments and costs. You need to map out what applications and processes will run on each provider. That entails deciding what can be locked into a single cloud, what needs to be portable between clouds and what applications need to be fully multi-cloud.

    Cloud zoning policy would cover, for example, whether you keep analytics and web serving on separate cloud providers.

    This also involves identifying your special focus areas. For example, if you want to ensure constant uptime even in the rare instances that AWS goes down, you might concentrate to extremes on load balancing among multiple clouds.

    If global availability is absolutely paramount to your business, you would set cloud zoning policies to support that imperative.

    Do not overlook the possibility that different teams need to use different best-in-class tools that may be specific to a provider; for example, an AI team that needs GCP TPUs.

    Step Two: Architect Your Multi-Cloud

    The high-level design and knowing what goes where are the crucial foundations for multi-cloud implementations. Forecasting is an art that comes into play here because you will need to forecast how your utilization of different services will grow.

    Hopefully, you will know how it’ll grow. Where do data science and AI go? Where is production application serving? Where is data warehousing? How will they grow relative to each other?

    The architecture phase is where you determine projects that need to be cloud-agnostic, and which don’t need to be portable and therefore can lean on proprietary CSP managed services.

    In general, in the long term, we see it is cost-advantageous for companies to take a flexible and containerized approach that can work with any infrastructure-as-a-service provider, or build with common standards if using managed services, such as using EKS for orchestration. This ensures not only portability between vendors’ common compute hosting solutions, but also portability within individual vendors’ managed service ecosystems, allowing customers to find an optimal fit for the application needs. For example, a containerized application can run on EC2, Lambda, ECS and a number of other options within AWS alone.

    Forecasting comes into play for specific parameters, including invocations of lambdas, the data storage your computing will need, the number of compute nodes and database utilization.

    Step Three: Financial—Contracts and Billing

    Forecasting continues to be important as you move into the selection of services and preparing for contracts. You need a clear understanding of your flexibility needs as the infrastructure you are consuming changes over time, both today and up to three years out. Then comes the process of matching costs to each forecast to build your cloud consumption budget,

    By studying your forecasts and the amount of uncertainty associated with each of them, you can begin to optimize commitment plans to zero-in on the best blend of contracts to cover the expected future usage.

    Throughout this challenging phase, look for ways to mitigate the risk of the commitments you’ll make. One way to do this is via commitment buy-back guarantees or by taking advantage of more natively flexible commitment options from AWS—such as compute savings plans, which can be consumed by any AWS compute usage in any region—in exchange for much lower savings rates.

    You can avoid confusion and lost time with careful budgeting and accounting. Make sure that commitment costs and savings are attributed specifically to the right applications, not spread like peanut butter across everything, which is often the default (unfortunately).

    Finally, when planning migrations of applications between vendors, interpret carefully between the big three and other providers. The performance semantics of a virtual machine at vendor X usually means something different than a VM at cloud provider Y, even if they appear to have the same specs.

    Going Multi-Cloud: Real Perspective

    In real-life multi-cloud computing where services are billed by the second, it is almost impossible to achieve 100% optimization of costs, commitments and performance. With manual approaches, very few organizations can expect to come close. Some companies do a very good job with attribution and tagging but do not accurately compare the hundreds or thousands of options between the big three providers to understand the optimal strategy.

    It can be extremely challenging, and it’s useful to understand the perspective of Amazon, Microsoft and Google. They respond first and primarily to the technical needs of their customers and often put off servicing their other wants (contracts, cost, transparency). For example, they make VMs spin up faster, but cannot make them less costly.

    Your challenge with going multi-cloud is much greater because you confront complexity by design, which makes optimization grounded in simplifying processes and automating as much as possible indispensable. Optimizing your multi-cloud smorgasbord requires involvement on your part, as well as external, neutral partners that exist to help the hundreds of thousands of organizations that consume cloud services.

  • Myth Busting: 5 Misconceptions About FinOps

    Myth Busting: 5 Misconceptions About FinOps

    Over the years, moves to the cloud have happened in several different ways and at various speeds. The reality is that today most enterprises are spending massive amounts on their cloud environments, and many teams are struggling to contend with the governance implications of this reality.

    Fundamentally, teams struggle with an either-or proposition: Either they give development and engineering teams free rein in terms of how they use cloud models, and, in the process, they leave the business exposed to a wide range of risks or they try to enforce central controls and restrictions on cloud usage and, in the process, stifle speed, flexibility and innovation.

    FinOps is a Necessary Discipline

    Teams are struggling with cloud governance in general, and one particularly vexing aspect of governance relates to cloud cost management. Quite simply, the procurement models and approaches that worked in the days of on-premises data centers simply don’t cut it today. At all.

    For these reasons, FinOps is emerging as a necessary discipline. At its root, FinOps is about establishing the people, process, and technology for establishing financial accountability in pay-as-you-go cloud environments.

    Here’s how the FinOps Foundation defines it:

    “FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.”

    Recently, I started preparing for the FinOps certification, and in the process, I have had the chance to talk with quite a few practitioners. Along the way, I’ve heard several misconceptions about the discipline. I’ll list and dispel a few of the most common myths in the following sections.

    Myth: FinOps is a Buzzword, not a Discipline
    While the term may still be new to some, the need for FinOps is clear, real, and not going anywhere. Consider that in a survey of more than 800 professionals, the FinOps Foundation found FinOps team sizes grew 75% in the last 12 months, and respondents are expecting 50% more growth in the next year. Today, the FinOps Foundation has more than 5,300 members. Further, on any given day, a search on career sites for roles specifically referencing FinOps will typically yield hundreds of opportunities.

    Myth: The Sole Goal of FinOps is Saving Money
    More than just tracking and controlling spending, FinOps offers a way to optimize spending, so each dollar invested ultimately yields the most business value. Rather than simply helping save money, FinOps is about making money.
    FinOps teams should advocate and lead with value-based discussions rather than focusing on cost. For example, if additional spending on a certain cloud service increases marginal value, FinOps teams help justify that additional investment.
    FinOps helps teams reduce wasted spending, but it also enables teams to invest more in services that allow the business to innovate, adapt, and scale. Ultimately, it offers teams a way to capitalize more fully on the advantages of cloud pricing models.

    Myth: FinOps Teams are Responsible for FinOps
    To be successful, organizations need to build a central FinOps team. These teams establish guidelines and best practices and facilitate unified reporting and visibility. However, FinOps doesn’t start and end with a single team.

    Those that succeed with FinOps are the ones that effectively break down silos. Individuals from leadership, finance, operations, development, and more all have a role to play. In a FinOps-driven organization, a range of teams collaborate, and in the process, they all benefit. For example, development teams can innovate more quickly and make more intelligent, data-driven decisions around balancing speed, quality, and cost.

    Through FinOps, everyone takes ownership of cloud usage. Cross-functional teams work together to establish more effective management of cloud vendors and rates. Ultimately, rather than creating conflict, friction is reduced. The end goal is to establish alignment around business objectives.

    Myth: FinOps Teams Stifle Innovation

    With traditional procurement models, central teams retained visibility and control over expenditures. While this would add layers of time and effort to purchases, this was accepted as a worthwhile tradeoff.

    Part of the reason for FinOps has come into existence is that it enables teams to break away from the rigid, centrally controlled procurement models that used to be the norm.

    Rather than having a finance team that acts as a central gatekeeper and bottleneck, FinOps enables teams to fully leverage opportunities available for automation in the cloud. Compared to rigid, monthly, or quarterly budget cycles—and being blindsided by cost overruns long after the fact—teams move to continuous optimization.

    Real-time reporting and just-in-time processes are two of the core principles of FinOps. Fundamentally, FinOps is about removing obstacles, and the focus is on enabling development teams to speed up their ability to deliver new features and capabilities.

    In the cloud, the reality is that teams can spin up a cloud resource with the click of a mouse. FinOps is about bringing real-time visibility to teams so, along with this instant access, there can also be informed decision making and ultimately accountability—all while fostering agility.

    Myth: FinOps is Only for the Largest Enterprises With the Biggest Cloud Budgets

    Clearly, the larger the business’ cloud investments, the larger the stakes. In addition, the larger investments, the bigger the problems that silos between technology, finance, and procurement can create.

    The goal for FinOps is to establish the people, processes, and technologies that enable more intelligent decisions about cloud investments. Ultimately, FinOps enables teams to ensure that each dollar spent in the cloud is delivering the most business value. Given that context, it is clear FinOps is invaluable for any organization making investments in cloud services. This is particularly true as organizations become more reliant on more cloud vendors and service types and more internal teams begin to access services.

    Establishing a strong FinOps practice can support growth in cloud investments while equipping teams to ensure better those bigger investments will yield maximum business value.

    In my experience, it seems that most organizations take on the creation of a FinOps practice after encountering significant issues, such as massive cost overruns or major snafus that impede operations. It is far better to make this move proactively before issues and obstacles arise. Further, the sooner the move is made, the sooner the business benefits.

    Conclusion

    As organizations’ investments in cloud services continue to grow, FinOps is becoming an increasingly vital discipline. FinOps offers teams a way to make more informed cloud investments and ultimately ensure those investments yield maximum business value. Consequently, FinOps represents a key aspect of cloud governance, which also requires teams to ensure security, compliance, and operational policies are constantly adhered to.

  • Resolving CI/CD Permissions Issues to Address Delivery Needs

    Resolving CI/CD Permissions Issues to Address Delivery Needs

    Security concerns and DevOps process issues can stall CI/CD operations. DevOps teams are familiar with the frustrations plaguing their pipelines, whether regulatory or process-based. Operational hurdles are all too common in DevOps pipelines, leading to miscommunication between team members and the broader organization. One of the leading operational issues DevOps teams encounter is permission issues. Permission issues are a seemingly small yet significant roadblock to smooth CI/CD pipelines. Fail to address them and the result is a lack of cohesion between development and organizational objectives.

    Here’s how to streamline these processes, boost security integration within the broader CI/CD framework, and maintain robust security postures.

    Review Pipeline Tools for Permissions and Access

    The DevOps life cycle often contains multiple tools, all with different access needs and permissions. As such, this situation is a security nightmare. Jeremy Hess, head of DevRel at secrets management platform Akeyless, called this a “secrets sprawl.”

    “The combination of proliferation and decentralization of secrets creates an operational burden, if not a nightmare,” he said. “For organizations that operate in both a cloud-native environment and classic IT infrastructure, a duplication issue is created due to having their own secrets managed with different tools and cloud-native solutions.”

    There is also the risk of these tools exposing user credentials and permissions to malicious actors. For instance, configuration tools like Jenkins use plugins to determine access and artifact deployment. Because these tools communicate with other pipeline tools, credential details can often be present in configuration details.

    Developer passwords are not visible on the frontend but could accessible from the system backend. Any user with ‘configure’ permissions could request any credential and then inject them into agents. The result is that AWS keys, Git credentials and/or passwords are at risk.

    To mitigate this issue, the first step involves deleting hard-coded secrets from CI/CD tool files. Distributing secrets between multiple tool configuration files also reduces the possibility of attack while easing developer and engineer access. Password managers are also a good choice, but validate them for security before implementing a solution.

    Practice Least-Privilege Access 

    Access and permission issues often create a lot of frustration among DevOps teams as they are forced to assign blanket access to the majority of users, regardless of members’ roles or job functions. While this situation encourages rapid development, it also creates massive security issues.

    Balancing security with CI/CD needs is tough to get right. That’s where the principle of least privilege comes in. Team members receive access to secrets on a need-to-know basis. Note that this principle applies to everything from apps to systems and connected devices.

    While most teams put this principle into practice, they make the mistake of leaving their process intact. The lack of access audits creates DevOps frustration, not the level of access. CISOs should regularly involve DevOps teams when reviewing access to mitigate issues quickly.

    For instance, embedding a security role within every delivery team will mitigate access-related risks quickly. The security team member will have insights into risk-based access needs and can quickly approve or reject requests.

    Creating an access management repository will also remove any confusion related to role-based access. In addition, record time-based and task-based access permissions in the repository. The result is every DevOps team member understands their access paths before projects get started. It allows them time to offer feedback and request one-off access to sensitive secrets.

    Review segmentation rules within your systems when assigning role-based access. Often, these rules will have to change depending on delivery timelines. Involving all stakeholders in these discussions is good practice and prevents frustration down the road.

    Implementing OTPs and other authentication factors is also a good idea when validating user access to secrets.

    Review OSS Projects

    Open source software (OSS) projects are essential to industry growth but might pose security risks if access is mismanaged. Zan Markan, developer advocate at CI platform CircleCI, summarizes the problem aptly.

    “Often, the company that initiated and that owns a popular OSS project continues to employ the core contributors,” he said. “They will probably be joined by other regular contributors and maintainers that are not part of that company. And then there is everyone else—anyone who occasionally might contribute a fix or a feature.”

    As user access grows, security concerns grow exponentially. Enforcing rigid user-based access is unrealistic and detrimental to an OSS project. However, CISOs or other security-focused managers must review whether sensitive secrets are being passed during builds for pull requests. Monitoring permissions—and who can place requests and roles that review them—will ensure a good level of security.

    Establishing machine identity is also critical, given the degree of non-human access pipelines face. Authentication can be based on verifying whether client runtime container attributes match the characteristics of the valid container. Once authenticated, role-based access can take over, limiting access to secrets.

    It’s also a good policy to destroy containers and VMs after they’ve been used.

    Streamlining DevOps Operations is a Top Security Priority

    DevOps is critical to every organization’s success. Access and permission-related issues are common occurrences, but are easily avoided. Reviewing access and establishing a balance between delivery and operational needs is essential to maintaining a competitive edge.

  • Four Steps to Avoiding a Cloud Cost Incident

    Four Steps to Avoiding a Cloud Cost Incident

    The recent Flexera 2022 State of the Cloud Report found that organizations waste 32% of their cloud spend, up from 3o% last year. This can be due to cloud cost incidents triggered by unused resources, malicious activity or overambitious projects and which have a massive financial impact if not found and corrected promptly.

    As an organization’s cloud infrastructure footprint matures, mapping cloud resource use and costs accurately to product lines, teams and business units becomes progressively more complicated and problematic. However, accurate cloud cost attribution is vital to understanding team resource use and determining accurate cost of goods sold (COGS) margins and is imperative to budgeting and forecasting. Organizations need reliable, granular views of the cloud environment to attribute costs back to departments and optimize a meaningful budget.

    Cloud cost spikes can blow up an organization’s budget fast and can be hard to track down, but enterprises can help protect themselves from a cloud cost incident with just a few simple steps.

    Have a Strong Tagging Strategy That Attributes Cost Granularly

    The cloud operations team needs to identify what is important to business reporting, which will help define and create a strategy for tagging. For instance, when an organization has two teams managing a particular service, the teams should safeguard the services tagged with a team identifier. Also, the teams should add another tag for the environment in which they’re running so they can allocate cloud costs across teams and environments.

    When an application uses numerous resources, like a database and storage, teams should consider adding a specific application tag and break down costs by each application. It should be noted that there is no one-size-fits-all tagging solution, so enterprises will need to determine what works and try out different strategies by adding and removing tags later.

    Understand Cloud Cost Ownership to Avoid Chaos

    Ask yourself how well your organization has attributed cloud costs to teams, applications or COGS. If the answer is “Not well,” then you are missing vital information about how your cloud costs relate to your business.

    The lack of this context or visibility into resource allocation makes it unmanageable and impossible for cloud operations owners and senior leaders to agree on who is responsible for varied expenses and resources. Manual cost attribution doesn’t scale accurately or account for shared cluster resource use across teams and applications. This creates confusion that can escalate when users arbitrarily slice data and claim ownership without accountability or clear visibility.

    What happens is that costs can sometimes be double-counted with two owners—or even missed completely with no owner whatsoever. The resulting data emerges as an inferior quality that is untrustworthy and not actionable. The inability to visualize resource use in context can dilute, hinder and even defeat cost improvement initiatives and optimization.

    Cloud costs should have an owner who can ensure that cloud spending is tied to business value. Understanding who owns which pieces will help pinpoint the cause.

    Establish and Monitor Cloud Budgets

    Historical data on cloud spending is gold—it can help forecast and budget for what should be happening with the cloud’s cost footprint. If that’s not happening, then it should be flagged and investigated.

    Once you get cost data under control, organizations can get an accurate picture of where cloud spending is taking place. However, does this match the expectations of spending? By establishing and monitoring budgets at every stage of a project, organizations can have guardrails to cloud spending and prevent costs from soaring out of control when engineers overallocate on performance “just in case.” Once budgets are in place, organizations can monitor spending and right-size resources to balance actual usage, rather than estimated usage at the start of execution.

    Over time, right-sizing resources will allow for optimal spend, as well as identify unused resources that can be shut down. Organizations should identify development and test instances left running when no longer needed and shut them off.

    Implement Cost Anomaly Detection

    Organizations can shield themselves from cost anomalies by continually monitoring and optimizing cloud costs. Cost anomaly detection can help act as a barrier to early recognition before they become problematic. This is especially effective when prompt, actionable alerts can be delivered directly to resource owners via Slack or email when their forecast exceeds the set budget. The best option would be adopting a cloud cost monitoring and optimization (CCMO) tool that gives alerts in real-time when a cost anomaly occurs. These tools must be able to detect anomalies and analyze their root cause, while also allowing visibility into what went wrong to avert similar future errors.

    Executing continuous cost monitoring and anomaly detection tools for dynamic cloud environments is essential in identifying any activity that doesn’t align with expected expenditure or diverges from an established pattern. With proper monitoring, organizations can take corrective measures before the fact.

    Unwanted and unexpected cost incidents can clean out an enterprise’s budget quickly, especially as its cloud infrastructure grows. Organizations need to practice these steps to gain a full picture view of their cloud environment.

  • How FinOps Can Optimize Cloud Costs and Drive Innovation

    How FinOps Can Optimize Cloud Costs and Drive Innovation

    Two mainstays drive most application migration and modernization initiatives. First, organizations are moving workloads to the cloud as an innovation catalyst. Achieving their strategic goals requires the speed, agility, reliability and advanced technical capabilities available to them in a hyperscale cloud.

    Second, they’re intent on ensuring the return on investment (ROI) through cost optimization, which is different from the abstract “cost savings” that was part of many early cloud pitches. It’s a recognition that attaining ambitious strategic goals depends on ruthless attention to the bottom line. Cloud enables the capabilities described above not just by making them available at the click of a button but via a finance and business model far more palatable to CFOs and boards than if the company were to build everything in their own data centers – including the data centers themselves.

    Cloud Usage Costs

    Therein lies a fundamental problem—and one of the major application modernization trends we’re seeing in 2022: Cost optimization in the cloud is far more challenging than many organizations first expect. And as cloud use bills balloon, the costs begin to undermine the benefits of migrating there in the first place.

    Identifying cost savings in the cloud isn’t really the problem. Doing so isn’t easy, per se, but there are various ways to go about it—such as changing a storage type, instance type, or retention policy, among many possibilities.

    Implementing those cost savings is the real issue. Companies know where and how to optimize utilization and spending but struggle for various reasons to make the changes needed to realize these gains. This challenge is why we’re seeing the growth of FinOps in 2022. FinOps is the culture and practice of creating visibility and accountability to manage cloud spend throughout an organization.

    FinOps responds to two significant problems that hinder cloud cost optimization measures.

    The first is conflicting incentives. The IT team or a consultant or managed services provider may identify opportunities for saving money in a company’s cloud bill, but that same IT team—the ones typically responsible for the “keyboard work” needed to implement the changes—may not truly own the application in question. Moreover, the business unit or team that does own the application may not, in fact, have any financial accountability for the infrastructure that powers that app. They don’t have any skin in the game and are often reluctant to approve changes especially if the app is meeting their performance goals.

    Second, many organizations migrate to the cloud only to realize they lack dependable visibility into how they are allocating costs in their new environment. A CFO or even CIO with a multi-million-dollar cloud spend may have very little visibility into who in their organization is spending that money—much less why they’re spending that money.

    These are significant issues that can spiral into runaway cloud bills—and ultimately suffocate the business value that the cloud was supposed to unlock in the first place.

    FinOps is to Dollars What DevOps is to Code

    Enter FinOps: FinOps is to dollars what DevOps is to code. It is essentially about driving awareness of cloud spending throughout a business, from C suite to a junior developer. In doing so, FinOps makes possible the kinds of cost optimizations required to attain the cloud’s transformative potential.

    Just as DevOps fosters values like shared responsibility and visibility (without playing the blame game) to sustainably increase development velocity, systems reliability, and other priorities, the FinOps framework brings a similar approach to cloud resource utilization. DevOps is ultimately concerned with that first mainstay cloud goal I described above: Achieving speed, agility, reliability, etc. FinOps focuses on the second mainstay: Cost optimization.

    In this way, FinOps is becoming a vital trend in application modernization because you cannot have innovation without cost optimization. (If you think otherwise, invite your CFO to lunch and see how they feel about it.)

    FinOps engenders cost optimization in various ways, but there are two key facets I’ll highlight here. The first is that FinOps culture and practices typically entail implementing “showbacks,” a system that clarifies who is using (read: spending) what in the cloud.

    Showbacks take some time to set up—they involve things like resource labeling and tagging and creating a reporting structure, for example—but are well worth it. They form the foundation of shared visibility into resource utilization and spending. With showbacks in place, you can see who is spending what and optimize accordingly. For example, you might discover a business unit that uses a high percentage of overall spend for a relatively low percentage of revenue. There might be a good reason for that, but you may have uncovered an opportunity to reduce spending if not.

    Chargebacks are the second phase, in which application owners, teams and business units – virtually any org structure can work here – become directly responsible (via their budget) for their cloud spending. With showbacks and chargebacks, you have visibility. You can also reduce or eliminate misaligned incentives since there is more granular control and responsibility for spending down to the engineering level if desired.

    It can even create healthy competition among cross-functional teams or the broader organization—who can decrease their spending the most, who has the best spend-to-income ratio, etc. At 2nd Watch, we use an “innovation score” model to assess cloud spending in a client’s organization, for example, that factors costs into the overall score.

    FinOps enables everyone to speak the same language, not just about cloud but about cloud spending.

    It’s worth noting that the showbacks and chargebacks aren’t new concepts at all. Yet we’re seeing growing interest in them in the industry—and a corresponding increase of tangible goals attached to implementing them, such as “implementation of showbacks and chargebacks by Q1 2023.”

    This is a reflection of the FinOps movement—and the fundamental necessity of optimizing cloud costs.

    You don’t have to call it FinOps, but you do have to address how you allocate and use your resources in the cloud. All of the cloud’s good stuff—the outsized benefits and business value it creates—depend on it.