Tag: DevOps

  • Cider Security Raises $38 Million to Bring The First AppSec Operating System To Market

    The first-of-its-kind AppSec Operating System, which is already deployed at dozens of organizations worldwide, enables Security and Engineering Teams to build AppSec programs in minutes

    Tel Aviv, ISRAEL, March 7, 2022 –  Cider Security, the world’s first AppSec Operating System, emerged from stealth today, announcing that it has raised $38 million in funding, with a recent Series A round led by Tiger Global Management. Joining the round was the lead investor from Cider Security’s seed financing, Glilot Capital Partners, with participation from Glilot’s early growth fund, Glilot+.  

    The diversity, velocity, and dynamic nature of today’s engineering ecosystem have introduced a wide array of new security challenges and gaps, which are both slowing down engineering as well as continuously being taken advantage of by hackers. 

    Cider Security’s platform provides a unified view of the entire engineering ecosystem, providing Security teams with an in-depth understanding and comprehensive view of the technologies, systems, and processes unique to every engineering environment. Security teams are provided a highly tailored set of controls and solutions to optimize security and achieve full resilience across the entire CI/CD pipeline – all the way from code to deployment. Designed to eliminate the friction between Security teams and Engineering groups, Cider Security allows for AppSec programs to be implemented within minutes, democratizing security and allowing AppSec to become a commodity, consumable by organizations from all verticals, sizes, and maturity levels. 

    “My co-founder Daniel and I endured many of the same challenges that security engineers face today, so we set out to build a new approach,” said Guy Flechter, CEO and co-founder of Cider Security. “By removing the barriers to implementing protection – in essence, democratizing security for AppSec teams – we are changing processes that many felt were set in stone. The level of excitement from users completely exceeded our expectations and we can’t wait to change how Security and Engineering teams from companies everywhere operate.” 

    The funding will be used to expand R&D operations in Israel and open new offices globally to support growing demand. Already in use with dozens of global companies, the company also boasts security leaders from Atlassian, Databricks, Netflix, Rapid7, Built Technologies, Lemonade, Rapyd, and others as part of their advisory board and investors. 

    “The demand in the market for Cider Security is massive,” said John Curtius, Partner at Tiger Global Management. “The methods that companies are using are not keeping pace with the threat landscape, creating serious vulnerabilities that impact businesses globally, and Cider Security is poised to become the industry standard for CI/CD security. Even at such an early stage, they have reached impressive milestones and received incredible feedback from the market. We are looking forward to starting the journey with them.”   

    “As the very first AppSec Operating System, Cider Security is well-positioned to become the leading DevSecOps solution in the market,” said Arik Kleinstein, Glilot Founding Managing Partner. “The solution has made a great deal of impact for its customers in a short amount of time, providing a novel approach to application security that takes the realities of development into account.” 

    About Cider Security

    Cider Security is a first-of-its-kind AppSec Operating System that provides Security and Engineering teams a single, consistent method to orchestrate and implement end-to-end CI/CD security through a single, unified platform. The company takes a holistic approach to the security of the engineering processes and systems, from code to deployment. It establishes a comprehensive Technical DNA of the engineering environment, giving Security teams the transparency and visibility needed to optimize AppSec and achieve full resilience. Founded in late 2020 by cybersecurity industry veterans, Guy Flechter and Daniel Krivelevich, Cider Security’s mission is to solve the most commonly encountered challenges CISOs and security engineers face today. For more information, visit www.cidersecurity.io/.  

  • Zoho Takes on Current Low-Code Market Gaps with New Creator Platform to Empower Businesses to Easily Build, Deploy, Manage, and Analyze Custom Solutions

    Bringing in the company’s 15 years of expertise in low code, the new unified development platform empowers both IT teams and business users to build sophisticated, modern, and compliant solutions, for a low-code experience that is secure, easy to use, and custom-fit to solve business challenges

    Austin, TX, March 3, 2022 — Today, Zoho Corporation, a leading global technology company, announced the latest version of its low-code offering, Zoho Creator Platform, an all-in-one solution that bridges the gap between business users and IT teams by providing a low-code solution-building experience regardless of technical know-how. Organizations currently face soaring demand for new business software, but existing low-code platforms for business users only facilitate basic app building, lacking the sophistication needed to develop scalable, enterprise-ready end-to-end tools. Existing solutions in the market designed specifically for business users facilitate only basic app building, lacking the complexity needed to develop end-to-end tools, which allow organizations to scale and ensure centralized governance.

    Addressing the needs of both business users and IT teams, Zoho Creator Platform supports all levels to build, manage, integrate, and analyze for a complete low-code experience, enabling 10X faster deployment than any other solution on the market. Democratizing access to low-code development tools allows IT and business users to work in tandem to create and deploy apps that are highly customized, while minimizing common interoperability, permissions, and governance challenges.

    “Currently there isn’t a low-code solution on the market that allows both business users and IT to truly build end-to-end business solutions,” said Raju Vegesna, Chief Evangelist, Zoho Corporation. “With this update, Zoho’s Creator Platform combines application development, integrations, process automation, business intelligence and analytics into a single platform while simultaneously enabling IT teams to effortlessly manage security, compliance, and governance challenges. Organizations can now leverage a unified solution for all of their low-code needs, extending the ability to innovate to every employee.”

    The Zoho Creator Platform integrates digital data and processes to facilitate the creation of truly agile solutions for business users and IT teams alike. Business developers can now easily build scalable low-code solutions which include apps, integrations, analytics, and process automation without heavy dependency on IT teams or time-consuming training. For IT stakeholders, the Platform now provides deeper controls around governance and management, without compromising automation, data-driven insights, customization, and the ability to affect revenue and growth. Together, business users and IT can quickly deploy secure, dynamic solutions built to auto-scale, so that organizations can focus on solving business problems and pursue new opportunities.

    “We needed a complete solution to resolve specific operational difficulties, including a lack of streamlined communication and an inability to oversee employees effectively. The Zoho Creator Platform allowed us to build new contextual tools that unify disjointed communication channels, automate processes, and seamlessly integrate into our existing system,” said Gaurav Kakkar, System Process Manager at Emirates Logistics. “Additionally, the new Platform has given specific administrators greater flexibility in implementing new processes through the sandbox and demo user options to keep our data secure while providing important business insights. Together, we’re able to better support employees to be more productive, enabling them to collaborate and spot opportunities to better serve themselves and customers.”

    “With this version of Creator, Zoho is shifting its low-code emphasis from applications to business solutions,” said Jason Bloomberg, President of Intellyx, an industry research firm. “Creator helps business stakeholders and IT personnel collaborate to combine applications, business intelligence and analytics, and process automation into end-to-end business solutions. Creator is simple enough for nontechnical staff while also powerful enough to address complex workflow scenarios in a secure, scalable environment.”

    Key areas of innovation in the new Creator Platform include:

    Expand App Building to Solution Building

    Unified Solution Builder – Create, integrate, analyze, and manage custom business solutions at scale from a single dashboard. Seamlessly switch between different elements, with deep interoperability between capabilities, and in-built guardrails for IT teams to drive enterprise-wide citizen development programs.

    Artificial Intelligence (AI) – Zoho’s intelligent AI assistant (Zia) now enables developers to import data from anywhere, cleanse and transform with one click, build data models, and automatically detect data relationships via Smart Import. AI tasks such as predictive analytics, keyword extraction, sentiment analysis, OCR, and object detection are built into the drag-and-drop user interface for easy deployment.

    Process Blueprinting – This intuitive drag-and-drop builder graphically constructs an online replica of a business process by specifying each step, assigning responsibilities across stakeholders, and automating actions based on pre-set conditions. Users can now identify bottlenecks and have clarity to facilitate scalability for evolving business needs.

    Enhanced Serverless Functions – Developers can now write, store, and execute reusable code blocks in Zoho Creator Platform using Deluge, Java, or Node.js. These functions encourage IT and business teams to work together to build scalable and easily maintainable enterprise-ready apps faster.

    Build a Connected Ecosystem of Solutions for a Seamless Experience

    Unified Data Modeling (UDM) – Unchecked data points, varied data formats, and evolving app landscapes add layers of difficult-to-solve complexities to data integration, resulting in sub-optimal business results. Universal cloud modeling is now included to help developers establish secure data transfer by automating data integration protocols with unified data architecture and over 600 plug-and-play connectors to make data integration easier for users.

    Integration Status Dashboard – Users have complete visibility on how well each integration operates with the new Integration Status Dashboard. Status Dashboard provides key findings on recent executions, success and failure stats, and top connections facilitating early error detection and resolution to enable organizations to discover errors and resolve them quicker.

    Embedded BI and Analytics Engine – An industry-first, full-fledged business intelligence and analytics engine is now included in the Zoho Creator Platform, enabling users to derive business insights from the data residing in their applications without worrying about bringing another subscription into the fold. High-end BI functionalities like predictive analytics, data alerts, what-if analysis, data blending, and conversational analytics are all now supported on the low-code platform.

    Increased Control for IT with End-to-End ADLM

    Environments – Developers can now launch solutions in different environments of choice—development, staging (testing), or production—with a single click based on the readiness of the solution. This allows users to add features continuously or make changes without disturbing the existing app in production. The environments also support role-based access to help business developers simulate user-specific experience validation.

    Centralized Governance – To help IT manage low-code development, features such as granular role-based access controls, comprehensive audit trails and backup options, application IDE, dashboards to view and manage users, billing dashboard, personalization options such as localization, branding customization, and more, are now available in the low-code platform.

    Integrated Communication and Collaboration Aid – Often, business developers get stuck in the build phase with minor obstacles, especially when new to the platform. In order to enhance communication and collaboration, integrated communication enables messaging, sending files, sharing screens, and the ability to make audio and video calls.

    Zoho Creator Platform Pricing 

    Pricing starts at $25 USD per employee, with a 15-day trial available. For comprehensive pricing information, please visit: https://www.zoho.com/creator/pricing.html

    Zoho Privacy Pledge

    Zoho respects user privacy and does not have an ad-revenue model in any part of its business, including its free products. More than 75 million users around the world, across hundreds of thousands of companies, rely on Zoho everyday to run their businesses, including Zoho itself. For more information, please visit: https://www.zoho.com/privacy-commitment.html

    About Zoho

    With 50+ apps in nearly every major business category, including sales, marketing, customer support, accounting and back-office operations, and an array of productivity and collaboration tools, Zoho Corporation is one of the world’s most prolific technology companies.

    Zoho is privately held and profitable with more than 10,000 employees. Zoho is headquartered in Austin, Texas, with international headquarters in Chennai, India. Additional offices are in the United States, India, Japan, China, Canada, Singapore, Mexico, Australia, the Netherlands, Brazil, Saudi Arabia, and the United Arab Emirates. For more information, please visit: www.zoho.com/

  • Service Level Objectives – Techstrong TV

    Service Level Objectives – Techstrong TV

    Service Level Objectives (SLOs) are being more widely discussed as they provide a clear path to delivering exceptional results by defining clear reliability goals. Kit provides updates on the community, use cases and best practices. The video and a transcript of the conversation are below.

    Recording:              This is Digital Anarchist.

     

    Alan Shimel:            Hey everyone. Welcome to another Techstrong TV segment. I’m really happy to have my friend Kit Merker all done up in his Seattle Kraken hat and his winter beard for the pacific northwest up there joining us today. Ken of course is the COO of Nobl9, a recent winner of the devops dozen awards as best new company on the devops space. Hey Kit. Welcome to Techstrong TV.

     

    Kit Merker:             Hey Alan. Great to see you.

     

    Shimel:            It’s good to see you again my friend. I’m thinking Kit we may actually see each other in person soon. I’m hoping.

     

    Merker:             Wouldn’t that be great? Hopefully somewhere sunny and I can get rid of the beard.

     

    Shimel:            Well I’ll tell you. I was just looking at airfare for Valencia, Spain for Cube Con in May. I don’t know if you guys are planning on being there for that one, if that’s like a CNCF thing you go to or what or – actually we have a road show coming up in Seattle at some point. I’m not sure when. We’ll talk about that.

     

    Merker:             Well in May I’m not sure about Cube Con but we will be having SLO Con and we’re doing it online again this year in May so that’s what I’m looking forward to.

     

    Shimel:            Yes. I think I saw that. What are the dates?

     

    Merker:             It’s May 9th through 12th. And that will be completely online and asynchronous and attend while you work just like last year. So we’ll have tons of speakers and all the fun from last year that we had and hopefully even bigger. The CFP is open right now so if you go to slowconf.com you can submit a talk. And it’s going to be exciting. And you guys covered the, were a media sponsor last year so hopefully we’ll have you back.

     

    Shimel:            Yes, we were.

     

    Merker:             Not to put you on the spot.

     

    Shimel:            I remember. We’ll talk about it.

     

    Merker:             All right.

     

    Shimel:            So that works out well because I think Cube Con if I’m not mistaken is like May 16th.

     

    Merker:             Yeah. We intentionally didn’t put it the same dates so.

     

    Shimel:            Yeah. So that will work. Cool man. Let’s talk a little Nobl9 though.  I guess we really shouldn’t. I’m assuming everyone knows who Nobl9 is. But I forget you’ve still only been around two, what, two, three years and at most. And not everyone may be familiar. Why don’t we back up and start there?

     

    Merker:             Sure.

     

    Shimel:            Tell people about Nobl9.

     

    Merker:             Of course. Yeah. So Nobl9 we make a service level objective platform, SLOs. And the whole idea of SLOs is about measuring your observability system and bringing new context, shared context so that you can make better decisions and better automation within your organization. So if you think about how you’re pulled in all these different directions, right? Some people on your team say we’ve got to ship features. Some people say if we don’t make it reliable and perfect then we’re going to hurt our reputation. If we don’t fix our tech deck we’re going to burn out all of our employees and we’ll have the great resignation to deal with. They’re all getting pulled in all these different directions.

     

    And what’s interesting about this is that we have actually more data about our software than we’ve ever had before. We have source control. We’ve got our AWS Cloud. We’ve got our Kubernetes cluster. We’ve got all these observability tools. We have so much data and yet we come to these different conclusions about what we should work on. And this is a big problem for so many organizations. So what Nobl9 is doing is we’re bringing some additional context. This is what’s really missing is people need to understand in an organization what are the risks to the system. What are the expectations that customers have and what are the tradeoffs we have to make in order to deliver the right kind of service to our customers?

     

    So what we’re doing with service level objectives in Nobl9 d is we collect all this observability data, we add this context and we drive automation and decisions so that whether you’re on call, you’re planning your future roadmap or trying to justify your investments you can see exactly what the impact is on the business and everybody can start pulling in the same direction. And that’s really what we’re doing. And like you said we’ve been around for a couple years. We now have a product in market. We both have kind of an entry level thing called Hydrogen, an enterprise class product that’s being used by some of the world’s largest enterprises and it’s very exciting and we’re having a great time.

     

    Shimel:            Very cool. Kit when we look over the evolution of the last couple years, right, ‘cause I remember with Nobl9, right, we first thought of it around well this is an SRE kind of thing. Right?

     

    Merker:             Yeah.

     

    Shimel:            And SREs early on were inherited a world of SLAs. Right? Where it was perform or a quick bullet to the back of the head will work.

     

    Merker:             Metaphorically speaking.

     

    Shimel:            But that wasn’t a very forgiving model or a model that would really kind of foster cooperation and team building and a lot of the principles behind devops, right, about how we get stuff done. It’s very hard to have a blameless postmortem when if you blew an SLA someone’s job is on the line. Right?

     

    Merker:             Well it’s really interesting because I think definitely in the sort of earlier I would say IT service model, right, where you have SLAs, especially if you have maybe outsource contracts. Right? SLAs became really a form of punishment. Right? One of the interesting things that I learned from sort of the Google SLA model is that there’s an assumption of reliability at Google, an assumption of infrastructure investment that’s not actually there in most enterprises. The SLOs that are prescribed by the SREs in the Google model are really trying to hold back over investment in infrastructure and this sort of gold plate infrastructure problem. Well most companies in the real world.

     

    Shimel:            It’s the other way.

     

    Merker:             It’s the other way around. Their issue is they can’t keep up with the reliability needs and the feature pressure is really the issue that they have. And so with this SLO model and being able to define them in fine grained ways across multiple data sources, being able to use it with automation. What changes is that you can start to put guardrails around these different conditions that people care about. You start to model the business. And this is really what we’ve got to get to. It’s about building the technology for digital business because all the businesses are digital now. Right?

     

    Shimel:            Right.

     

    Merker:             So you’re point about kind of like how you adopted sort of like devops method and bring this to the table, I mean really devops is trying to get better at building software, become more kind of diligent and efficient and make the right tradeoffs. It’s about ownership, right, a sense of responsibility but not punishment. And I think once people realize – actually I just had this customer from Flexera. We just did this testimonial video together. And he said it’s like once people realize that they weren’t building SLOs to point blame at them or punish them, that we were trying to do it to help them so that the people in the organization could see when they had problems, right, when they needed help.

     

    Then people really got open to this idea. This to me this is the game changer. If we can help organizations become more transparent, to be able to do more through APIs instead of meetings if you know what I mean. Right? Like using the data and the systems to help make these better decisions. This is what changes culture. A lot of people want to talk about reliability culture and devops culture and agile culture but that’s such a scary idea. The way I like to think about this and what we’ve talked about with our customers and community members is it’s about how you make decisions together. Right?

     

    And if you can make lots of decisions in a way that is supportive of the strategy, supportive of the business and also the realities of the pressures that we’re on as humans. And let’s not forget that everybody is going through a hard time and maybe not totally happy being on call and all these other things. Taking all that into account and making a decision together this is what becomes culture, not the other way around. Right? You don’t change culture first to get the decisions. You start making good decisions and then the culture emerges from that. And that’s I think a really important idea.

     

    Shimel:            I agree with you 100 percent. No doubt about it. And it is. But when we focus on devops being about delivering software and clearly that’s the goal. Right? Delivering software better, faster, higher quality. In order to do that you need just that whole culture thing. And some people say oh culture is BS. It’s not. Having a team that works together, having goals that are clearly enunciated, right, we’re all trying to do – you understand what the guy or gal next to you is doing. Right? And why they’re doing it and how you fit into it. That’s all part of that. All of those things help you get software better, faster, higher quality. And that’s where it is.

     

     What’s interesting about Nobl9 Kit from where I sit, right, because I sit – I mean beyond being on different sides of the continent I sit in a different chair than you. I get to look at the whole market without a horse in the race so to speak. You guys have done a really great job of defining and owning SLOs. Right? I think for a lot of people in the marketplace, right, SLOs aren’t necessarily synonymous with Nobl9. But you’ve probably done more to promote SLOs and their use and why they’re beneficial than anybody else in market.

     

    Merker:             Well first of all I appreciate that a lot. Personally I think it’s a reflection of the community. I think it’s a reflection of a nerve that we hit at some level. Because to your point, right, goals that are well enunciated and it’s funny to me because I think oftentimes we think of goals as things that are kind of squishy. Right? We set stretch goals – oh sorry. I thought I muted everything.

     

    Shimel:            It’s never all muted.

     

    Merker:             We’re all muted. We want to set goals. Sometimes they’re a little squishy is what I was saying. So it’s like maybe you have OKRs. Maybe you have stretch goals. Maybe you have some different perception of what the goal is for your service. And what SLOs are doing is turning it into pretty much the most precise type of goal you could imagine which is code, right? Like actually describing it in code and something that’s checked in where it’s the truth. There’s no arguing about what it is. Now we can change it, right? We can always change our minds about what the goal is. But at any given point in time there is a goal that’s described and there’s a set of actions associated with that goal. And to me this is exactly what is so attractive to people in the market about SLOs because they’re no longer guessing.

     

    They’re no longer sending each other Slacks and emails and writing documents and putting it in dashboards. They have a very precise way of describing what they want and expect from their service that takes in account the risks and tradeoffs and customer expectations that they have for the service and then allowing the team to engineer to that goal, allowing the business to understand the tradeoffs. Right? Hey. If you want the service to be faster we’re going to have to spend more to buy more computing power. Right? Hey. If you want these features we’re going to have to put these other reliability concerns on hold and vice versa. This is something that brings visibility to all the little engineering decisions that are made on a daily basis and then aggregates them up to the size of an entire enterprise ‘cause it’s birds eye view of how the enterprise functions and doesn’t limit them to a prescriptive way. ‘Cause I think this is one of the other big challenges.

     

    When I look at the observability space or anybody’s infrastructure space is trying to bring a prescriptive guidance. I think today’s world is about the right tool for the job. Right? You’ve got to fit inside of an ecosystem whether that’s what language you use, what CICD system you use, what package manager you use, what source control you use. All these things are choices that engineering teams have to make for themselves. And you can’t necessarily dictate that Team A and Team B are going to agree on that stack if you will. Right? You give them some flexibility. But what you can get them to agree on is the concept of the service level objective. Like what should my service provide to customers in terms of availability, latency, performance, throughput, whatever the characteristics are that deliver that end to end service.

     

    This is what becomes almost the contract because if I know that I’m using your service and you’re going to give me x number of latency over y number of nines then I can build my system to account for it. I can decide what my retry strategy is, what my caching strategy is. Right? I can design and engineer a system that takes into account what your service says it’s going to do. Well that level of clarity allows engineering teams to operate in a completely fundamentally different way because now they aren’t guessing and they’re not hoping and they’re not wishing. Right? They’re working toward a clearly articulated goal. And I think this is what’s so important. So now the whole idea of us promoting this concept. I mean we’re just like we’re in love with SLOs. I mean I don’t know how else to explain that. Like we’re just like losing our mind about how amazing it is.

     

    But it is really about the community. We now have literally thousands of people that are involved in the SLO, the SLO Conf community. We have the monthly meetups. The conference as I mentioned will be in May. And we’re expecting hopefully about 5,000 people to show up this year. Last year we had 2,200 registrations. So we’re pushing hard for this but based on what we’ve seen in the market and the companies that are literally deciding if they’re going to build or buy an SLO platform right now.

     

    There is a huge groundswell of interest in this concept to take their observability systems, their operation systems, reliability systems to the next level. And all the practices and tools and techniques and tricks everybody wants to share it and learn together which is I think the most exciting thing. And it fits in with so many other areas, incident response and chaos engineering and how we do monitoring and logs. All this stuff kind of fits into this whole story about SLOs. Even finops, right, even like cost management, all this stuff fits into this same story. So yeah. It’s kind of overwhelming to be honest how much the market seems to have appeared and materialized over the last couple of years with SLOs.

     

    Shimel:            Cool man. Hey Kit, we’re up on the clock here. So you mentioned SLO Con and SLOconf with an F dot com. Right?

     

    Merker:             That’s right.

     

    Shimel:            Right.

     

    Merker:             Yep.

     

    Shimel:            For people who want to maybe submit a talk or just find out more about attending this year’s virtual conference in early May. And then for people wanting to get more information on Nobl9 is it Nobl9 dot com or IO? I forget.

     

    Merker:             Nobl9.com. Yeah. N-O-B-L number 9, dot com.

     

    Shimel:            That’s it. Hey Kit, man. It’s great seeing you. I hope to see you in person sooner than later here. But keep doing what you’re doing man and congratulations on the devops dozen award as well.

     

    Merker:             Thank you so much Alan and hopefully we’ll catch a hockey game together.

     

    Shimel:            Come on down. Actually I don’t have Seattle Sounder tickets when they’re playing the Panthers but we’ll look into it. I’ll talk to you later man.

     

    Merker:             All right..

     

    Shimel:            Great seeing you.

     

    Merker:             All right. Take care Alan.

     

    Shimel:            All right. Bye bye.

     

    Merker:             Bye.

     

    [End of Audio]

  • Analyzing SRE Job Postings

    Analyzing SRE Job Postings

    You can find plenty of high-level definitions out on the internet about what site reliability engineering means and what site reliability engineers do.

    But if you want to understand what it’s actually like to work as a site reliability engineer, there is perhaps no better source than job descriptions. SRE job ads explain what real companies are looking for and what they expect on a day-to-day basis.

    To provide insight on what SRE looks like in practice, we’ll look at some job ads from several leading companies. As we’ll see, each company has a slightly different take on what the site reliability engineer role entails, but it’s possible to identify some core themes that underline what businesses expect.

    To understand the content of SRE job descriptions, let’s examine examples from four leading companies.

    GitLab’s Job Ad

    GitLab’s SRE job description contains most of what you would expect from a typical site reliability engineer job ad. It highlights the importance of having a mix of technical skills and collaboration skills. It also emphasizes expertise in areas like Unix/Linux, infrastructure-as-code and Kubernetes.

    What may be slightly surprising, however, is the emphasis that GitLab’s job description places on programming skills. GitLab expects SREs to know how to code in specific languages, like Ruby and Go. The takeaway is that SREs need to know more than just how to use code to solve IT operations problems. They must also be able to develop applications or contribute code to application platforms (the job description mentions “contributing to code in GitLab” as a required SRE technical skill).

    Also interesting is the fact that GitLab expects site reliability engineers to be able to write blog posts. Blogging may not be one of the first skills that come to mind when you think of a site reliability engineer’s responsibilities, but at GitLab, at least, it’s part of the job.

    LinkedIn’s Job Ad Template

    LinkedIn provides an SRE job ad template that businesses can use when posting their own SRE jobs on the site.

    LinkedIn’s ad is pretty high-level (which is unsurprising, given that it’s a template rather than an ad for a particular job). For the most part, it doesn’t mention specific tools—although the main exception is programming languages, where it says SREs should know how to code in languages like C, Python, JavaScript and Ruby. Like GitLab, then, LinkedIn clearly sees development as a core SRE job responsibility.

    The LinkedIn job description also places a heavy emphasis on the ability to “gather and analyze metrics.” It doesn’t use the word “observability,” but that seems to be what LinkedIn is getting at.

    An SRE Job at Microsoft

    Continuing the theme of development-centric SRE work, a recent job ad for a specific SRE opening at Microsoft reads a lot like a DevOps engineer job description. The ability to “design, write and deliver software” is the top responsibility listed in the ad, which also mentions familiarity with CI/CD tools.

    The Microsoft job description also mentions the importance of written and verbal communication skills. Unlike GitLab’s ad, this one doesn’t say SREs will need to write blog posts; still, it’s clear that companies expect people in this role to be creative communicators in addition to technical experts.

    It’s worth noting, too, that Microsoft wants site reliability engineers who know both Windows and Unix. If you need further proof that Unix skills are absolutely central to SRE work, look no further than this job ad from the company that created Windows.

    Amazon’s Site Reliability Engineer Ad

    Even Amazon—a company that is more of a platform provider than a software vendor—places major emphasis on the ability of SREs to code in one of its recent SRE job ads.

    Interestingly, the Amazon job also highlights networking skills as a major qualification. That’s understandable given the complexity of networking in the AWS cloud. But it’s a bit surprising because most other site reliability engineer job ads don’t call out networking expertise as a key skill—despite the fact that network engineering is critical to SRE work.

    The Amazon job description mentions the importance of an applicant’s willingness to be on-call, too. We suspect that’s critical in virtually any SRE job, but at least Amazon is upfront about the fact that, at time, you’ll be woken up at 4 a.m. to manage incidents.

    Conclusion: Takeaways

    There are a few key takeaways from these various SRE job descriptions.

    • Development skills are absolutely critical in order to be an SRE. Scripting for administration or IT Ops purposes is not enough on its own.
    • The ability to communicate clearly—including both verbally and in writing—is more important to SRE work than you may realize.
    • Network engineering skills, too, are a crucial part of SRE jobs, at least at some companies.
    • In practice, SRE job descriptions sound more similar to DevOps job ads than you might expect.

    This is not to say that all SRE roles are identical or that all companies expect the same things from their SREs, of course. But the jobs ads or templates we’ve surveyed do highlight how the high-level understanding of SRE translates to on-the-ground reality at actual companies.

  • Shoreline Announces Multi-Cloud Incident Automation

    Added support for GCP and Azure enables Shoreline customers to debug, repair, and automate across multi-cloud environments, reducing operations complexity

    Redwood City, CA, Feb. 16, 2022 — Shoreline.io, the Incident Automation company, today announced the general availability (GA) of its platform on Microsoft Azure and Google Cloud Platform (GCP), building on existing GA support for AWS. With today’s news, customers can seamlessly remediate issues across their multi-cloud environments as if they were working on a single box.

    Today’s DevOps teams struggle with manually managing differing resource hierarchies, tags, credentials, and accounts across multi-cloud fleets. They have to learn each cloud provider’s tools and the nuances of configuring and maintaining their fleets. It can be challenging to query resources and execute actions across clouds, accounts, clusters, or regions to debug or repair an infrastructure issue.

    Shoreline manages the cloud-specific complexity of discovering resources, scraping metrics, and building automations, with commands executed in parallel across VMs and containers in all three clouds. Interactive commands return in seconds, regardless of fleet size. This allows SREs to debug in real-time and quickly build automations across the three largest cloud providers, increasing reliability.

    “Multi-cloud environments are becoming ever more common and complicated to operate,” said Anurag Gupta, CEO and founder of Shoreline. “Shoreline’s ability to provide parallel fleet-wide debugging and automated remediation has been proven with AWS. With today’s announcement, we now offer the same seamless experience across Azure and GCP as well. This makes it simpler for customers to debug incidents and automate repairs without intricate hand-coding for each cloud environment.”

    All Shoreline capabilities, including role-based access control and audit, run consistently across clouds, reducing the challenges of managing multi-cloud production environments. Shoreline automatically discovers resources and tags, providing a unified resource hierarchy across cloud environments. Customers can transparently query and execute actions across clouds, regions, accounts, and clusters without logging in and out of different VPNs, reducing manual labor and the need to juggle many cloud-specific tools.

    “If you need to manage a multi-cloud fleet, Shoreline is your best answer,” said Dr. Jay Yu, VP Product and Innovation and GM San Diego Innovation Lab at TigerGraph. “Shoreline’s approach streamlines remediation of incidents in our production cloud, and it eliminates the complexities inherent in operating across multiple cloud providers. This means we can understand and resolve issues faster, which increases our system availability.

    Whether you are handling instance maintenance events in a multi-cloud environment, moving or copying files to cloud storage, or autoscaling, Shoreline allows users to take full advantage of each cloud without worrying about the differences between clouds.

    To learn more or start a free trial visit: https://shoreline.io/blog/multi-cloud-operations-can-be-easy

    Helpful Links

     

    About Shoreline

    Shoreline provides real-time automation and control for cloud operations. Shoreline makes it easy for DevOps engineers to diagnose and repair incidents and quickly create automated remediations to fix them forever. Founded in 2019, Shoreline has raised $22M from Canvas Ventures and NTT VC. The company is headquartered in Redwood City, California. To learn more, visit https://shoreline.io/.

  • DevOps for Customer Experience

    DevOps for Customer Experience

    Charlene O’Hanlon and Amy Hudson of Cyara discuss the concept of DevOps for customer experience, which takes DevOps methodology and focuses it on CX software. But there are pitfalls DevOps teams face when dealing with customer experience software. The video is below followed by a complete transcript of the conversation.

    Announcer: This is Digital Anarchist.

    O’Hanlon: Hey, everybody, welcome back to Tech Strong TV. I’m Charlene O’Hanlon, and I’m here now with Amy Hudson, who is the VP of Global Center of Excellence at Cyara. Amy, thank you so much for taking a couple minutes and talking with me today—I really appreciate it.

    Hudson: I’m happy to be here.

    O’Hanlon: Great, great. So, Amy, tell me a little bit about Cyara to start off.

    Hudson: Oh, absolutely. Cyara has been around for about 10 years at this point, but we really focus on what we call customer experience assurance. Companies spend a lot of money in designing the right customer experience and all the technology that supports it, and Cyara is in the business of making sure that you are getting the experience you’ve invested in. And if you are, how do we help you continue to innovate and double down? And if you’re not, how do we help you fix it very quickly so you can stay ahead?

    O’Hanlon: Alright. That sounds great, and I imagine your business has been booming over the last year or so, because customer really came to the forefront for a lot of organizations as they kinda had to double down on their digital transformation efforts just to stay alive over the pandemic, over the last year and a half or so. And some of them have done it really well and others have not done as well.

    So, what are you guys seeing in the market right now as far as customer is experience is going?

    Hudson: Yeah, no, that’s a great question, because it has changed a lot in the last year, with the pandemic. I mean, listen, customers have historically always been demanding, right? That’s in our nature as customers. But now, with their hands on the technology, customers have very high expectations right now. And switching costs are low. So, if a customer doesn’t get what they’re looking for out of an experience, you may lose them.

    And so, the importance of having a good customer experience and staying ahead of it is at an all-time high from our perspective.

    O’Hanlon: So, we’ve been, obviously, you know, through DevOps.com, we focus on the benefits of going with a, kind of a DevOps methodology and mindset and culture shift and all that good stuff. And we’ve seen kind of that whole premise of DevOps kind of shifted to other parts of an organization as they recognize the benefits of kind of blending two different maybe mindsets and areas of an organization together to kind of streamline operations and actually build a better product in the long run.

    I imagine customer service is not—has not been left out of the conversation when we’re talking about organizations adopting those DevOps principles for customer experience.

    Hudson: Yeah, that’s right. It’s interesting. So, about four or five years ago at Cyara, we started seeing DevOps fold into the contact center/customer experience space, but it was a little bit more of a rarity then. DevOps hadn’t necessarily intersected with customer experience yet at that point, but over the last three couple years or so, we’ve really seen DevOps become much more commonplace in the customer experience space. Which I think is a good thing, because, exactly what I mentioned before—you need to stay ahead. You need to be able to innovate quickly for customer experience, and I think these companies are starting to see that.

    So, we’re starting to see DevOps adopted almost universally. Either somebody has started it or is halfway through or a little more mature, but it’s in the conversation with almost everybody we talk to these days in terms of customer experience.

    O’Hanlon: That’s great. That’s really great to hear, because there are certainly a lot of benefits to DevOps in the customer experience space, you know, not the least of which is being able to service the customer much more effectively and quickly.

    But it’s not kind of a one to one adjustment, though. You know, it seems like, especially since, when we’re talking about DevOps, we recognize that each DevOps implementation and each DevOps experience, if you will, is different. You know, everyone is kind of a snowflake.

    So, how does that equate to the customer experience and how might that actually kinda trip up organizations if they’re looking to kind of add DevOps to their customer experience?

    Hudson: Yeah, absolutely. So, when I first started at Cyara, I led a very small strategic consulting group, and we worked with customers on how Cyara can help them through any major transformation. And because of the shift of the industry, it ended up being a lot of DevOps transformations. And so, we’ve seen customers at multiple different points in the journey, and the struggles that they’ve bumped into. And I think there are a number of different kind of pitfalls if you will, or lessons learned from that.

    And, you know, one of the first things—and we can go into as many of these that are of interest, but one of the first things and most important that pops out at us is that leadership level cultural shift. I think, so frequently—and I’m leading with this because if you don’t get this part right, it’s really gonna hold you up. But so frequently, DevOps is viewed as a technical or process change and so, it happens at the day to day level. But really, it is a mind shift, cultural shift, has to be top down, has to be embedded in the culture, and it has to be leadership driven.

    O’Hanlon: Mm-hmm, yeah. I agree, agree, and that goes across an entire organization, no matter where they’re implementing DevOps, whether it’s in IT or if it’s in the back office or marketing. Because we’re seeing this blending of so many different disciplines in an organization these days as ways to advance and accelerate just their ways of doing business.

    But to your point, if we don’t have, or if an organization doesn’t have that buy-in from the top, no matter where they’re implementing DevOps in an organization, it’s doomed to failure.

    Hudson: That’s right, that’s right. And it’s, you know, and it’s not just the kickoff, it’s not just somebody at the C level saying “rah rah” at the beginning.

    O’Hanlon: Right.

    Hudson: This is, like, through the process, embedding into how you motivate, incentivize, how you reward people, how you—you know, in your regular cadences. It’s everywhere. It needs to be treated as a cultural shift.

    O’Hanlon: Yeah, yeah. I totally agree. Now, what about, you know, beyond kind of that initial, as organizations start to kind of adopt this mindset and these principles, what are some of the things that maybe we call it kinda DevOps Phase Two or DevOps 2.0, the Second Day DevOps—what are some of the things that you guys are seeing that organizations need to be very mindful of to make sure that they are successful?

    Hudson: Yeah, another thing that we’re kinda bumping into at more of the kind of operational level is, as you know, the importance of flow in DevOps, right?

    O’Hanlon: Right.

    Hudson: You don’t wanna disrupt the flow. And to do that well, you have to think about automation, right? It’s just—it’s a no-brainer. It’s a pillar, right? And to me, when I think about automation, there’s a lot of different pockets you can automate. But for me, I think primarily around deployment automation and testing automation.

    We did an interview—or I did an interview with a consulting, one of the big four consultants with the DevOps expertise and a customer. And both of them agreed that automating the testing, while it’s not always completely simple or straightforward, it is, they would almost consider it the low hanging fruit, right? Get the testing automated so you can just kind of plug and play that part of it, don’t disrupt the flow.

    From a deployment perspective, there’s a number of different environments, right, to get something into production. So, the more you can automate from that perspective, the more you can continue to push things out and learn fast and fail fast, if you will.

    And so, finding those pockets of automation and having a strategy on how you can automate as much as possible as to not disrupt the flow is something that we’re really recommending to folks to realize the total benefit of the transformation.

    O’Hanlon: What about from a people perspective? You know, DevOps is as much about culture, as we know, as it is about the processes and the technologies. So, are there ways that organizations—maybe they’re not thinking about particular things when it comes to culture and people in their adoption of DevOps specifically for customer experience?

    Hudson: Yeah, sure. So, I would answer that a couple different ways. The first one I would talk about is essentially around—this is, again, it’s a culture thing. One of the pillars of DevOps is to create an environment that encourages learning and a safe place to fail. And so, you want your teams to be encouraged to fail if they have to and learn from it and get better the next time and feel safe doing that. So, that’s one from a person perspective.

    The other thing I would mention is just around measuring, key performance indicators, right? You can’t know if you’re successful without measuring, right?

    O’Hanlon: Mm-hmm.

    Hudson: And then publishing those KPIs so they’re transparent. Transparency is really important, so everybody is charging towards the same goal, and everybody feels like they are part of achieving that goal. So, let’s get the performance indicators out there, let’s be clear what we’re trying to achieve, let’s make people feel safe in that process. And, you know, that’s kinda the culture you wanna build around it.

    O’Hanlon: So, when we’re talking about customer service applications and software versus, say, an internal process or internal DevOps process or an internal application that is being advanced by these DevOps processes, what is the difference when we’re looking at what may be what those KPIs are or what the service level objectives are, things like that? Are there certain things that an organization needs to be more mindful of when they’re working on a customer experience type software rather than maybe more internal focused or maybe other customer that’s not maybe customer facing, end user customer facing?

    Hudson: Yeah, I think that’s a great question. And what we’re trying to do within our industry is create this mind shift where you are thinking about the end customer all the time—not just in the production environment, you are always thinking about the end customer experience through every step of the journey.

    And I’ll give you an example of what I mean by that. Traditionally, the contact center space, how they would monitor things in testing or production is kind of server loads or capacities, right? If it’s reached capacity, it’ll set off an alarm and that’s a problem, right? You don’t want it to be at capacity.

    Great, but you might not know what the customer experience is if that server is at capacity, right?

    O’Hanlon: Mm-hmm.

    Hudson: And so, at Cyara, what we’re trying to do is say—absolutely, that server might be at capacity and that’s a problem, but what is the customer experiencing in the moment right now in production? But we also wanna test in Dev and QA and UAT and performance testing, what the customer experience would be. So, if there’s an issue that comes up, you know it could be a pretty serious one, it could be calls being disconnected. If, in your revenue generating phone lines or chat windows, customers can’t get through—you wanna know that before it gets into production.

    O’Hanlon: Mm-hmm.

    Hudson: You don’t wanna know necessarily that—or it may be less helpful to know if a certain piece of technology is at capacity. What’s most valuable is to know what the customer would experience in that moment, even before it gets into production, if you can do that.

    O’Hanlon: Interesting. You know, it’s really fascinating to have the conversation about DevOps in different vertical markets, because everybody’s got something different that they’re really, really focusing their efforts on, but at the end of the day, it really is all about just making sure that the end user experience is the best it can be, and that the application is working as advertised and certainly that there’s a level of security as well within that application.

    So, I do imagine that security is also a big part of the equation, especially with the customer experience and the amount of sensitive data that a lot of contact centers, to your point, that they’re dealing with on a regular basis. So, heavy emphasis on Sec on DevSecOps?

    Hudson: Oh, absolutely. And that’s really from two ends. One is that customer data, right? There’s—you have to protect that. There are sensitivities, and those need to be protected, and we need to invest in those, and you need to be able to test that in production or prior to that if possible, right?

    But the other side of it, too, is around the regulatory requirements, right? Customers will—our customers, large companies—will get fined if certain requirements aren’t met, right? And so, from a pure business perspective, you’re motivated to make sure the customer is experiencing that requirement. But then from their own protective perspective, you’re also motivated.

    And so, DevSecOps, we really encourage people to fold security in very early in the discussions. It’s often one of the last things to come up—“Oh, wait, did we talk about security, did we bring in that team?” Fold them in early, complete transparency, get the conversations in and weave them into the process, because it’s critical.

    O’Hanlon: Excellent, excellent. Amy, this has been a great conversation. I’ve really, really enjoyed it, and would definitely love to have future conversations with you about other topics related to DevOps and the customer experience, because I really think that this is something that is—it’s not gonna be a one and done conversation. It’s like DevOps. Customer is an evolving conversation.

    But for now, thank you so much for taking the time and having the conversation with me. I do appreciate it.

    Hudson: Thanks for having me. It’s a privilege to be here.

    O’Hanlon: Alright, great. Alright, everybody, please stick around. We’ve got lots more Tech Strong TV coming up, so stay tuned.

    [End of Audio]

  • Irreconcilable Differences: DevOps Grapples With Issues

    Irreconcilable Differences: DevOps Grapples With Issues

    DevOps issues can be a thorny subject. The coming together in harmony of Dev (developer) and Ops (operations) represents an arranged marriage of sorts that, for some, will never have a ‘happily ever after’ ending as both parties ultimately grapple with irreconcilable differences.

    But despite the naysayers, the very existence of DevOps as a portmanteau (and perhaps sister labels like DevSecOps, to form a security sandwich) is, in many ways, a validation of the need to form a bond of tighter unity and harmony between two factions that have often been at odds with each other over the years.

    Even with the popularization, extrapolation and democratization that DevOps has enjoyed through the last decade, not everyone will be convinced of its worth and/or its effectiveness—some even doubt its very existence. Some say that DevOps already existed without a formalized label if you look at the software development practices IBM championed a quarter-century ago.

    One thing we can be certain of is that DevOps almost always throws up a few meaty bones of contention. Let’s take a closer look at these issues in the hope that we can harness some of the angst and turn it into positive energy for a DevOps-enriched future. If we are to analyze the most contentious and sensitive DevOps issues in this space, what should we be aware of and how do the big issues break down?

    Is it a Bird? Is it a Plane?

    Arguably, the biggest problem DevOps faces is categorizing it. Some call it a methodology for software application development. Proponents of ‘classic’ software methodologies disagree with this idea as, for the purists, a software methodology can only be Agile, waterfall, extreme, rapid, joint or Scrum.

    These semantics mean that many people would prefer DevOps to be classified as a culture, a workplace ethic, a technique, a culture and/or a mindset or, perhaps in the vaguest terms, an approach. To be truly successful with DevOps you must take a holistic approach and look at the entire development cycle from beginning to end. Closely evaluate the processes that go into development to find bottlenecks and roadblocks to productivity. By finding the areas where your current processes come up short, you will be able to identify the areas to emphasize when implementing a strong DevOps strategy.

    Cloud-Native DevOps

    Anyone who hasn’t been living in a cave since the turn of the millennium will know that cloud computing has grown, faltered occasionally and, ultimately, blossomed to become a new standard barometer for all organizations on their journey toward so-called digital transformation.

    That’s the good news. The not-quite-so-good news is that cloud (and the contemporary drive to go cloud-native) is still complex from initial deployment to ongoing maintenance, management and reporting.

    Taking DevOps into the world of cloud-native will ultimately pay off, but first, there will be challenges as teams get used to the new shape, form and function of the altogether more abstracted and virtualized software toolsets.

    The key to getting cloud-native DevOps right will be a prudent approach to monitoring and observability. As cloud-centric DevOps teams ingest the logs, metrics and traces they need to perform solid and dependable system observability, they will need a consistent set of tools to monitor and observe systems in the long term. Within this practice, it will also be important to remember that monitoring shows you lower-level granular information related to system performance. Observability includes all the information gleaned from monitoring and also includes higher-level tools, some of which will be data visualizations for DevOps practitioners to use. When the two are combined for cloud-native DevOps, system health can be optimized, preserved and maintained while any debugging or root cause analysis is executed at the lower level.

    Machines in the Application Loop

    With machine-to-machine events now happening more prevalently inside the internet of things (IoT), the need to capture, integrate and analyze the event streams that go on outside of the human loop and bring those log metrics back closer to the sphere of ‘human’ software engineering is not a plug-and-play quick fix.

    Getting machines to play nicely and be a part of expansive and progressive DevOps teams should be a given. After all, they’re just machines. In reality, there will be specific skills needed and human DevOps personnel will be required to get used to updates and other alerts that they have not considered before.

    AIOps and Automation Limits

    Related to our last point on machine events, we need to think about AIOps. When we build AI-driven DevOps and create AIOps, we will need to stop and question where we set limits on process automation and where the wider elements of automation hit the limiter/restrictors. To know just how far we should build out our AIOps practice, exhaustive auditing and analysis must to be carried out; the whole technology proposition here is no simple point-and-click affair. Even when we do establish workable AIOps, know that there will be perimeters.

    Add all that to the fact that some AIOps implementations will require what we like to call ‘human handoff’ support when the AI intelligence engine doesn’t know what to do next and needs additional data and training—only then can we start to appreciate that AIOps itself is no simple plug-and-play affair.

    Lift and Shift Doesn’t Scale

    One of the unfortunate truths in too many real-world IT shops today is that, where the cloud is used, it is used poorly. Too many technologies are unceremoniously lifted and shifted to cloud instances that an organization procured. This makes cloud-centric DevOps harder to achieve. But why?

    Because what happens back down in terrestrial (i.e., non-cloud) programming is the development of individual cross-functional software teams. This silo-based approach happens due to corporate legacy structures, company management systems and, sometimes, for personal, parochial or cultural reasons. When different teams are all reinventing wheels (running diagnostics tests, setting up CI/CD pipelines, delivering upgrades and so on) that should be shared and accessible to all, a natural level of inefficiency surfaces.

    DevOps Issues: Conclusion

    These are the five most contentious DevOps issues in the near term, and it would, of course, not be too hard to find and categorize even more. In the future, we might even need to argue over which developers should be categorized as core devs and which core members of the operations department to include.

    For software developers, software architects—really, all the software engineering professionals who work in systems administration, database admin, testing, security and all other forms of operations—there’s quite a lot at stake and quite a lot to fight over. And if you ask me, that’s what makes DevOps great.

  • 3 Technologies Driving Business Sustainability

    3 Technologies Driving Business Sustainability

    The pandemic highlighted many things, not least of which was the shift in consumer behavior toward further encouraging companies to change their operations and act with sustainability in mind. An overwhelming 96% of businesses said the pandemic shifted their focus to the social component of environmental, social and governance (ESG) strategies. Technology has been a key player in helping corporations quantify and tackle ESG issues in their sectors.

    A recent PwC and WEF report outlining the use of technology to drive large-scale sustainable change looked at 300 cases of emerging technology in relation to achieving global sustainable development goals. The study found 70% of their 169 targets could be enabled by technology applications.

    With the link between sustainability and technology clear to see, here’s where technology and innovative thinking are boosting sustainability in three key industry areas.

    Energy, Utilities & Resources Are on a Sustainable Transition Journey

    With 30% of overall greenhouse gas emissions stemming from power plants, it is not surprising that utility companies are under intense scrutiny and pressure to transition to green energy. Many are actively investing in renewable energies such as wind farms, hydro stations and solar power. “Green steel” is at the center of America’s 2030 greenhouse gas pollution reduction target, and the U.S. already generates around 11.4 million tons of hydrogen per year. All eyes are on these green steel initiatives that are showing that, with the right resources, there is plenty of potential to decarbonize the U.S. energy, utilities and resources sector.

    A Swedish partnership, which includes Europe’s largest iron ore producer and IFS customer LKAB, has delivered the first fossil-free steel in the world. The steel was made with 100% fossil-free hydrogen instead of coal and coke—paving the way for a completely fossil-free value chain for iron and steelmaking.

    As experienced by LKAB, enterprise software can strategically support the shift to a more sustainably focused energy, utilities and resources sector. To thrive, new business collaborations and joint ventures must be agile and able to develop at pace, unencumbered by restrictive enterprise solutions; to achieve both these goals, cloud deployment and full supply chain sustainability is key.

    Manufacturing–Closing the Loop Requires Supply Chain Visibility

    The manufacturing sector is another major industry facing complex challenges—and opportunities—on the path to sustainability. The time is now for manufacturers to drastically change their linear approach of material, manufacture, dispose and move toward a circular economy of reduce, reuse, recycle. This means adopting reverse logistics methods enabling manufacturers to integrate more environmentally friendly practices into their manufacturing processes.

    According to a recent Deloitte op-ed, “Through the use of digital technology, manufacturers may already have a head start in their sustainability journey. In recent years, the implementation of lean processes using digital capabilities has boosted productivity, created safer workplaces and reduced costs.” For example, enterprise resource planning (ERP) software is helping manufacturers to develop and maintain the overall life of a product by using data and tracking of which areas need more sustainable practices. For instance, manufacturers embracing a circular model can rely on ERP software to help them maintain, recondition, recycle and support a product over an extended life cycle.

    And again, the software can incorporate environmental footprint management tools to capture the footprint of their product over its life cycle and present information that can be used for better decision support. By analyzing the percentage of post-consumer waste used in a product, manufacturers can then see where they can maximize the reutilization of components and preempt sustainability challenges.

    Aerospace and Defense—AI Predicting a Cleaner Future

    Every industry has a part to play in reducing carbon emissions, and the aerospace sector is no different, so it’s necessary and right that the industry is taking significant steps toward improved sustainability. Some of the key enabling technologies that will support this are highlighted by Global Data in its Thematic Research on ESG in Aerospace and Defense. The report highlights: “Electric aircraft, hydrogen-powered aircraft, and sustainable aviation fuels (SAFs) are key innovations that will shape the future of air travel. Improving social sustainability is vital for companies seeking to earn government contracts, increasing visibility and improving management throughout the whole supply chain will be vital.”

    From the Silver Spirit to the Spirit of Innovation

    Leading original equipment manufacturers (OEMs) are highlighted in the report for applying innovative thinking to solve industry emissions challenges. Rolls-Royce, for example, has already announced the first flight of its all-electric “Spirit of Innovation” aircraft and has committed that by 2023 all of its Trent family engines will have been proven compatible with 100% SAF.

    The Rolls-Royce Trent, a family of high bypass turbofans produced by Rolls-Royce, has been able to help airline customers automatically update predicted maintenance deadlines for every life-limited component inside their engines by using AI forecasting and digital twins through IFS aviation maintenance software. This forms a key part of the Rolls-Royce Blue Data Thread strategy; a digital information thread connecting every Rolls-Royce-powered aircraft, every airline operation, every maintenance shop and every factory.

    More effective maintenance will also translate into sustainability benefits. As the aviation industry moves toward a greener future, digitalization and predictive maintenance are important elements for the engineering side of the industry. By reducing the need for maintenance interventions, part replacements and overhauls, the use of energy and resources in manufacturing is reduced, and the emissions footprint of part and engine logistics is minimized.

    Turn to Tech to Sustain Green Pledges

    These are just three industries where technology is playing a pivotal role in achieving ESG goals. The case is clear: Sustainability initiatives can be accelerated by here-and-now technology such as IoT, AI, cloud deployments and more, not space age or future–focused solutions. The link between meeting customer demands, fulfilling environmental goals and greater profitability has never been closer. Technology will be a strategic business enabler to achieve all three.

  • Why Developer-First is the Future of AppSec

    Why Developer-First is the Future of AppSec

    DevOps culture and rapid cloud adoption mean developers are shipping code faster than ever and, in many cases, security teams struggle to keep up. To avoid relegating security to afterthought status, organizations must shift left and adopt a developer-first approach to application security (AppSec).

    Organizations that depend on software development need a solution that accomplishes two essential things to adapt and survive: Risk-appropriate security measures and an even distribution of functions across the stack. First, risk-appropriate security measures must be applied to all software before it is delivered or deployed. Second, they must adopt processes that enable security functions to be distributed across the development stack in a way that will not slow down the pace of development.

    Just as the entire development process starts with developers, integrating security should also start with a developer-first approach. Developer-first AppSec is the future; here’s how organizations can evaluate tools that will help them adopt a developer-first approach.

    Why Developer-First is the Future

    Developers outnumber application security engineers by as many as 100 to one, and AppSec functions cannot scale if security practitioners are the only ones responsible for security. This imbalance suggests that organizational leaders must better distribute security ownership across the developer teams that own the software asset.

    As it stands today, many companies expect developers to build and deploy software faster than ever before. Security teams often can not keep pace with software development, and they become a roadblock to software delivery. To meet project development deadlines and their key performance indicators (KPIs), developers tend to leave security teams behind. They do not have the time or the incentive to slow down development because application security tools or processes are slow and cannot keep up.

    Security and developers are at cross-purposes in today’s software development model. They are pseudo-adversaries because AppSec teams know what it takes to make code secure, or at least they know how to find vulnerabilities. And, on the other hand, developers need to write code that works well and meets the sprint’s deadline.

    Friction Between Teams

    This growing problem creates friction between these two teams. It’s not that security teams don’t care about the organization’s need to produce quality software quickly or that developers don’t care about security. It’s just that each team is measured and incentivized to achieve opposing objectives. AppSec programs must create a developer-first approach to building software quickly and securely to combat this growing problem.

    It is not feasible for organizational leaders to provide security engineers with the entire business or environmental context behind software applications. In this sense, AppSec teams are working with limited vision. They may not see how the software fits into the organization’s big picture or understand its priorities.

    With limited contextual understanding, security teams necessarily rely on developers to make decisions about acceptable risks. If left to their own devices to view the world through a security-centric lens, AppSec teams could get bogged down—potentially spending too much time enforcing security measures that do not apply to the task at hand.

    Since developers are building the software and know what the services are designed to do, security engineers must defer to a developer-first approach so that decisions about security issues will align with the business context and acceptable levels of risk.

    Finding a Developer-First AppSec Platform

    Below is a condensed guide to help organization leaders evaluate potential AppSec platforms. These questions will help identify a solution that will enable the organization to build a developer-first security program.

    • Will the solution flood the developers and AppSec team with more and more results, or will this help them fix the essential gaps?
    • Will the solution provide context to help developers focus their limited time on security work that matters, or will it end up wasting time on things that may not even present a risk?
    • Will the solution help build security measures as guardrails to prevent security issues in the first place?
    • Is the solution flexible enough to enable building custom application security checks and policies in the SDLC?
    • Does the solution provide flexible ways of communicating actionable security information directly to developers in real-time within dev tools like source control systems, CI/CD platforms or engineering task management systems?

    There are an overwhelming number of application security solutions on the market today, most of which are designed to create security alerts about every conceivable threat regardless of the business context of the software being developed. More tools are then needed to manage the identified vulnerabilities.

    What This Future Will Look Like

    AppSec teams must recast themselves as security facilitators providing expertise for solving complex challenges and maintaining oversight of the developer teams’ security efforts. Developers should own tactical security tasks, but the AppSec team should continue to be the experts in making risk-based decisions and driving security accountability across the business.

    Inside many organizations, application security is only beginning to become integrated into developer workflows. This integration creates both opportunities and challenges. As organizations strive to make AppSec an enabler that aids developers in creating secure software quickly, developer-first AppSec programs let businesses make their digital transformation journey safer and faster.