devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Automation is Needed for Reliable Cloud Platforms

    Automation is Needed for Reliable Cloud Platforms

    From six to 1,400 microservices in less than five years? At first glance, that sounds like overwhelming complexity. Can you actually see the entire system across all of the microservices? This is the key to highly available and reliable SaaS cloud platforms. But what does this mean, and how can SaaS providers achieve it?

    Over the past decade, the cloud has become the virtual space where the majority of companies’ business processes and communications take place. Considering the accelerated digitization processes of the last year alone, cloud computing plays an increasingly crucial role when it comes to making distributed teams more productive. As a result of these developments, the number of applications, microservices and interfaces is increasing, creating a more complex IT infrastructure.

    The reliability and availability of cloud services must, therefore, be a high priority for providers. Weak services and downtime not only cause frustration among customers, but can also lead to considerable financial losses on the customer side. Accordingly, SaaS providers must establish processes and methods that help them provide secure and highly reliable cloud infrastructures, or risk losing their customers.

    Microservices as the Foundation for Reliability

    Complexity is implied with every SaaS cloud platform. This can be managed in two different ways. On one hand, management can be done via a centralized monolith. Through this, complexity arises from a single system with only one interface to external systems. On the other hand, complexity can be distributed via smaller system units in the form of microservices. This means that the various functions of an application or service are broken up and assigned to several individual instances that communicate with each other. The advantage of this is that if a microservice fails, the entire application is not necessarily affected.

    Microservices in cloud environments have been enjoying steadily growing popularity for some time now. In fact, 76% of the companies surveyed as part of a 2019 Forrester study stated that microservices will be high on the business agenda for many companies in the future. Only 4% disagreed with this statement at the time. In 2020, a TechRepublic survey found that the majority of experts surveyed (73%) have already integrated microservices into their application processes, and 66% of respondents use them in the form of cloud services. Microservices are everywhere!

    Service Level Objectives and Automation

    Due to the numerous interfaces that arise with microservices and the need to be monitored, this architecture appears, at first glance, to be more error-prone than traditional monolithic systems. Some companies already rely on service level objectives (SLOs) – i.e., targets and measurable KPIs to ensure service quality – for a higher level of security. However, these are often limited to the outer layer of the entire system.

    Formulating appropriate SLOs for each microservice with additional alerts can counteract this. In combination, these provide profound protection of the system against creeping errors.

    In order to maintain an accurate overview with regard to security and security-related incidents, and thus ensure the reliability of the system, the microservices and their respective SLOs must be closely monitored and continuously tested. When we surveyed software and IT professionals back in 2019, we found that 71% of respondents reported that microservices-based architectures are much easier to test than monoliths. And with the help of automation, operational teams can ensure that the overall reliability level is close to 100% in every single instance of the systems, no matter how complex. A separate, centralized automation tool monitors all microservices in use and is able to alert appropriate teams about any abnormal activity with respect to individual breached SLOs. In addition, this tool should be linked to an incident management platform so that any breach can be remediated directly. By following this framework, software developers will enjoy the benefits of a more manageable and scalable microservices system.

    We live in a time when consumers expect technology to be updated regularly and run reliably. If this is not the case, they will simply opt for better alternatives. To prevent this, companies need to invest in more effective service structures. Microservices, combined with a central platform that automates testing and management, is the foundation for achieving reliability and scalability.

  • The Importance of NetSecOps in Network Management

    The Importance of NetSecOps in Network Management

    The IT landscape has changed beyond recognition in the past decade or so. The vast majority of businesses now operate largely in the cloud, which has had a notable impact on their agility and productivity. A recent survey of 1,900 IT and security professionals found that 41% of organizations are running more of their workloads in public clouds when compared to just one quarter of respondents in 2019. Even businesses that were not digitally mature enough to take full advantage of the cloud will have dramatically altered their strategies in order to support remote working at scale during the COVID-19 pandemic.

    However, with cloud innovation so high on the boardroom agenda, security is often left lagging behind, creating a vulnerability gap that businesses can little afford in the current heightened risk landscape. The same survey found the leading concern about cloud adoption was network security (58%).

    Managing organizations’ networks and their security should go hand-in-hand, but, as reflected in the survey, there’s no clear ownership of public cloud security. Responsibility is scattered across SecOps, NOCs and DevOps, and these teams don’t consistently collaborate in a way that aligns with business interests. We know from experience that this siloed approach hurts security, so what should businesses do about it? How can they bridge the gap between NetOps and SecOps to keep their network assets secure and prevent missteps?

    Building a Case for NetSecOps

    Today’s digital infrastructure demands the collaboration – perhaps even the convergence – of NetOps and SecOps to achieve maximum security and productivity. While the majority of businesses do have open communication channels between the two departments, there is still a large proportion of network and security teams working in isolation. This creates unnecessary friction, which can be problematic for services-based businesses that are trying to deliver the best possible end user experience.

    The reality is that NetOps and SecOps share several commonalities. They are both responsible for critical aspects of a business and have to navigate constantly evolving environments, often under extremely restrictive conditions. Agility is particularly important for security teams to keep pace with emerging technologies, yet deployments are often stalled or abandoned at the implementation phase due to misconfigurations or poor execution. As enterprises continue to deploy software-defined networks and public cloud architecture, security has become even more important to the network team, which is why this convergence needs to happen sooner rather than later.

    We somehow need to insert the network security element into the NetOps pipeline and seamlessly make it just another step in the process. If we could automatically check whether network connectivity is already enabled as part of the pre-delivery testing phase, that could, at least, save us the heartache of deploying something that won’t work. And then, if we do need to open new ports, an automated process that could also raise a change request would save even more time. Better yet, if it’s one of those “make this like that” changes, the change could be automatically implemented on the firewalls – in minutes, not weeks.

    With NetSecOps, application developers can get creative without worrying about security slowing them down, and network security teams can sleep soundly, knowing that risk and compliance checks are built in to the continuous delivery process with a full audit trail, so they can even get time back to do some fun stuff.

    If we could do all this with only the rare cases of new connectivity requiring approval by security, the NetSecOps dream could become a reality, allowing fast, high-quality delivery. With NetOps and SecOps working together, organizations can establish a collective approach to network management and security, offering equal opportunity for both teams to present and prioritize issues and agree on the fundamental rules from the start; a match made in heaven.

  • Tiering Cold Data to the Cloud Without Tears

    Tiering Cold Data to the Cloud Without Tears

    The cloud provides inexpensive storage. But like everything else in the cloud, there are hidden costs. Cloud storage providers (CSPs) charge to put data into and retrieve data from the cloud. They charge for the API calls and they generally charge an egress cost when the data is extracted from the CSP. So, to keep enterprise storage costs low, infrequently accessed data such as snapshots, logs, backups and cold data are best suited for tiering to the cloud.

    By tiering data, on-premises storage arrays need to only keep hot data and the most recent logs and snapshots. Typically, 60% to 80% of enterprise data has not been accessed in over a year. By tiering the cold data as well as older log files and snapshots, the capacity of the storage array, mirrored storage array (if mirroring/replication is being used) and backup storage is reduced dramatically. This is why tiering cold data can reduce overall storage costs by as much as 70%.

    The many advantages of this approach include:

    • Lower acquisition cost. Flash storage, used for fast access to hot data, is expensive. By tiering off infrequently used data, you can purchase a much smaller amount of flash storage, thereby reducing acquisition costs.
    • Lower backup and mirroring costs. By continuously tiering cold data, you can reduce your footprint, license costs and storage costs for backups and replication if the cold data is placed in robust storage (such as that provided by the major CSPs).
    • Improve performance and lower capacity of your storage array. By running storage at a lower capacity and by moving access to cold data to another storage device or service, you can increase the performance of your storage array and get by with a smaller storage array.
    • Enable processing of cold data without burdening the storage array. Processing and feeding your cold data into your AI/ML/BI engines is critical to staying competitive. With cold data in the cloud, you’re also reducing the load on your storage array, thereby extending its life.

    Know First, Then Tier

    A key challenge of cloud tiering is determining what data to tier. End users should not have to decide which data to archive or handle the management of shared files. This issue may result in IT organizations keeping too much data in expensive, hot storage. One way around this is to automate the process through business policies dictating when and how the process is applied. It’s also helpful to provide transparency of the data by keeping it in the existing namespace. Users can still find the data and access it as if it had never been tiered. Transparency enables IT to tier cold data continuously and systemically across all storage devices in the entire organization without requiring end user assistance.

    To help IT make the right decisions, analytics is needed to see just how much data you have, and how much has not been touched in three, six or 12 months. It will be even more compelling if IT can run what-if scenarios to determine how much they will save with cloud tiering. The last thing you want to do is tier data in the dark. Take time to understand your data assets before you invest in the effort.

    Here are other considerations, beyond analytics, when embarking on a cloud tiering initiative:

    • Transparent, continuous tiering. Tiering should be transparent to the user. If someone can still search for and access data that’s tiered without any change to the experience, IT can realistically tier data systemically across the enterprise. Without transparent tiering, it’s an onerous process to tier data because you will need user permissions.
    • Flexible tiering policies. You need the flexibility to exclude certain data sets, include others and select from a large range of data ages. Be aware that many tiering solutions provide an extremely limited set of policies.
    • Tiering across multi-vendor storage arrays. Most enterprises have storage arrays from multiple vendors, and each appliance will have different tiering solutions if any. This makes it difficult to roll out a consistent, global tiering policy across the organization. Look for a solution which can encompass all the storage devices you have today and might acquire tomorrow.
    • Fast access to tiered data. Accessing data from the cloud will incur a much higher latency than accessing data on the local storage array. But once the cold data has been retrieved you can cache it locally to eliminate future latency and reduce egress costs. If the data set is large, the tiering solution should stream it so that users can access it even while the rest of it is being recalled.
    • Native cloud access to tiered data. The tiering solution should allow access to the cold data directly using the cloud storages native access tools. For instance, if you tier cold data to AWS S3, you should be able to access the data directly from AWS using a standard S3 browser like CloudBerry. Unfortunately, most storage array tiering devices store the data in a proprietary format, meaning that you can only access it from the source storage array.

    Cloud tiering is a practical and easy step on the path to the cloud. When done right, it gets you into the cloud while reducing storage costs. There are new solutions available that make this approach seamless with no disruption to users and your existing data protection workflows. By running an analysis of data assets across your storage ecosystem, and setting up policies for migration of cold data, you can ensure that data is always living in the best places from both a cost and business perspective.

  • Managing Cloud Security with Check Point Software

    Managing Cloud Security with Check Point Software

    Managing cloud security across multiple cloud providers, private cloud, AppSec and software as infrastructure, is highly complex.

    In this TechStrong TV episode, TJ Gonen, head of cloud security product line at Check Point Software, advises a security strategy that meets the challenges of cloud environments and cloud-native software architectures, and DevOps toolchains.

    Information about Check Point’s cloud offerings is available here.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by TJ Gonen, who is head of cloud security product line at Check Point Software. Welcome, T.J.

    TJ Gonen: Hey, thanks for having me, Mitch.

    Ashley: I love your name. A guitar player in a band in college was named TJ, a good friend of mine.

    Gonen: Oh, really? [Laughter]

    Ashley: So, it’s always nice when I come across another TJ. Well, hey, would you introduce yourself and, as we were joking before, for the two people who might not know, in the world, Check Point Software, tell us a little bit about Check Point.

    Gonen: Right, yeah, so TJ Gonen, and I joined Check Point actually about a year and a half ago from an acquisition of the company. I was one of the founders in the serverless security space, in the cloud security space, so I’ve been around Check Point for 18 months, about 18 months.

    Check Point has been around for a bit more than that, 27 years, one of the OGs of cyber security—literally invented the firewall. [Laughter] So, it sounds crazy, but that’s literally what happened and over the last 27 years or a bit more now, one of the largest individual or independent cyber security companies in the world, billions of dollars, traded on NASDAQ, 100,000 customers over the years, 60,000 active customers, enterprises, I think we secure literally everyone and provide solutions across the full gamut of cyber security with a lot of focus on cloud security over the last two, three years, just because that’s a topic. And that’s what I do for Check Point, I round the cloud security product line.

    Ashley: Excellent. Yeah, I was sharing with you the second firewall I implemented was a Check Point firewall back in the ‘90s, so it goes back a ways. You’ve been around—

    Gonen: It does, it does.

    Ashley: – tried and true solution, for sure. Well, we wanna talk about not just the old days of when maybe you or I started in security. You know, obviously, the environments of what we manage and have to deal with the threat, the attack surface, all of those things has become infinitely more complex, and it’s continuing to go that way, if that’s an accurate phrase.

    I’m sure one of the issues that you deal with is helping customers with how do they manage all of their security across, you know, multiple clouds, cloud providers, their applications, their on prem, stuff that they’re running, SaaS services—whatever it might be that anybody in the organization is touching, whether they’re inside a firewall or outside, right, especially with remote work. Tell us a little bit about that.

    Gonen: Right. Yeah, I think—I mean, because both you and I go a long way back, then we have the privilege, if it’s a privilege, to look at the generations. So, it’s interesting. I think, you know, we talked about Check Point inventing the firewall in ’93, ’94 when the Internet revolution started, and I think that differently, when you look at security before the Internet and you look at security since then, obviously, that changed dramatically. And I think that what we’re experiencing now with cloud is sort of that thing happening again. It’s another inflection point.

    Ashley: Mm-hmm.

    Gonen: And if you—and realistically, from the invention of the Internet and the ultra-connected world, most of what we had to deal with was, generally speaking, in the same domain. Yeah, more complex, more bandwidth, more stuff, more operating systems, but the blueprint—I think people figured out sort of the blueprint over the last 20-something years of what you are supposed to do after the Internet came across, right? Cloud, I think, restarts a lot of this discussion, and it’s not just the sheer notion of, yeah, your data center is somewhere else and your stuff is somewhere else—I think it’s just velocity and scale.

    I think the biggest struggle we hear from customers and prospects, and honestly, even if you own your own environment, is just, you think you figured it out and then a day after, it’s 10 times bigger, 50 times more people have access to it, and you lost control. It’s so easy to lose control. So, I think where we were, where we had, “Hey, you know what? Oh, you have a data center? Okay, let’s put the firewall, let’s put some segmentation, let’s put AV or whatever—okay, here’s the blueprint.” Now, we are in this place where, how many data centers do we have? One, day after it’s 50, and now, how do you know, even, what’s going on there?

    So, I think scale and speed has been the biggest problem, and I think cloud is a real revolution. It’s not incremental, it’s not another thing you need to deal with.

    Ashley: Mm-hmm.

    Gonen: It’s a thing you need to deal with, and it’s a big issue.

    Ashley: The evolution of, we move things to the cloud, but we do things the same way we did on prem.

    Gonen: Right, right—it’s not that.

    Ashley: Then there’s the next evolution of how do you do it within, truly within a cloud environment that matches that. I mean, I remember the days of just managing the rules and what were they all in there for and who put what in, and just—that was complex, you know, when you’re an enterprise, multi-location.

    Gonen: Yeah.

    Ashley: Talk about the management capabilities that you have to have in a cloud environment, multi-cloud environment.

    Gonen: Actually, you sort of touched on something that is a no-no in the cloud environment. You literally mentioned something that, like—hey, someone was sitting down and writing firewall rules and configuring who has access.

    Ashley: Mm-hmm.

    Gonen: Manual, right? There is just no way you can do anything manually in the cloud. I mean, think about this, Mitch. Everything that happened over the last 10 years in Dev and infrastructure has been focused on automating everything.

    Ashley: Mm-hmm.

    Gonen: Literally. We talk about CI/CD, and obviously, DevOps and now cloud, if you look at cloud—cloud totally automated infrastructure and then it totally automated application infrastructure and now it’s automating everything, no code and stuff like that.

    Ashley: Including infrastructure as software, right?

    Gonen: Yes, exactly.

    Ashley: Not all of them are in a stack.

    Gonen: Everything. So, everything has moved towards automation. So, if we are going to, let’s say, you can imagine saying someone is gonna configure something manually on security, by definition, we’ve failed. So, the biggest challenge that’s facing security is how do I automate security? Because it has to secure stuff that’s fully automated.

    So, I would say, you asked about management—the first thing I would say about management for cloud, it can’t be manual. If there is, we have a saying inside Check Point that we say in the CloudGuard team, it ain’t done ‘til it’s automated. Whatever you were working on, whatever capability feature security for, if it’s not automated, if you can’t automate it, you are not done, because by definition, you are gonna be left behind and something is gonna be open, because the rest of the stuff is automated.

    So, I think the biggest—and when we talk with a prospect and when I talk on the stage, even, I always say, “Listen, when you talk about your security blueprint for the future for the cloud, number one is automation. It’s not how secure it is, it’s how automated it is.” Because it doesn’t matter, you can have rocket science technology for security—if it’s not automated, you’re gonna miss half of your footprint, anyway. So, automation has—

    Ashley: Mm-hmm. [Cross talk] the same way twice, right?

    Gonen: Right, exactly. [Laughter]

    Ashley: Without the audit trail. Well, talk a little bit about, you know, there was sort of the orchestration phase, right?

    Gonen: Right, right.

    Ashley: What we thought of as automation now, you’re talking about the entire Dev and Ops process.

    Gonen: Yeah, right.

    Ashley: The infrastructure as code, applications, dynamic environments—you know, things are changing very quickly.

    Gonen: Right, right.

    Ashley: How does it differ today from maybe folks that remember orchestration as [Cross talk]?

    Gonen: Right, yeah. So, it is different, and I think in security—let’s talk from a security perspective, because I think that’s the angle that, definitely, we deal with today. We feel like there’s two pieces to automation that are critical in this world. I call it, I split it into the first one being the presence of security needs to be automated. We lost the luxury of someone telling us that it’s doing something so we can put security in place.

    Ashley: Mm-hmm.

    Gonen: That luxury is gone, so the presence of a security control or mechanism has to be there automatically. So, if someone—just to keep it really simple, if someone is deploying new container to the cloud, which happens a billion times a day, and I decided that that container needs to be secured, then whatever the security mechanism I chose for that container needs to be there automatically. The container is deployed, security is there. How? Magic. I don’t know, but the presence of security has to be automated.

    The second thing that has to be automated is the security configuration itself. Because, again, we lost the luxury of someone saying, “Hey, I deployed an application, how about you call someone to configure the web application firewall and fine tune it to the application?” or, “I changed the application, now someone needs to fine tune the rules.” What? Find new what? It’s gonna change in five seconds, again.

    So, two things have to be automated—the presence of security, and that really talks to DevOps and integrating into the infrastructure as code pieces, just like code is automated or the deployment process is automated, the presence of security and deploying serverless functions, security has to be there. I’m deploying a new VPC and I decided that I need a firewall at the entrance, it has to be there automatically. No manual, no human intervention. And the second piece is the actual configuration. So, if I decided—let’s follow that thought process—if I decided that I’m deploying a serverless function, a Lambda function with AWS, security needs to be there. The security needs to be there automatically, but also the profile of that security, the allow and block rules has to be there automatically and they need to auto adapt to changes.

    And I think that’s such a—this is such a different breed of security automation. This is not just orchestrating security into where it needs to be, and it needs to be in a billion places, it’s also the sheer notion of how do I keep things maintained and configured correctly. And that’s why I think a big change is the definition of who does security engineering.

    Ashley: Mm-hmm.

    Gonen: Like, you and I started a billion years ago—me a billion, maybe you half a billion.

    Ashley: I’m two billion, so.

    Gonen: Two billion? You’re two billion, okay, there you go. [Laughter] So, between us an average of one and a half billion years ago. A security engineer is the one that configured the Check Point firewall, right?

    Ashley: Mm-hmm.

    Gonen: And part of the process was, “Hey, open this port for me, close this port for me, what’s the”—that’s gone. The new engineering is, the new engineer is not only the DevOps guy and the DevSecOps guy, because everything is as code and security has to be as code. I would argue that the new security engineer is the machine itself. Because you have to eliminate, as much as possible, even the process of an intervention, even by a DevOps person.

    There is, the security just needs to find itself there and auto-configure itself. That’s where it needs to go, and that’s where we put in a lot of effort. That’s why I said it ain’t done ‘til it’s automated, because I can give you the best solution ever, but if I actually require you to know what’s going on, there is just no way. You can’t keep up. There’s not enough humans in the world to keep up with the change of what’s happening now in the cloud.

    Ashley: Let me ask you this, because something that I’ve believed for quite a while now is that we are always talking about educating developers about security and helping to write a more secure code.

    Gonen: Right, right.

    Ashley: But the opposite is true, too. Not that security engineers need to be software developers, but security engineers need to understand software architecture as more than a temporary cloud. You obviously know it, you’ve been using the language of containers and Kubernetes and software as code. It’s not that you need to—it isn’t the old way of let’s go to the security team and have them set this all up for us, which is the whole premise of what you’re talking about. That happens, that has to be built into the process, it has to be built into the environment.

    So, what is the role of the security engineer in that kind of a shift left, DevSecOps, that kind of an automated environment—what skills do they need to have today that they maybe didn’t need 5 or 10 years ago?

    Gonen: It’s so fascinating. I mean, this topic, I think that there’s—we’re in this real point in time where there is a new role, architecture, or let’s say hierarchy defined. Because I think you’re gonna find security people, just to your point, when you come to a CISO and you say, “Hey, can you tell me what’s happening in my Kubernetes environment inside Azure?” And the average CISO is gonna say, “I have no clue.” The Dev guys, they do whatever they want with this environment. My security guys know how to read dashboards. They don’t know how to read code.

    Ashley: More of a SecOps kind of—

    Gonen: More of a SecOps, yeah. And I think, then—and to your point, though, when you go to the develop and you say, “Hey, developer, what’s your security strategy?” and he says, “Dude, I’m a developer—what security strategy?” So, I think you’re right that there’s new roles being defined, and I think where the world is coming to is one that you’re gonna find more, like I mentioned a bit earlier, the SecOps and Sec engineering roles are gonna be more and more definitely, in the world of the cloud, people who can write scripts.

    Ashley: Mm-hmm.

    Gonen: I think that you come back in five years from now, you talk with a SecOps guy, and you say, “Hey, can you write item scripts, can you write bash process, do you understand how to connect to the AWS API?” and he says no, he’s gonna have a real problem managing engineering, security engineering in the new world.

    Now, so, I think where the world is gonna go is that you’re gonna have what today is traditional, security do policy, defining what needs to happen, and governance. So, these are the two ends of the spectrum. I’m gonna define what I expect to happen, which measures what do I test for, what do I scan for and so forth, and I’m gonna make sure that it’s being done. And then, inside that sandwich, inside that Oreo cookie, the piece in the middle is gonna be more of the developer people—DevOps, DevSecOps. Because they’re gonna be in charge of actually doing a lot of the security work, so if the policy says applications have to be segmented in the cloud, so the payment application has to be segmented, you know, separated from the CRM application. The security people are gonna say that. That’s the policy, because it’s PCI data or whatever.

    The people that are actually gonna implement segmentation are gonna be DevSecOps people or DevOps people, because the segmentation is done in Kubernetes, and the security guy doesn’t know how to write Kubernetes microsegmentation over Calico and CNI, and these are all buzzwords, he doesn’t even know what they mean. And there’s gonna be governance at the other end to say, “Okay, that was being done. That might be a dashboard or something like that.”

    Ashley: You know, there may be—we could spend a whole other conversation on this.

    Gonen: Oh, yeah, I’m sure. [Laughter]

    Ashley: There might be a nice parallel, the analogue to this was what’s happened on the Ops side, because SRE is big, right?

    Gonen: Right, yeah.

    Ashley: And those are people that know how to code and know how to write scripts, and maybe something like that is the emergence of the security engineer role is going to be as, “My job is to automate the security.”

    Gonen: Exactly.

    Ashley: “Work with the teams, whether it’s the tool pipeline or it’s the software Dev team, the infrastructure teams.”

    Gonen: Right, right.

    Ashley: And almost that kind of a role, I wonder if that might be where we’re headed.

    Gonen: It’s actually very much true, I think that you are heading in the right direction. The SRE was born exactly from that necessity—hey, I need an Operations guy, but I need him to be able to actually orchestrate stuff using code. And I think it’s exactly what’s gonna happen or is already happening to some extent, but it just doesn’t have a name yet, except DevSecOps, right? Like, maybe DevSecOps is the closest thing, which just doesn’t come down to an acronym—DSO, maybe, I don’t know. [Laughter]

    Ashley: Yeah, we need a new job title, I’m sure.

    Gonen: We need a new job title. [Laughter] But other than that, that’s exactly it. And really, I mean, in the cloud world—listen, if you’re a cloud native company and your data center and applications are cloud native, if you hire a security guy from 10 years ago, he’s gonna be lost.

    Ashley: Mm-hmm.

    Gonen: I mean, everything is code. He needs to be able to—

    Ashley: Plus, a lot of developers are moving into security that have an interest, right?

    Gonen: Yeah, right, yeah.

    Ashley: So, that may be the best way to acquire. Well, hey, we’re running out of time, T.J., and I look forward to having you back.

    Gonen: Yeah, sure.

    Ashley: I’d love to chat with you more, especially as we get into sort of the DevOps and the CI/CD pipeline and integrating security into that.

    Gonen: Yeah, I’d love to.

    Ashley: Who knew 27 years ago we’d be having this conversation—

    Gonen: [Laughter] There you go.

    Ashley: – with Check Point? So, things have certainly advanced. Where can folks find out more and check out your cloud offerings?

    Gonen: Yeah, so, CheckPoint.com, and it says in very large letters cloud. That’s where you can go and you can start a demo, you can read a lot of the white papers around these things. And actually, I think more than anything else, we were just talking about developers—experiment with it yourself. Developers, that’s what they like to do.

    Ashley: Mm-hmm, absolutely—write a little bit of code, see what it does.

    Gonen: [Laughter] Right.

    Ashley: TJ Gonen, great talking with you, Check Point Software. I look forward to chatting again. Take care.

    Gonen: Sounds good. Take care.

  • Despite Cloud Adoption, Enterprises Demand On-Premises Software

    Despite Cloud Adoption, Enterprises Demand On-Premises Software

    A recent report from Dimensional Research reveals that the demand for on-premises software is equal to that of public cloud. The report, which was commissioned by Replicated, a company specializing in on-premises software modernization, queried 405 participants in software development, executive, product management, sales and services roles to determine the needs, usage and challenges of on-premises software.

    The report revealed that some 90% of companies surveyed said their on-premises sales of software solutions continue to rise, while 70% that do not currently offer on-premises solutions intend to in the near future. 

    “In the past few years we’ve experienced a steady increase in interest from leading global companies who see that modern on-prem software delivery through containers and Kubernetes can make data protection and security much easier,” said Grant Miller, co-founder and CEO of Replicated. “Coupled with growing customer demand, it’s a win-win scenario for any industry.”

    While Miller’s view may be optimistic, the survey also revealed that the majority (65%) of companies cited privacy compliance as the top reason for using on-premises software delivery; an indication that the market is being influenced by cybersecurity issues more than any other factor. However, 54% also stated uptime and reliability were a primary driver for on-premises solutions, while 45% noted the importance of integration.

    The report indicates that enterprises, which have cited digital transformation and a movement towards the cloud as critical factors over the last two years, may also be thinking more about on-premises solutions in light of cybersecurity and compliance concerns. This, in turn, means that DevOps has the potential to gain even more traction in the enterprise. 

    While the report mentions the merits of an on-premises software strategy, it does raise the question of why more enterprises have not moved in that direction already. That hesitation to re-embrace on-premises software can mostly be attributed to perceived complexity, time commitments and the cost of engineering resources to make it happen. 

    Complexity is further highlighted by 74% of survey respondents reporting that it would take more than a week to install and configure on-premises software, and 29% stated an install could take over two months. For the 16% that claim they can rapidly install and configure on-premises software in less than a week, the potential for growth in the market is notable. 

    While the future remains somewhat uncertain, the report from Dimensional Research runs counter to other reports, such as a Synergy Research Group report that revealed in 2019, spending on cloud platforms edged past the resources spent on acquiring servers and software for on-premises data centers. “60% of the servers now being sold are going into cloud providers’ data centers and not those of enterprises,” said John Dinsdale, a chief analyst at Synergy Research Group, confirming the trend. “Clearly, companies have been voting with their wallets on what makes the most sense for them.”  Dinsdale said the growth of cloud infrastructure will continue to accelerate aggressively over the next five years. 

    Although conflicting observations tend to add to the market confusion, one thing is certain – DevOps shops have market opportunities to service customers deploying both to the cloud and on-premises software.

    on-premises

  • Cloud Governance Can Trim Cloud Costs

    Cloud Governance Can Trim Cloud Costs

    The abrupt need to transition to remote work last year caused many companies to migrate to the cloud or accelerate an in-process migration. Cloud has become an essential part of company operations and budgets. Last year, worldwide end user spending on public cloud services was $257.5 billion, making up 9.1% of total global enterprise IT spending, and it’s forecasted to increase to 14.2% by 2024, according to Gartner.

    Upfront Cloud Costs

    The allure of cloud for organizations is its potential to save money, increase agility and offer easier scalability. However, these promises don’t materialize without proper management. Organizations will likely see an initial rise in costs with cloud adoption. Organizations spend, on average, 12% more running a workload in IaaS (infrastructure-as-a-service) compared to when it happens in their own data center. These cost increases occur when work is lifted and shifted without modification.

    Like any change, there will be upfront costs involved with the process of migrating to the cloud that need to be considered. With careful planning, organizations can avoid surprises. Items that need to be factored in when budgeting include the cost of cloud infrastructure, labor costs associated with migrating applications to the cloud, and the monthly bill from cloud providers. Many cloud providers provide cost calculators to help organizations determine what to expect when migrating to the cloud.

    Managing Cost

    A factor that is key to managing cloud costs is planning for the monthly cloud bill. Without proper monitoring, this is where overspend can occur—57% of IT leaders have exceeded their cloud budgets at some point, according to a 2018 Softchoice survey. One of the issues is the lack of visibility that leaders have into their cloud costs. A lag in your cloud billing data makes it difficult to make accurate decisions, which can be the case with spend reports from cloud providers that are 12 to 24 hours old.

    A lack of timely visibility into current costs and the inability to forecast future costs leads to cost overruns and blown budgets, which is why having a product that provides the most up-to-date information and monitors your budget is important. There is no use in budgeting if it’s not being monitored. Let me repeat: an unmonitored budget is useless.

    Timely visibility and monitoring your budget fall under financial control of your cloud—one of the three pillars of cloud governance. Cloud governance includes the development and implementation of budget controls, as well as controls to manage access and ensure ongoing compliance.. A cloud management product can help with this by not only keeping your budget under control and alerting you before you go over that budget, but also by finding saving opportunities through ongoing optimization.

    Using these tools means you can automatically find out about ways to save your organization money.

    The other two pillars of cloud governance, managing access and ensuring compliance, also impact your overall cost in the cloud. A robust governance and management solution establishes proactive protocols that can automate tasks such as account setup and ensuring compliance with your security standards. Automating controls will save your organization time and money. Monitoring and ensuring that your cloud is secure will help you avoid costly security breaches. When adopting the cloud, a plan for implementing cloud governance should be at the forefront to help you realize the cost savings of cloud.

    Despite the initial costs of scaling to the cloud, in the long term, cloud adoption does result in cost savings. Once organizations move away from managing on-premises data centers and implement cloud governance in their cloud environment, that’s when opportunities for innovation can happen due to time and money being saved. For example, when Riso, a printer and digital copier manufacturer, migrated to AWS, the company cut its total IT operational costs by 55%. Avery Dennison, a manufacturing company that specializes in labeling, saw an annual run rate savings of $5 million due to investing in cloud-first initiatives. These are just some examples of how the cloud has helped companies optimize their costs. It can be possible for your organization to reap similar benefits with proper planning and the implementation of cloud governance.

  • Consider Telemetry When Rearchitecting Applications

    Consider Telemetry When Rearchitecting Applications

    Australia and New Zealand have seen a big move to the public cloud, and “… when I talk to customers, I see huge interest in rearchitecting applications rather than doing a lift-and-shift right into public cloud,” said Scott van Kalken, F5 ANZ solution architect for DevOps and modern applications.

    That migration to the public cloud has led to massive interest in telemetry. When you go from a monolithic application to a distributed app, there may be 100 or even 1,000 APIs involved. Without telemetry, you don’t know what’s going on with those APIs. But the telemetry needs to be consistent.

    F5’s 2021 State of Application Strategy report found 75% of respondents considered telemetry, especially about application security and delivery, important for meeting business outcomes, and 95% of respondents said they are missing insights from their existing monitoring and analytics solutions.

    Van Kalken recounted a conversation with a practitioner as an example. This practitioner gets yelled at when problems arise with partner APIs used by the application he manages. So, even though these APIs are not technically his responsibility, he needs visibility into their status. Only by combining internal telemetry with telemetry from these partner APIs can he make sense of what’s happening within the application ecosystem.

    And it’s not just a question of whether an API is available or not. Problems can arise when it is responding slowly. “‘Is that normal? Is that normal for this time of day?’ I’ve got to have some sort of telemetry data available to me to make decisions,” van Kalken said.

    Enabling Security Automation with Telemetry

    An aspect that’s particularly interesting to him is the ability to automate or otherwise take action based on security telemetry data.

    A simple example is a security event that reveals some kind of systems abuse. Automation can add a firewall rule to block the associated traffic.

    As organizations increasingly adopt event-driven architectures, events and responses occur at the application, network, infrastructure and other levels. “The minute that you automate those event-driven architectures with security, it opens up a world of possibilities.”

    It’s not just about automating security. Imagine an API gateway that serves a variety of APIs to customers. Telemetry might reveal that two of the APIs are starting to slow down; in which case, “I might kick off a workflow that just deploys more of them so that we can handle the load. But if you don’t have that telemetry, you can’t do that,” he said.

    In practice, this involves telemetry, analytics and automation.

    “When we show [customers] how you can make use of the analytics in a really easy way, their eyes light up,” van Kalken said.

    Multi-Cloud Migration

    A further consideration is that rearchitecting applications isn’t just about splitting monoliths into smaller pieces and redeploying them as microservices. There’s also a desire to run them across multiple public clouds to reduce risk, and also to deploy applications at the edge where they are closer to their users.

    The 2021 State of Application Strategy reported that just over three-quarters of respondents are already using or have plans to use the edge to capture benefits related to application deployment, performance and data availability.

    “This is really important, because as an application developer, I want to deploy my application once and I want to say, ‘I want this distributed to all of these places around the globe’,” van Kalken said.

    But if the application is deployed in, say, five locations, then from a telemetry perspective, it is five applications, not one.

    “I’ve got five sets of telemetry, because I’ve effectively got five different applications deployed out there. It’s the same app, but it’s in five locations, and the consumers are different in every location; the way that they interact is different and the telemetry that I’m getting is going to be different,” he said. “So, I need to actually suck up all of that telemetry, and make it meaningful in some way,” he explained.

    Telemetry Enables Clearer Vision

    “A distributed cloud architecture is right for these modern applications. We recently bought a company called Volterra, and this is one of the areas that they play in — distributed applications, and specifically, abstracting multi-cloud and multi-cluster Kubernetes application deployments,” he said. This area of focus will be critical in the future, van Kalken said.

    He predicts that as organizations move to 5G, applications will become increasingly distributed. If that does happen, it will be extremely important to receive telemetry from all components of the application so it can be analyzed and used to support intelligent decisions, as part of the distributed application deployment.

  • OpsRamp Extends AIOps Reach to Embrace Prometheus

    OpsRamp Extends AIOps Reach to Embrace Prometheus

    OpsRamp today announced it has added the ability to ingest data captured via the open source Prometheus monitoring software into its namesake IT operations platform infused with machine learning algorithms.

    In addition, the company is adding support for customizable dashboards using the Prometheus Query Language to create visualizations of hybrid infrastructure performance. Also, a set of available tools makes it easier for IT teams to discover when workloads have been added to a cloud. These capabilities became available with the Spring 2021 Release of OpsRamp’s IT operations platform infused with artificial intelligence (AIOps).

    Finally, OpsRamp has also created an alert definition model that streamlines the alerts generated by the AIOps platform and its integrations for the Microsoft Azure cloud and the Cisco HyperFlex platform deployed in on-premises IT environments.

    Deepak Jannu, senior director of product marketing for OpsRamp, said that as IT becomes more complex to manage, many IT teams are starting to realize that managing these environments without help from an AIOps platform won’t be possible. As such, much of the fear and loathing that was initially associated with AIOps is giving way to acceptance as IT teams start to realize these platforms augment their capabilities versus replace them, added Jannu.

    Much of the complexity is being driven by the rise of cloud-native, microservices-based applications that tend to have lots of dependencies. OpsRamp has primarily been encountering Prometheus in these environments. However, Prometheus can also collect data from legacy applications, as well, so over time, the expectation is the open source monitoring tool will be employed more widely.

    As AIOps platforms become more widely employed, there is no doubt job roles within IT organizations will change. As lower-level tasks become automated, IT teams should have more time to spend resolving complex issues once the AIOps platform has identified a baseline for how applications should optimally behave. In many cases, the need for personnel to perform rote tasks that no one in IT wants to actually do will be eliminated altogether.

    DevOps teams that are committed to automating IT tasks will naturally be among the first to employ an AIOps platform to augment the capabilities of site reliability engineers (SREs) that are often challenging to hire and retain.

    In general, Jannu noted that the observability that many IT organizations now demand can’t be achieved by simply collecting more metrics. IT organizations will need to invest in an AIOps platform capable of making sense of all the instrumentation data being collected. The challenge now will be defining the right division of labor between man and machine in an IT environment, Jannu added.

    At this juncture, AIOps, to one degree or another, is inevitable. In many cases, machine learning algorithms are already being employed to optimize applications or a specific class of hardware. The decision IT teams will ultimately need to make is determining whether to replace their existing IT operations platform or wait for the provider of their existing platform to get around to adding AI capabilities.

  • Survey Illuminates Long Dark Road to Hybrid Cloud

    Survey Illuminates Long Dark Road to Hybrid Cloud

    While hybrid cloud computing will play a critical role in enabling digital business transformation it turns out most IT organizations lack the skills and technologies required to achieve it.

    A survey of 108 IT executives conducted by the research firm Pulse on behalf of CloudBolt Software, a provider of a cloud management platform, finds 94% believe hybrid cloud computing will be critical to digital transformation. A total of 92% also noted that empowering end users through self-service IT is a digital transformation accelerator, while 99% said successful automation depends on streamlining integrations.

    However, 78% of respondents said they lack the visibility necessary to optimize cloud deployments. More than half (56%) believe that their self-service offerings fail to meet user needs and more than three-quarters (76%) still rely on some form of custom coding when it comes to integration.

    In terms of the capabilities respondents are looking to acquire, 80% noted they want real-time insight into cost optimization and security remediation. A total of 71% want self-service to be easy for end users, while 62% want an approach to integration that doesn’t require deep domain knowledge or special expertise.

    CloudBolt CEO Jeff Kukowski said the biggest immediate obstacle when it comes to hybrid cloud computing is the lack of visibility IT organizations have into their existing IT environments. IT teams are not going to be able to unify the management of distributed IT environments without it, much less achieve anything approach observability, noted Kukowski.

    Pressure on IT organizations to accelerate application development while simultaneously reducing costs rose as the economic downturn brought on by the COVID-19 pandemic began. The challenge is that each new platform adopted by an organization tends to increase the total cost of IT as organization acquire tools and hire specialists to manage those platforms. It’s not likely all those platforms will be managed via a single console, but Kukowski said it’s clear IT organizations are moving toward a more federated approach that will enable them to centralize the management of IT.

    In the meantime, Kukowski noted organization are collectively wasting billions of dollars on IT platforms that are employed inefficiently. Most of that waste stems from either overprovisioning of IT infrastructure, or simply because someone didn’t think to turn off a virtual machine left running on a cloud service.

    It may be a while before IT organizations are able to strike that perfect balance between flexibility and control that currently remains elusive. However, organizations that focus on improving a few small things today will find themselves in a much better position to manage what is rapidly becoming an over extended enterprise tomorrow. Right now, Kukowski estimated only about a quarter of IT organizations have the sophistication required to manage a hybrid cloud computing environment.

    There’s no doubt the management of IT will become more automated in the months and years ahead. The challenge organizations face today is determining what tasks either can or soon will be automated. Once that’s determined, it becomes a lot easier to identify what DevOps skills those IT teams will require tomorrow.

  • ‘Old Man Yells At Cloud’

    ‘Old Man Yells At Cloud’

    These days, software programmers are increasingly estranged from hardware. Most millennials and Generation Z developers have never had to mount physical servers. They have never been lulled by the gentle hum of a server room chugging along in synchronous harmony. Today, you don’t even necessarily have to build your own PC or worry too much about disk space.

    Instead, cloud-native software developers conveniently offload the server burden to cloud service providers (CSPs). Hosting in a cloud, like AWS or Azure, for example, makes a lot of sense — it allows programmers to hone in on their own specializations. Elastic computing models are cost-effective for startups, and CSPs typically offer a vertical stack with helpful integrated platform-as-a-service (PaaS) and software-as-a-service (SaaS) offerings. However, what are we sacrificing?

    Well, first, research shows the cloud model becomes less cost-effective as a business scales. Second, as more companies transform into technology platforms, cloud usage could better enable their competition. Third, more direct access to bare metal could be an attractive option for certain service providers to increase ownership and control workload optimizations.

    These arguments are bolstered by large companies such as Dropbox, Facebook, Walmart, and others that chose to cut their cloud allegiances in favor of building their own data centers or adopting colocation (in other words, running your own hardware in someone else’s data center, also known as “colo”).

    I recently met with Zach Smith, managing director, bare metal, Equinix, to understand the current state of hardware-as-a-service and the future of hybrid server models. He believes that in the coming years, improved interfaces that access low-level infrastructure will arm IT with better consumer choice that brings them closer to the metal. Yet, to enable this, the hardware world will need to take some lessons from the upper stack regarding transparency, open source community, programmability and improved developer experiences.

    Sidestepping the Cloud

    Public clouds arose as a convenient one-stop-shop to host entire software application environments. As a result, “we have a generation of developers who will never physically touch that hardware,” Smith said.

    The cloud infrastructure services market was worth $39.8 billion in Q4 2020, estimates according to estimates from Statista. Having witnessed the “movement toward verticalization of hyperscale clouds,” Smith now sees the infrastructure-as-a-service (IaaS) market as an industry of high margins and escalating fees. This is echoed by others who seek to reduce rising cloud expenses.

    Though cloud computing usage is growing considerably, the data center isn’t dead. Instead, computing models are morphing and becoming hybridized. “By 2025, 85% of infrastructure strategies will integrate on-premises, colocation, cloud and edge delivery options, compared with 20% in 2020,” predicts David Cappuccio, distinguished VP analyst, in a Gartner report.

    As hybrid multi-cloud approaches emerge, Smith notices a resurgence of attention being paid to infrastructure. Some massive service providers are starting to construct their own data center estates; others, such as Box, now own and lease servers from data center providers.

    Benefits of Bare Metal

    As mentioned above, there are a few reasons to move back to the metal. First, it may simply be more cost-effective for large deployments. In his well-researched article, Antoine Beaupré compared monthly recurring costs for colocation versus an AWS bill, and found the break-even point rested at $100,000 per month, or 150 Amazon m4.2xlarge instances. His research also found that I/O-heavy applications are more costly in the cloud than via colocation.

    “While many services simply launch in the cloud without the organizations behind them considering other options, large content-hosting services have actually moved back to their own data centers,” Beaupré said.

    In addition to cost savings, automating colocation with a programmable layer could also offer more fine-grained control over computing optimizations. “I believe what we’re creating is an operating model for a rapidly changing hardware substrate,” said Smith. He described how bare metal opens up a neutral infrastructure substrate to control physical networking aspects such as cross-connects, IP transits and peering — a benefit Smith half-jokingly called ‘NetDevSecOps.’

    Another argument is that investing in hardware could, ironically, bring sustainability benefits. A report conducted by ITRenew estimates that, of the total embodied energy required within a server’s entire lifespan, 77% is used to manufacture the hardware itself. In contrast, the operational energy used over a server’s lifetime only accounts for 22%.

    Thus, there is an environmental benefit to reversing the trend of a make-dispose economy continually producing new servers. Instead, hardware ownership could encourage a more circular economy. “A circular economy aims to end our take-make-dispose economy, which is a very linear approach, and instead, keep products at their highest possible value for as long as possible,” according to the ITRenew report.

    Learning From the Upper Stack

    How can we build a fundamental non-opinionated infrastructure platform? According to Smith, the industry needs “hardware and networks that are programmable and usable by a developer generation.” To Smith, changing firewalls at a kernel level, altering how the runtime works or controlling the IP stack, should all be operational via API commands.

    Yet, hardware accessibility is still rather opaque and, historically, not as developer-friendly. “How can we take abstraction and community-driven ideas from up the stack?” Smith asks. To enable these changes, he believes the hardware world should model itself on the upper stack in a few key areas:

    1. Transparency: The hardware world is not as easy to comprehend. “When you get to the physical side of switches and routers, it’s still arcane,” Smith said. Increased transparency in functionality and ownership will be required to turn servers into something all developers can operate.
    2. Open-source community: In the same way the software world is built on strong developer communities, hardware will require an open community to normalize things like firmware, boot order and support for differences between drives.
    3. Programmability: “Self-service and programmability are requirements for most things these days — there’s no difference with physical infrastructure,” says Smith. Take the rise of the API economy — today’s mantra is, essentially, if something is possible in a UI, it should be possible through an API. Similarly, if it can be done in a server, it should be controllable with an API.
    4. Quality developer experience: Self-service, programmable infrastructure is just the beginning — interfaces to operate infrastructure require good developer experience. Smith feels that hardware requires an improved buying experience and better life cycle management capabilities. This could be enabled by open source tools like Tinkerbell, a provisioning and workflow engine supported by Linux Foundation.

    Back to the Metal — A Platformer’s Dream?

    All this is not to say the public cloud isn’t valuable – it absolutely is. The cloud has been necessary and has proven resilient enough to support online business and digital life as we know it throughout the pandemic and for years prior. “In 2020 and beyond, most organizations are going to be transforming into a completely cloud-based environment,” said Werner Vogel, CTO, Amazon, during an online AWS summit.

    But, even if most organizations are in the cloud, that doesn’t mean all of their assets will be. Service providers, especially, may cling to hybrid models for more control, to avoid supporting the competition and, perhaps, even to save money. Private data centers could also increase security. In an era where raw computing power is becoming a new asset (quite literally, in the case of cryptocurrency), the server rack is starting to look sexy again.

    “The magic happens when software and hardware work together,” said Smith. But, giving access to physical technology to a generation that has never touched it will require some ingenuity. As Smith says, this could be done by “automating colo” through more usable, standardized interfaces for hardware management.

    “We will see a future in next 10 years where operated software is separated from cloud infrastructure,” Smith said. That’s a bold statement, as such a dramatic change would, in effect, usurp the current cloud provider IaaS market share, altering the distribution and economic model associated with global software.

    While this dream may seem far-fetched, if more platforms decide to cut out the cloud middleman and go it alone, it could materialize.