Category: DevOps Culture

  • Best Free Virtual DevOps Conferences to Attend in 2021

    Best Free Virtual DevOps Conferences to Attend in 2021

    New year, new beginnings and new conferences. It’s that time of the year again, to review and research upcoming events for 2021. Of course, given the ongoing COVID-19 pandemic, we’ll cover only virtual conferences. Here are the top five best DevOps virtual conferences you can attend for free. Just sign up, reserve your seat and attend, it’s as simple as that. 

    Why attend virtual conferences?

    Conferences provide wide visibility into market trends. As an individual, it’s impossible to know everything that is happening around the industry, especially the software industry. Conferences give us a chance to see things from different perspectives. Knowing how others are solving their engineering problems, what best practices they are using, how they deploy to production, etc., gives us the confidence to tackle our own problems. Demos, practical approaches and learning from top experts and speakers is yet another advantage for conference attendees. As the world has gone virtual, it has become easier to attend conferences via our laptops/desktops, right from the comfort of our home office. 

    So, let’s consider some of the industry’s best DevOps conferences this year.

    swampUP

    Date: May 25 – 27 (AMERICAS) | June 1-3 (EMEA)

    devops epicenter conference

    swampUP is one of the most recognized global DevOps conferences meant for DevOps practitioners around the globe. This conference puts you at the center of DevOps.

    It’s about all the stuff you ever wanted to know and understand from an engineering perspective. It empowers the attendees with actionable tips, patterns and use cases to drive DevOps initiatives with modern CI/CD, package management and security best practices. swampUP enables attendees to talk to the leading DevOps gurus live and benefit from their insight. 

    What is unique about this conference?

    The conference also includes three full days of hands-on DevOps training, keynotes, breakout sessions, real-world use cases with renowned speakers and brands and comprehensive, deep-dive tutorials. 

    DevSecOps Days

    Date: March 5, 2021

    devsecops days conference

    DevSecOps Days is a renowned conference that takes place in various cities and is organized around the latest security best practices in DevOps. Topics and talks center on adding security to DevOps. This conference aims to educate, share knowledge, evolve and explore DevOps and DevSecOps technologies and concepts, keeping security the focal point in software development. That’s what we call developing security as code. Volunteers from the local community organize the event. 

    What is unique about this conference?

    Attendees of DevSecOps Days will get a chance to talk to the industry’s leading security practitioners, and come away with insights about implementing security, automating security, overcoming challenges in DevSecOps and scaling security best practices. 

    DockerCon

    Date: May 27, 2021

    dockercon conference

    Docker is the tech that popularized container technology. If you are a DevOps enthusiast and want to know more about working with container tech, DockerCon is the conference for you. So much is happening around Docker these days, and it is worth your time to attend the event. DockerCon is an industry-recognized conference that offers:

    • Technical demos of container technology products and innovations from Docker and their partners. 
    • In-depth, real-world Docker use cases and examples of how others are using it to streamline software development. 
    • Technical sessions from Docker experts and captains and notable leaders from across the industry.
    • A chance for the community to come together and connect with collaborators around the world.

    What is unique about this conference?

    The conference is for everyone from beginners to experts. This is a great opportunity to hang out and chat with Docker experts and Docker captains. 

    DevOps World

    Date: September 22-24

    DevOps World 2021 conference

    DevOps World  is one of the premier DevOps events, bringing together DevOps thought leaders, software practitioners, developers, contributors and the entire DevOps ecosystem in one place. What else can attendees expect? 

    Aside from interacting with industry experts, it provides attendees the opportunity to learn, share, explore and help mold the future of software development and delivery best practices.

    What is unique about this conference?

    Attendees get hands-on experience with various new DevOps technologies and can make new connections in the industry.

    cdCon

    Date: June 23 – 24, 2021

    cdCon conference

    cdCon is a two-day virtual conference on delivering software with security and speed. It is a global conference featuring continuous delivery thought leaders, industry experts, practitioners, open source experts and developers delivering world-class talks. Attendees get to be part of the conversations driving the future of software delivery, enterprise leadership and open source technology.

    What is unique about this conference?

    cdCon is the best place for networking with industry thought leaders. Attendees will learn the latest trends in software delivery from experts. Meet and explore open-source technologies with other practitioners and enthusiasts. 

    DevOps India Summit

    Date: August 27-28, 2021

    DevOps India Summit conference

    One of the APAC region’s top conferences is DevOps India Summit.

    The conference theme this year is “Adapting to Industry 4.0 with DevSecOps, SRE, AI/ML/IoT and Data Science.” This conference focuses on broad topics related to SRE, data science and DevSecOps. It emphasizes Industry 4.0, which refers to the fourth industrial revolution focused on the rising trends in automation, IoT, big data, AI and cloud computing technologies.

    What is unique about this conference?

    The conference features industry leading speakers and panel discussions, and it enables attendees to interact with sponsors, attend yoga sessions, a party with a DJ, fireside chats and much more. 

    Let’s make 2021 an amazing year for DevOps by attending some great conferences, learning new technologies and adopting them into your organizations to solve engineering problems. Happy DevOpsing!

  • Transforming Your Digital Transformation

    Transforming Your Digital Transformation

    Change is difficult, so most companies pull the bandage slowly, hoping to avoid the hard, painful part – especially with regard to digital transformation. But in the corporate world, cautious change inevitably leads to entropy. Progress gets made in one department at a time, at the expense of others. Leaders turn over, priorities shift, plans fall apart and the desired results never happen. The bandage never really comes off.

    I see this happen a lot in companies that say they want to transform their digital customer experience – across all industries we work with. The board or the shareholders might not embrace a truly digital-first strategy or understand what the end-state transformation goal actually is. Instead, they end up digitizing the past, refreshening a longstanding brand with a new storefront in a doomed effort to maintain business-as-usual.

    These companies start with a well-meaning internal innovation team. They preach agility, then spend months researching the problem and consulting internal stakeholders, all the while trying to stay close to their comfort zone of existing practices. They write reports, they create roadmaps, run design-thinking workshops and come up with a solution … and then throw it over the wall to IT and wash their hands of it. Nine months later, the team is busy executing the new plan, but, with no internal champion, it can’t innovate. Due to the chaos and complexity of the project, the company burns through its budget and the project becomes a sad statistic. In fact, 95% of corporate digital transformations fail outright or produce diluted results, according to one recent study.

    Shrink the Transformation Timeline

    If a company really does want to digitize for the future instead of the past, it needs to turn that approach on its head. It needs to drastically shrink the timeline for digital transformation, which means starting with a digital operating model and putting the end clearly in sight.

    The result is a digital operating model that continuously delivers and measures value. It’s not a project. It’s not a product. It’s an operating model that puts teams close to the market and customer, and makes them responsible for finding and delivering innovative, high-value customer experiences.

    Get the Team Right

    This approach requires a team that knows how to embrace ambiguity and takes responsibility for creating the solution, not just designing it or building it – both of which fail when done in a silo.

    It needs to be a small, multifunctional team with the authority to implement things quickly, with the fewest possible hoops to jump through along the way. And when the inevitable organizational friction arises, the team and its goal needs to be seen as a transformation opportunity, not a barrier to be avoided.

    Companies assume they can do this work in-house, but it’s next to impossible to form the right internal teams because, typically, they don’t have enough experience with this model.

    These internal teams don’t quite have the right training for the job, but more importantly, they don’t have the right permission and agency. Some are risk-averse or can’t break through organizational silos. Some simply aren’t given the agency to do the work. Organizations with a lot of experience evolving, that give their employees this agency as a matter of course, might have success in-house. But it’s a tough ask for older, established firms.

    Don’t Design – Execute

    To their credit, many companies see this and outsource their transformation leadership to a consultancy firm. But you can’t outsource a transformation. You can’t teach a transformation. You need to implement transformation.

    Both internally and externally led transformations fail to grasp what really makes transformation work: agency and delivery.

    Instead of researching, planning and announcing, the team needs to roll up their sleeves and start executing. They have to drive the evolution of the company’s software toward the identified goals, break down any organizational silos or challenges that get in the way and deliver – quickly. They have to work together with the IT team, and anyone else who needs to understand what they’re doing, but execution needs to be top of mind at all times.

    The solution isn’t insourcing or outsourcing. It’s a joint venture, where the transformation is within the company’s core business unit, working together with a consultancy or partner to complete the digital transformation faster by focusing on a smaller slice of the business. With this foundation, an organization can be pulled through a rapid transformation in nine to 18 months, rather than three to five years.

    In fact, in under six months, a tiny transformation team of five to seven people can scale up to a transformed organization of 120 people, quickly delivering the desired digital-first customer experience. All it takes is a team that has done it successfully, multiple times. And the best thing about this is that transformation is measurable by the ability of teams to continuously deliver and evolve experiences across multiple digital channels.

    Digital moves too fast, and is too complicated, to be managed by traditional processes and approvals. If it does, whatever change your company sets out to enact is at risk of being dead on arrival. Agency plus delivery is the formula for a successful digital transformation.

  • The Chaos Mindset: Teaching Your Code to Cope

    The Chaos Mindset: Teaching Your Code to Cope

    Chaos engineering sounds alluring and exciting—it’s fun to experiment, right? But what some misunderstand about this approach is that it’s not about moving fast and breaking things. It’s about designing and introducing disruptions in the software production process that tests the resiliency of the code, much like crash testing in the automotive industry.

    If you think about it, this is the logical extension of the way developers like to think anyway: we’re designing software and systems for the real world. Shouldn’t they be able to handle real-world situations?

    To design effectively for the real world, developer teams don’t necessarily need to become chaos engineers. This isn’t about training for an entirely new set of skills. Rather, it’s about adopting a chaos mindset—a set of systems and perspectives that lets your team engage in controlled experiments to deliver products that can cope with whatever end-users throw at them.

    So, how do you know if your team is ready to adopt chaos engineering principles? And what should you do to help them?

    Chaos Engineering: The Basics

    This approach is all about using distributed systems as a “safe” experimentation environment, so that dev teams can ensure their products will withstand unexpected turbulence in production. Netflix engineers get the credit for coining the term, based on their experiences developing for Netflix on AWS.

    The fun part of chaos engineering is that it lets developers find loopholes in existing systems that allow them to develop for resiliency. By running experiments within existing platforms in a distributed environment, or within a sandbox development environment, teams can supervise and control the experiments without impacting end users.

    Some applications, such as transactional applications in finance or trading, should not be disrupted in production, and developers should test in a sandbox environment instead. Chaos engineering is very easy to put in place if your team uses containerization techniques already – which should be part of any modern DevOps CI/CD process anyway. It is common to setup a DevOps CI/CD pipeline to run a battery of tests on an application before it gets to the publish step. Within that testing step, you can easily add some disruptions; some may be harder to put in place and require a more elaborate environment.

    Dev teams can use existing environments and systems to show each other how unexpected issues could impact production of a software product, allowing them to collaborate and solve the coding mystery before it slows or stops production entirely.

    Applications designed by engineers are subject to common issues, whether the applications run on-premises or in the cloud. We can group these issues into the following categories: hardware limitations, sub system failures, external system failures and software bugs. While we could define more categories, these are the main ones, and the ones that are easy to test.

    Chaos Mindset: The Tao of Chaos

    Like Agile, chaos engineering is more than a set of activities and workflows—it’s also a state of mind. Your people and your culture must be ready and able to adopt chaos principles, as well as chaos processes.

    For the DevOps leader, adopting a new mindset might sound a little, well, vague. But this shift is based on concrete actions, not just philosophical musings.

    Consider an example from the world of cloud infrastructure: a mission-critical application that is hosted within a cloud service could be at risk for failure if, say, that cloud service is centralized in a single location, or within a limited number of microservices within the cloud infrastructure. But if the app is hosted in a distributed way, you can create greater opportunity for application-level availability and resilience, and you can test for that resilience within the existing production environment.

    This kind of distributed architecture isn’t brand-new for most enterprises, and, therefore, the process of developing applications in way that tests for availability in a variety of infrastructure scenarios also shouldn’t be a foreign concept. As a DevOps leader, you can build a culture of resilience-centric thinking by empowering your teams with the tools they need to adopt chaos-style testing, and then showing them how to build that thinking into every sprint and every standup.

    It takes work to train your teams, but you don’t have to do it alone. Netflix’s Simian Army has tons of tools and guidance; Facebook Storm and Amazon Gameday, both war room-type experiences to simulate failures in the cloud, also have helpful examples and ideas.

    Chaos Engineering in Real Life

    Deploying a chaos-inspired experiment strategy isn’t easy. Start with a simple set of operating principles as a guide for designing your chaos strategy:

    • Hypothesis: How we think the system should work, so we know when it doesn’t work.
    • Scenario planning: What are the possible failure events or crisis points that you know can happen in the real world?
    • Set up the experiments: Design and put in production the tests that measure the code’s strength.
    • Configure monitoring: Monitoring will help test the hypothesis and help you see, in real time, the impact and resolution of the disruption.
    • Make the experiment run itself: Automating the tests lets you continuously assess both performance and resilience.
    • Contain the experiment: You don’t want software that’s already out in the wild to get disrupted by your lab experiments, so make sure to design with guardrails in place.
    • Shut-off switch: Even when contained, have a shut-off switch to prevent the disruption from further impacting some users.

    The fundamental irony of chaos engineering is that it’s anything but chaotic. It’s a disciplined approach to breaking things that lets your team get smarter, faster, about how their products and applications will work in the real world. It’s a strategy that harmonizes beautifully with Agile practices. And even though it won’t make your apps bulletproof, it can definitely help you dodge the bullets of failure with greater grace and finesse.

    You must look at the software architecture as a whole to find the most appropriate chaos engineering testing tool for each portion of the architecture. There isn’t a single tool that can test all the components of your architecture; you will have to use different tools for different parts – and don’t forget monitoring! It’s only through proper monitoring that you can assess how the software is behaving in response to a disruption.

    Sometimes, the best approach, and the simplest one, is to build some chaos engineering steps into your software so that the software itself can be disrupted given specific inputs without exposing a security weakness in an obvious way. This is very much like how cloud applications create heartbeat and health check endpoints. We like to think about chaos engineering as a great complement to unit testing and integration testing, except we run it on production systems.

  • Citizen Development Program: Selecting the Right Use Cases

    Citizen Development Program: Selecting the Right Use Cases

    The COVID-19 pandemic forced us into new ways of working that demanded a truly digital enterprise. Digital enterprises require we deliver applications for our everyday tasks and processes with unprecedented speed. Our traditional development resources – our professional developers – and traditional, professional code development environments simply cannot meet the demands from our lines of business.

    Citizen development

    The rapid adoption of low-code application platforms and the ability to use more readily available “low-code developers” partially closes the demand-supply gap by improving app delivery velocity for IT organizations. But velocity is only half the battle. Because our app development teams (pro and/or low code) can be so focused on the application itself, they may not fully understand the larger context around that application, the business processes they are attempting to digitize or how to connect with the process owners to gain that understanding. We become faster at app delivery, but not necessarily more agile. True business agility comes when we push app development to the edge; out into our lines of business and into the hands of “citizen developers.”

    citizen development

    Now let’s all take a deep breath, pause for a moment, and accept that citizen development is not the panacea for all our digitization needs – nor is it the beginning of application anarchy. A well-executed citizen development program can dramatically improve delivery velocity and business agility if organizations make good decisions in three key areas: 1) selecting the right use cases for citizen development; 2) enabling and empowering our citizen developers; and, 3) establishing citizen development guardrails that protect our organization.

    Before exploring the key decisions, it is important to note a few elements that are consistent across successful citizen development programs:

    • Adopting a Low-Code Application Platform (LCAP) – LCAPs benefit IT developers (both professional and low-code) but are critical to citizen developers. Teaching Java to your lines of business is what’s called a distributed development model – and that’s a whole different article.
    • Embracing the Journey – A citizen development program is a learning process for both the IT organization and the lines of business. Start focused, learn from the experience, adjust the approach and expand the reach.
    • Marketing Success – It is important to raise awareness of the program by telling the company about both the successes and the lessons learned – be candid and clear. People feel good about successful programs and rally around them.

    Selecting the Right Use Cases for Citizen Development

    We want to set up citizen developers, and the citizen developer program, for success, which means matching the business need to the citizen developer skillset.
    We need answer the following questions regarding line of business needs.

    • What business use cases are a good fit for our LCAP?
    • What technical requirements are a good fit for our LCAP? What technical requirements are not?
    • What types of applications in our enterprise are a good fit for citizen development?
    • Are there lines of business / departments that could benefit more than others from empowering citizen developers?
    • Are there specific risk, compliance, security and legal (RSCL) mandates that need to be addressed?
    • Are there other core enterprise systems that need to be considered for certain use cases?
    • Are there legacy technologies and/or is there technical debt that should be targeted?
    • What is the potential return on investment? How quickly can we start achieving that ROI?

    The answers to these questions are not binary. These questions, and others unique to each company, provide a filter to vet – and possibly score – use cases to determine suitability for a citizen development program.

    Just as important as selecting the right use cases is finding the right citizen developers. We need to answer the following questions about any potential citizen developers.

    • Will we have different categories of distributed / citizen developers? Are those categories based on skill level, organization and/or access?
    • Have we identified the aptitude and attitude characteristics of a good citizen developer?
    • How will we recruit and incentivize developers to join the program?
    • What is our value proposition to the citizen developer’s manager? Why would they support allocating some portion of their resource(s) building apps?

    In the early stages of a citizen development program, the most successful programs tend to prioritize the right developer over the right use case. A “high fit” developer delivering a “medium value” use case is a better bet than a “low fit” developer attempting a “high value” use case. Early wins matter.

    In part two of this series, we will explore enabling and empowering our citizen developers. We have now identified the right use cases and the right citizen developers, so let’s set them up for success.


    This post is the first of a three-part series offering real-world insights on delivering business value from citizen development initiatives.

  • A Pragmatic Approach to DevSecOps

    A Pragmatic Approach to DevSecOps

    In response to market and competitive forces, many companies are using DevSecOps to develop higher quality and more secure software. Whether that software is their own product or is a component of their product, quality – and especially security – have become required rather than optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can, and has, caused significant disruption.

    Barriers to DevSecOps Adoption

    The main barrier to the transition from DevOps to DevSecOps is organizational rather than technical. Many companies are already employing special security teams tasked with ensuring applications are secure and that policies are being followed. However, they tend to act as gatekeepers to the release process – nothing gets released without security testing. This approach is prone to be “too little, too late,” as the security team is usually involved near the end of the development life cycle. Attempts to “test in” security rarely succeeds. Security needs to be built in from the start; “shifted left” so that security is fully integrated into the process from the start. Let’s break down these barriers:

    • Lack of motivation and awareness:  There’s a lack of awareness about security issues, and about the risks and impacts security vulnerabilities pose to the organization in terms of liability and reputation. Vulnerability statistics make it clear that many companies are still not taking security seriously enough. This indifference remains, even when 63% of companies had, or nearly had, vital data breaches in 2019 and each breach cost an average of $3.9 million to deal with.
    • Distrust: Lack of trust between teams is expected in most organizations, but it’s particularly problematic between software developers and security teams. Developers view security as impeding their success, and security teams view developers as incapable of delivering secure software.
    • Poor Perception: The prevailing view of security is that it’s difficult to implement and somebody else’s problem. If security teams are solely responsible for security, then it’s easy for developers to delegate to them. Companies often think that security can be tested into the product at the end of development – with disastrous results. Vulnerabilities discovered at this late stage are more difficult to debug, with subsequent impacts on time-to-market, budgets, product quality and reputation.
    • Gatekeeping: The security team sometimes acts as gatekeepers of release candidates, which is a source of friction between developers, testers and security experts. Placing security as a last, QA-like step before delivering a release is too little, too late. Developers also don’t like other teams imposing restrictions on their work, which is an issue when trying to put security controls, like secure coding practices, in place.
    • Lack of integration: Without integrating security practices and tools through the entire development process, security improvement initiatives have trouble getting off the ground. In fact, the key tenet of DevSecOps is to integrate security practices into each phase of development.

    These barriers might seem daunting, but it’s not unlike other corporate cultural shifts. Security teams need to delegate aspects of security to development teams and integrate secure practices as early as they can in their work. Developers need training and understanding of how critical security is to their work. Developers already have an appreciation for safety and quality, but lack some of the basics of good security practices.

    It doesn’t need to be this way. However, removing these barriers won’t happen overnight, so a practical and gradual approach to improving security is needed.

    Easing Your Way into DevSecOps

    Transitioning to a more secure software development process across an organization rarely works when done with a “big bang” approach. There’s often lack of buy-in from the teams, and general resistance to change when new approaches haven’t proven themselves. The cultural barriers to adoption remain, and the initiative fails. As with any large task, it makes sense to start small; to learn and adapt before expanding to more teams. The move from DevOps to DevSecOps should be organic.

    Start Small

    The alternative to the doomed “big bang” approach is to start with a small, motivated team, where it’s possible to implement new practices from the very beginning of a project. By keeping the scope, and thus, the technical and business risk, of the project smaller, it is possible to allow time for learning and adjustments along the way. Think of this as an incubator project, where the results are analyzed and used to evaluate gains, losses, what went right and what went wrong. This team can learn, and then teach the larger organization what works and what doesn’t. Importantly, they set the standard for how to approach DevSecOps, and kick off the organic growth needed for a smoother transition.

    Starting small extends to the use of new tools, as well. It’s one thing for a small team to adopt new technologies, but they can be quickly overwhelmed. Static application security testing (SAST) tools can produce a lot of information. It’s important that initial projects concentrate on high impact, high probability vulnerabilities, first and foremost. It’s easy to get bogged down in the details, and discipline is needed to focus on the highest impact, and to get the most ROI out of new tools.

    Start at the Beginning (Or as Early as you Can)

    This is where “shift left” plays an important role in the transition to DevSecOps. A small team can introduce new techniques without a large initial impact on productivity. They can also start integrating security from the beginning, right at the concept phase of development. They can introduce new tools, and become proficient at using them. It’s at these early stages where the payoff is the greatest. Finding and fixing possible vulnerabilities, and adopting more secure design and coding practices, greatly reduces the downstream impact. It’s not hard to justify the effort, when security attacks and data breaches in production systems can cost millions in fixes, downtime and reputation.

    Measure Success

    The interesting thing about measuring DevSecOps success is looking at what isn’t there; security vulnerabilities and potential software weaknesses. To understand how well a new DevSecOps transition is working, it’s important to have a baseline of vulnerabilities that exist in your other applications. For example, how many vulnerabilities were discovered during security testing? How many vulnerabilities made it into shipping products? If these statistics are known, then it’s a case of measuring how well the new project does versus the baseline performance.

    Other metrics are important, too, such as measuring the number of vulnerabilities detected, identifying those that are true risks and those that were removed through corrective action. SAST tools provide information on a per-build basis, so it is possible to look at trends over time. You can evaluate the DevSecOps process in terms of vulnerability trends over time; are they converging to a goal? How quickly is the convergence?

    The ultimate measurement of success is a more secure product and, ideally, security testing at the later stages of development should find fewer vulnerabilities than in the past. After building in security and starting at the beginning with a shift-left approach, vulnerabilities are caught sooner and removed more quickly.

    Start your DevSecOps Transition

    The critical time to detect new security vulnerabilities is as soon as developers write new code (or test cases) before it’s submitted to a build or software control system. It’s also critical that tools work in your favorite development environment (be that VI, Emacs, Microsoft VS Code or Visual Studio, or any of a number of Eclipse-based environments). It’s at this point where SAST tools shift security improvement via automation to the earliest point in the development cycle. Finding and fixing vulnerabilities here is less risky, cheaper and easier.

    Equally critical is establishing an initial baseline inventory of your third-party software assets, whether that is open source, reused internal code from other projects and/or third-party commercial software. This is done at the very beginning of the project, about as shift left as it gets! Software composition analysis (SCA) is critical throughout the development process since the open source and third-party software that you depend on is likely to have updates and introduce new security threats over time (including after you release the product).

    Early adoption of SAST and SCA tools can have many benefits as part of your DevSecOps adoption. These tools used in conjunction with a security “built in” approach make this transition easier:

    • Improve security awareness by exposing vulnerabilities in existing code, third party software and newly developed code. SAST tools provide all the necessary information to fix potential vulnerabilities, but also provide an explanation of the severity and risk. Developers get more experience with the types of software weaknesses that lead to vulnerabilities, and learn to avoid them.
    • Illustrate ROI by measuring success, and have a goal in mind. Eliminating just one serious vulnerability justifies much of the investment. However, communicating this ROI is important, and needs to be put in the proper context of how costly and risky vulnerabilities are once a product is released.
    • Remove gatekeeping so that developers and the security team are working together. Security teams provide the security controls that developers need to follow with a “trust, then check” approach. Developers learn more about secure practices over time, and integrate that knowledge into their existing workflow. In the end, there is no security team gate at release, and all members of the team know and understand the state of the product.
    • Integrate security practices into software development gradually, starting with a small team and small project. As experience is gained, these teams train the rest of the organization on best practices.

    DevSecOps From the Ground Up

    DevSecOps is a way to build security into an application, and the transition from an existing CI/CD and DevOps process is made easier with the right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. A “start small and start early” approach is recommended where new techniques, processes and tools, such as SAST and SCA, can be integrated with less downtime and cost.

    Most importantly, you need to decide what the success factors are. Measuring success and the ROI of the effort is needed to grow DevSecOps organically within the organization. Tools and automation provide the data needed to show progress, but communicating the ROI needs to be done in business terms. In the end, success results in a more secure product, and reduces your company’s exposure to data breaches and cyberattacks.

  • TechStrong TV: How to Build and Refine Your DevOps Skills with OpsCompass

    TechStrong TV: How to Build and Refine Your DevOps Skills with OpsCompass

    The role of DevOps is constantly evolving as new technologies and trends keep emerging and reshaping the business. It is critical for DevOps engineers to continuously learn about the latest tools, best practices and technology, and be able to adapt to change.

    There are many ways for DevOps teams to refine their skills in order to become high performers. In this TechStrong TV interview, OpsCompass Co-Founder and CTO John Grange and Engineer Amy Wall join Mitch Ashley to discuss upskilling and how to build and maintain your software, development, cloud and technology skills in the fast-paced world of cloud. John provides a look into the future and where our skills need to move next, while Amy graciously shares her journey into software development and some valuable lessons learned along the way.

    OpsCompass is a leader in Cloud Security Posture Management (CSPM) offering an enterprise SaaS product that provides security and compliance management in cloud platforms.

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

    Transcript

    Mitch Ashley: I have the pleasure of being joined by two really interesting folks. We’re gonna have a great conversation, I’m looking forward to this today—Amy Wall, who is an engineer with OpsCompass, and then John Grange, CTO with OpsCompass. Welcome to you both. Good to be chatting today.

    Amy Wall: Thanks. It’s great to be here.

    John Grange: Yeah, thanks for having us, Mitch.

    Ashley: Absolutely. You bet. Let’s do this—how about if we have you both introduce yourselves. Maybe, John, if you go first, introduce yourself—tell us a little bit about OpsCompass and what the company does, too, and then hand it over to Amy and you can tell a little bit of your background.

    Grange: Excellent. Again, I’m John Grange, I’m co-founder and CTO of OpsCompass. OpsCompass is a really powerful SaaS product that does security and compliance management in the cloud. And what that really means is, you know, we’re really helping DevOps teams, CloudOps teams get the visibility, have the intelligence and the control they need to run a successful cloud operation.

    You know, my background really plays a lot into what OpsCompass does and kind of the cloud security space. I’m a career entrepreneur. I’ve co-founded a number of companies, from top five global Microsoft ASP.NET hosting provider to a health and wellness SaaS product. So, I have a lot of experience, and our team has a lot of experience in kind of the infrastructure security compliance space. The cloud, obviously, was a big game changer, because a lot of the things that we used to deliver through a variety of different software products or hosted solutions inside data centers, we can now build software to easily do it in the cloud.

    Ashley: Mm-hmm.

    Grange: So, that’s kinda how I got into the business through kind of that hosting and infrastructure space, and now here we have OpsCompass, which is leading the charge with helping customers with their security posture, their compliance—all these different aspects of running or having a well-run cloud.

    Ashley: Sure is a fun and interesting space to be in and I think we’ll get into that, too. Amy, how about you? Just a little bit of introduction, and I think we’re gonna get into more of your story, too.

    Wall: Sure, yeah. I’m Amy Wall, I’m a DevOps engineer at OpsCompass. I have the pleasure of working with John Grange, working under John Grange, and kind of forming this exciting new product, OpsCompass. And so, I’m kind of—where I’m at in my career and on my cloud journey is really in a space where I’ve kind of come to it from a software engineering perspective. I’ve been a software engineer for years now, and you know, been going through the steps and kind of getting the skills under my tool belt, upskilling on the cloud path so that I can become a full DevOps engineer for OpsCompass. So, really been learning with OpsCompass and growing with OpsCompass as they sort of kind of figure out and carve out their space in the cloud infrastructure.

    Ashley: Mm-hmm. Isn’t that nice when you work with, you find a company that’s really compatible with what your goals are and what you wanna learn with where you are in your career? That’s awesome.

    Wall: Huge. Absolutely.

    Ashley: Well, that’s a little bit of what we’re gonna talk about, the upskilling is kind of a general, I guess, tag, label for it. We’re gonna explore a little bit, and you volunteered to share your story of how you got into software and how you’ve evolved into software in the cloud and DevOps, and then maybe take a look forward, you know? We’re here in December thinking about getting through the holidays and everything else going on and thinking about the new year. Maybe John can share with us some ideas on that, too, and we’ll explore some of those things about how do we prepare ourselves for the next things that are coming.

    So, let’s start with your story. I’ll let you tell it however you’d like, but you know, maybe how did you get into software?

    Wall: Sure, yeah. I always like to joke that if I told my 12-year-old or 14-year-old self that I was a software engineer or DevOps engineer, I would not believe it, at that age.

    Ashley: [Laughter] 

    Wall: But yeah, I really didn’t have a super traditional path. You know, I was a Humanities major in college. I left college and I became a content editor and then later a project manager in the marketing space. And I really enjoyed it, but kind of along the way, I got exposure to various technologies, I got a little exposure to programming, I got some exposure to IT, and over a few years, I realized that I just loved it, and that’s what I really wanted to do. And my favorite days at work were the days where I was able to kinda solve, you know, software problems or technology problems, whatever.

    So, I did, like, a total career 180 about five years ago and took a U-turn, learned how to code, and my first job after that was at OpsCompass or a subsidiary of OpsCompass that OpsCompass then later purchased. And so, I’ve been working in software ever since as a software engineer. And it wasn’t until OpsCompass a couple of years ago, I think two or three years ago, when I was able to join that amazing team of engineers where I started to really ramp up my cloud journey. You know, I had become pretty strong in the fundamentals of software engineering, and you know, I’d become really used to kind of the experience of learning on the job. You know, that’s kinda the nature of software engineering itself, and it’s the nature of DevOps, and it’s really the nature, I think, of cloud, because there’s new technologies coming out all the time and everybody’s kind of learning a way to navigate the space a little bit better all the time.

    And so, yeah, I just kind of figured out how to learn on the job and continued learning on the job, and now I’m surrounded by world class cloud engineers and John Grange, our CTO, who have excellent mastery in this space, and it’s been a blast to kind of learn together with them and figure out how this entire ecosystem works.

    Ashley: Wow, very complimentary of the company. Be careful, John, she may have an ask.

    Wall: [Laughter] 

    Grange: Yeah, I know. This is—this is great. No, but in all seriousness, you know, just from our perspective, even, having somebody who’s a rock star at this point, like Amy, it’s hard to find cloud expertise. And you have to be able to find people that are interested in growing, willing to grow, have that interest—like, it sparks that fire, so that then you can enable that and you can grow a lot of your own expertise, and it’s a really powerful thing, but I think it’s something that a lot of companies, particularly like us, have to do today to stay around.

    Ashley: Mm-hmm. You really do have to invest in people and give them the right, whatever ways that they learn, the right opportunities. You know, there’s also the person side of it, too. One of the best things I learned in college from a Computer Sci professor was, he said, “Everything you know now is gonna be obsolete in a year, so you need to keep learning. You have to have a thirst, just a hunt, a desire for learning just to keep—keep going.” 

    And it seems like that’s consistent with what your journey’s been, Amy. Maybe talk about what the evolution from some of the technologies you started developing software in to getting into cloud—what kind of things are you doing today?

    Wall: Sure, yeah. So, I started where I think a lot of new coders start is, I started on Ruby on Rails, and I used it for years, and I actually still use it a lot of the time. But yeah, I started there, and then I worked in the consulting space for a few years where I was able to kind of bring to life a lot of customers’ ideas, clients’ ideas, and I loved that, that was really exciting.

    And so, from there, I kind of have just begun dipping my toe a little bit in all the cloud has to offer. I still have a ton to learn. But our infrastructure has a number of different resources in various clouds. You know, I get to work with AWS, I get to work with Azure, I get to work with Google Cloud Platform. So, you know, any given day, I could be working on any one of those technologies. I could be spinning up Lambda, I could be debugging something in Typescript or JavaScript, whatever it is.

    But yeah, it was definitely a journey along the process, but we have a team, like I was kinda mentioning before, we have a team that we all, I think, feel that we’re in it together a little bit. And so, there’s a great energy where I think we kind of all learn together, even the master practitioners will continue to kind of get new certifications as they come out, will continue to offer advice, and will continue to learn.

    And so, I’ve never really felt like I was the baby in the room, so to speak, [Laughter] or that I was less skilled than anybody else, per se. I kinda just felt like—okay, we’re all making ourselves better, sharpening our skills, getting better all the time, so.

    Ashley: Especially, it can be an advantage in a technology area that’s relatively new, because everybody’s learning it, right? Nobody’s been doing it for 20 years or whatever makes you an expert.

    I’m curious, too, did you find mentoring, kind of learning from peers, things like that were helpful, since everybody’s learning at such an accelerated pace moving into the cloud, whether it’s on the UI side or on the software infrastructure side?

    Wall: Hugely, absolutely, yeah. Our lead architect, Nick Allmaker, is an excellent mentor for us. You know, his knowledge never ceases to amaze me, and he’s really, really helpful. He’ll always—he’s always willing to take some time out of his day to spend a couple extra minutes on a pull request or help you figure something out.

    But, you know, even earlier on in my software engineering education, I remember having a teacher who told me, “Always T.S., try it and see.” [Laughter] And I think I mentioned this in a blog recently, but that’s been hugely helpful to me as I’ve moved into this space, because you know, for me at least, in learning cloud and in understanding the ecosystem, tutorials online can really only take you so far. Sometimes, you just have to, you know, go in there and spin up a Lambda, you know, spin up an EC2, and figure out what’s going on, play with it, move it around a little bit.

    And so, I definitely—that’s a big insight that I’ve learned is that just get in there, try it. A lot of the clouds, I think all of them, in fact, have a free trial where they give you a little bit of free canister to play with at the beginning. I used that for all of them, absolutely, and you just, you know, spin up resources. 

    And I think in addition to that, having a third party like OpsCompass where you have kind of that visibility into every single resource that you have going on in every single cloud can be super helpful to someone. Obviously, helpful for experts and helpful for people who are in the cloud security posture management space, but also helpful for people like me who are learning and who don’t really understand or who are kind of putting the pieces together of what changes do what and what resources are like others, how similar is an Azure function to an AWS Lambda, and having that kind of visibility into all of your clouds and all of your resources can be hugely helpful.

    So, you know, I kind of had that advantage at OpsCompass where, you know, I’ve definitely had a leg up, for sure, in being able to kinda learn this stuff.

    Ashley: Mm-hmm. Opportunity is everything. Sometimes it’s self-created, and sometimes it’s the situational company, et cetera. I’m curious, John, what’s your perspective on, because you’ve, you know, you’re obviously probably in a little different place in your career, but as yourself and folks you’ve worked with, what are some of the mentoring and kinda helping others advance in their careers have you seen to be really successful—either for yourself or people you’ve worked with.

    Grange: Sure. Well, you know, there’s a couple things that come to mind, and one of them Amy just mentioned, being able to go and mess with something, being able to go out into the cloud and play with the resource and have kind of both the curiosity, the time, the capability to be able to go do that is a really powerful thing. And in the cloud, when all of these services are changing and being—you know, there’s a couple hundred different ones on AWS—there’s literally something new every day.

    Ashley: Mm-hmm.

    Grange: So, I think that that’s a big part of it. The other thing that I learned early on from mentors of mine that I also try and share with the team is that when there’s these big trends—you know, cloud is an example, but then also, you know, some of what you see with big data and AI, et cetera, there’s the sort of application top layer trend that’s all of the robust sort of user applications for those technologies. 

    But for those to actually come to fruition and for that trend to really be powerful, there’s gotta be all this plumbing underneath that isn’t as—it’s not as glamorous and not everybody thinks about it, but as those spaces burgeon, it’s not just the mobile app that’s using AI to really change kind of directions in navigation, it’s the whole industry of sort of the infrastructure beneath that needs to serve those sorts of trends and applications. And those end up being great places to go and learn about. And there’s tons and tons of opportunities, sort of, in the wake of those big trends and the leading kind of applications and companies.

    So, I always like to, even in our product, you see a little bit of that, but I even try and tell, you know, folks on our team that we need to be looking at things that way, as these trends are big. What kind of plumbing do the customers need? What are the dots that need to be connected? What’s the kinda unglamorous thing underneath that everybody’s gonna need that we can learn a lot about and solve the problems around?

    Ashley: I’m curious, Amy, have you seen that? Has that been consistent with your experience, too?

    Wall: Absolutely, yeah. I think—yeah, per what John was saying, I do really think that there is kind of an ecosystem to cloud and we’re trying to always stay on top of it, in front of it, you know, figure out what’s going on with it and view it from kind of like that 30,000 foot view, so we can really understand it as a whole picture.

    So, yeah, I think there’s a great knowledge share, for sure, and I think that’s hugely important to figure out where is this going, what is going to be happening in 5 years, in 10 years? Where do we need to start working now so that we’ll still be relevant, we’ll still be making sense at that time? And it’s not always easy to guess, but definitely, there’s a lot out there in the industry that you can kind of get a feel for that.

    Ashley: I think we’re in violent agreement. [Laughter] The best developers I’ve worked with really knew it from the operating system, the whole software stack, the network—you know, not an expert in every piece of it, but knew how it all fit together and how to make it all work and kinda hum and get to the performance that you need or make the right decisions on how you want to, the architecture you want to use and what parts you do and don’t want to use.

    You know, another thought—you may have mentioned this in your article, too, Amy, and I’ll put a link to the article in the description—open source is another fantastic resource. You talked about getting free time on cloud services and using sampling software—it’s a great place to watch how software’s built, in a little bit different way, in an open way, open community, but using that as well can be super fantastic. And by the way, everybody’s using open source in their products and their IT systems, their applications. And so, the more you know about it, the more you can leverage it, right?

    Wall: Absolutely, yeah. I love—I just, I love the idea of open source. You know, I think it’s—I love the ideology of it. I think it’s fantastic, and certainly, we do use it. And I think open source is the place where a lot of people kind of go to exchange ideas in the cloud space right now. You know, we have a lot of—Twitter, for example, Tech Cloud Twitter is always really exciting and people…yeah, I think people are making some really interesting things right now with open source, and it’s an exciting place to be.

    Ashley: So, let’s kinda turn the lens from, you were talking a little bit about your background, John sharing a little bit of his as well—turn the lens to kinda thinking forward, right? Things have changed. It’s a different world in the last nine months, for sure, and a lot of organizations have accelerated digital transformation projects. We’ve got data in my analyst firm to back this up very strongly. 

    The move to the cloud is accelerated, and you know, not stopping. It’s gonna continue to move even quicker. And I know you think about a lot where you’re going as a CTO with your company and your product and your technology, John. What thoughts do you have as you think over the next 6, 12, 24 months kinda into the where we’re going and how that might influence what people might learn or maybe how they learn?

    Grange: Mm-hmm. I actually—that’s a great question, and I’d actually go back to the comment I made before about some of the different trends. And, you know, just like we’ve had the DevOps trend over the last handful of years, there’s a whole number of kind of portmanteaus, right, the CloudOps and DataOps and AIOps.

    And I think that as some of these, you know, Fortune 1000, Fortune 2000s start to become more cloud mature, you’re gonna start to see more of the need for, okay, not just general DevOps where you really understand the cloud platform and orchestrating and automating workloads and things of that nature, but you understand the details of AIOps, for instance, which is a much different challenge, it has lots of other issues with data issues and labeling and things of that nature. Similar issues with sort of DataOps engineering—lots of new problems, really important business solutions to be built there for organizations that are already pivoting their organizations to prioritize these things, particularly after the pandemic. 

    DevOps is all about efficiency, and now what companies are saying is, “Hey, you know, coming out of the pandemic, we’re gonna prioritize our most innovative projects higher and we’ve got to push to be more efficient. We can’t have the cloud spending overages, we can’t have these big breaches that are costly reputationally and financially. We’ve gotta get more efficient.

    So, I think that those are the big things that, coming out of the pandemic, I’d be thinking about. If I were kind of a DevOps practitioner out in the field but also what I’m thinking about at OpsCompass is we’re, you know, looking out, we’re looking into how can we provide more value to our users for some of these really specific use cases that are driving very significant value for companies that are implementing them.

    Ashley: Mm-hmm. I’m curious, too, then, without getting into customer details, but as you’ve worked with your customers through the pandemic, through economic challenges, recovery, that kind of thing—what changes are you seeing in the market with the customers that you’re working with? Are they emphasizing different things, stepping back and taking new directions or trying to get better at just the core things? What’s happening?

    Grange: Yeah. You know what? It’s interesting. From my perspective, it’s very much almost no new phenomenon. It’s almost all just an acceleration of things that we were already seeing.

    Ashley: Mm-hmm.

    Grange: So, in other words, a lot of our kinda strategic plans that we thought were maybe a year out all of a sudden became, you know, “We need them, like, yesterday.” So, I think that a lot of those trends around remote work were already in place. I think a lot of—you know, many of the projects that we’re seeing companies, you know, prioritize, put a higher priority on, those projects already existed. Now, they’ve just become more important.

    Unfortunately, a lot of these IT teams and cloud teams shrunk during the pandemic. So, they now have the requirement that they’re more efficient and everything else, but they have, in many situations, fewer resources to work with.

    Ashley: Mm-hmm. Well, though that’s hard, it’s almost always that growth comes through investing again, so at some point, that starts to rebuild on that efficiency.

    Grange: It’s the story of IT, right? The story of IT—being understaffed and overly important.

    Ashley: Yeah, I don’t think I’ve met an IT team that said, “You know, we just have too many people. I’m not sure what we do with all these folks.” [Laughter] 

    Grange: Yeah.

    Ashley: You know, it’s interesting—I agree with you about, it’s very much accelerating. Another trend I would share—let me see if you concur with this—is, you know, you have the fortunate, if you wanna think of it that way, situation of being in a company where your software is your product, right? So, you can connect the dots between work that Amy’s doing or someone’s doing a test or someone’s doing customer service or architecture or what you’re doing in your role, John. You can connect that to the business and why you want to invest in AI and machine learning or whatever the next thing is.

    That can be really hard to do when you’re in a bank or an insurance company or something else where there’s a lot of distance between what I’m doing in my job—especially in a Fortune 1000 company or above. With that acceleration, though, and I think because of DevOps and AsteriskOps being adopted across different functions, a lot of that is about driving that connect the dots to why we’re going and where we’re going there, and how to accelerate, right? So, the efficiency can be for financial purposes, but recovery can also require agility, very fast response. You know, markets change, our supply chain is gone. We gotta rebuild that in a totally different way—so, guess what? Software is critical. It’s not just a back office thing. Thoughts?

    Grange: Hey, I think that’s exactly right. And, you know, using the financials as an example, you know, many of these financial companies were spending an extraordinary amount of money on reducing their risk, their technology risk, their physical security data centers, really expensive software to secure it all. And you’re exactly right, one of the accelerating trends is that efficiency. That’s not efficient at all. Capital One now has moved—they’ve shut down, now, all of their data centers around the world. They’re completely in the cloud.

    Ashley: Mm-hmm.

    Grange: That’s kind of an outlier example now, they’re like, the only one. But they’re all—I can tell you, just on experience with our own customer base, the mid-market is moving very quickly that way, too. Because they just realized that—hey, we don’t have to, we now don’t have to build data centers, we don’t have to have these huge capital budgets. We can be more efficient, we can be more operational. We can—to your point, the agility that’s required with how quickly this technology’s changing, you almost don’t have a hope unless you’re in the cloud. You know, you can stand up your own container stack in your data center and set up a rack and buy hardware and do all that, or you can go turn on, you know, Amazon’s Elastic Container Service and go with it. I mean, it’s just, it’s a whole different ballgame. And, yeah, I think that that’s a good example, Mitch.

    Ashley: Excellent. I’m curious, Amy, your perspective on it, too. Will you—in your role when, kinda, you think about your career and where you’re moving as well as the company, how is the current situation influencing how you’re thinking about what you do next, what you learn, and how you can maybe help others accelerate their learning?

    Wall: Hmm. Yeah, I agree with both of you, that I think the pandemic has had a real—there’s a renewed sense of urgency because of it. And so, I think a lot of us have had a moment to kind of take a step back and think a little bit from a broader perspective about what our company is, what our company is doing, what we are doing, where our careers are going—all those kinds of things. 

    And yeah, I think people are having an opportunity to figure out—like John was kind of saying, John mentioned the infrastructure for working remotely was largely in place before the pandemic, but that wasn’t always true, and that wasn’t true for every company. And so, I think there’s a lot of catching up that’s happening right now, and yeah, there’s definitely this added urgency behind all of it because of the state that the world is in right now.

    Ashley: Yeah, it’s interesting. I was running IT for a while at a prior job, and we were at this beginning of—stopped thinking about it as we were working remotely or working remote and think of it as work anywhere. 

    And it seems like that’s totally apropos now, that’s—you know, if you think about forward, it’s not like we’re all gonna show up back in the office after we vet the vaccine or whatever, even if things are in good shape, you know, public health wise, there’s a lot of things that, you know, we’ve been doing this for a year, two years or whatever the time’s gonna be. People are gonna build on it and leverage that, at least I think. I don’t know if you all agree, but I think this is the work anywhere that we’re in now.

    Grange: Well, CFOs got a little taste of really, really small travel and entertainment budgets, and I think that, as those start to come up, I don’t think that the tolerance levels will be quite where they were before the pandemic.

    Ashley: Yeah, we’ve proven, right, what we can do.

    Grange: Yeah.

    Ashley: Also interesting, you know, folks have talked about, we’ve made decisions a lot faster, too, in some cases. You know, we were debating—do we use Team or Slack or whatever, you know, for a year and suddenly in a week, two days, we decided it. Like, why can’t we do that all the time? Well, maybe not always you do that, but we’ve shown we can accelerate a lot of things.

    Grange: Well, I think that another thing that happened is, I think that American companies in particular, I can’t comment as much internationally, but American companies, I think, got very good in this, in the 21st Century at buying software—maybe even before that. 

    But I don’t think that companies are very good at actually adopting and using software, and I think one of the things that the pandemic did is, like, everybody bought teams and bought all this stuff from these, you know, the big tech companies, and nobody really fully adopted it, fully implemented it. It was always just kind of another thing on the shelf, and I think that that’s another thing that’s happening right now.

    Ashley: Mm-hmm. Getting greater adoption. 

    Grange: Lots of the collaboration technology, lots of the things that we all kinda use are now becoming highly mission critical business processes that we care about. So, we’re, like, fully adopting them.

    Ashley: Just the essential tools in the toolkit versus, “Yeah, I’ll use it if I have to talk to that team” or something, [Laughter] that group. As you’re thinking about the technology stack, Amy, you know, John was talking about adopting software. I remember a time in my career where folks felt like they had to write all of it, right? I mean, yeah, they used a database system, or—you like to build software, so build as much of it as you can.

    Today—yeah, you write software, but you want to, is there a better container management system than Kubernetes? Well, let me go check it out. You know, I don’t necessarily want to write my own. Maybe I do wanna do it as an open source, but you’re really a software integrator, software builder as part of the whole process, not just a software developer. Is that how you view things?

    Wall: Absolutely, yeah. Yeah, I’m a big proponent—totally, yeah. I always say, “If you can avoid it, don’t reinvent the wheel.” And everyone says that, but not everyone always takes that to heart.

    Ashley: Mm-hmm.

    Wall: And I think a lot of the times, especially when you’re in a software team, you’re in a development team and you’ve kind of got your head down and you’re really working hard on code, I think it’s really easy to kind of lose sight of the broader picture.

    And, you know, just last week for example, we had this problem we were trying to solve where some customers weren’t—you know, there was a miscommunication between our software and some customers. And, you know, I kind of just was able to take a step back and—

    Wall: – you know, customers weren’t, you know, there was miscommunication between our software and some customers, and you know, I kind of just was able to take a step back and say, “You know, if we just think about this and maybe document it, write about it, you know, find some documentation online, you know, find a good article, perhaps, that we could recommend, I think we could solve this problem without writing any code at all.” And we did. And I think those kinds of solutions are happening a lot, for sure.

    I mean, and you mentioned open source earlier as well, and I think that plays into it to a huge degree as well.

    Grange: That’s what I was about to say Amy, is that that goes right back to what you were saying, Mitch, with the open source. And I think that’s why open source sort of is kind of supreme right now. Go find a library, go find a package that already does this, go find a service that we can just integrate APIs with, you know—let’s not reinvent the wheel.

    Ashley: I remember being on some panels of, you know, “Should you use open source?” and my answer was, “I can guarantee you your competitors are.” Talk about a source of innovation that you can get for little or no cost—I mean, yeah, there’s a cost with it, but you better leverage it, you know, [Laughter] in the right way for your company as well.

    Let’s talk a little bit about OpsCompass. I’d love to hear, maybe, some of the future directions you’re heading. You’re not announcing anything here today, but what are the kind of things you’re thinking about since we’ve talked about this evolution of where the cloud and technology and skills need to go? What’s happening at OpsCompass as you evolve and change and play a leadership role in the industry?

    Grange: Sure. Well, for us, the way we like to think about the product and the product strategy is, what’s going on in the cloud space, what are customers doing, and then how can we provide kind of visibility and intelligence across those different dimensions?

    So, I talked a little bit about kind of some different AI products and services that we were starting to see companies use more containers. We obviously—that’s kind of a number one use case for our customers today. So, we’re fairly strong there, but we’re gonna get much, much stronger.

    But another big part of it for us is the DevOps pipeline. We provide visibility into what the pipelines are doing today, but it’s becoming so much more critical to the full cloud processing companies. They’re becoming more DevOps mature that we are going to, you know, kind of completely blow out that kind of set of functionality in our product over the next year. So, we’re excited about that. And you know, our customers are really looking—you know, you can parse through a lot of the technical explanations for problems, but what they’re really trying to do is get control, and the definition of control is a little bit different than it was in the data center. And there’s some more subtleties and things to it, it’s got a little bit more texture, I like to say.

    And so, it requires a different approach and when we can combine, you know, the deep visibility into what they have with the intelligence and context around, you know, what’s happening and the state of things, that’s kinda how you end up getting control. And there’s processes and people involved and everything else, but kind of everything we do—and we kind of, you know, eat, breathe, and sleep that kind of mantra, and we’re constantly poking and prodding at the clouds, working with the clouds. We work with all three at the corporate partnership level. So, we’re just really—we’re having a lot of fun, and it’s sort of the key problem of the age right now is just the different teams, all these different people, different resources, different services. It’s just sort of the impact of this sort of scale and kinda chaos a little bit. So, there’s just so many great problems to solve around making sense of it all.

    Ashley: Mm-hmm. Excellent. Amy, anything from your perspective you would like to add or talk about?

    Wall: Yeah, I think John is just spot on. And I also think, from an internal company perspective, you know, what’s happening within OpsCompass is being mirrored by companies across the globe right now, which is that we are really kind of getting a feel for how to operate as a totally distributed team, like you were mentioning earlier. We have employees now all across the United States and internationally. We also work with customers and _____ abroad.

    So, we have this—I think we’re kind of learning along with our customers how to kind of interact with a more global ecosystem than we had before and how to kind of bring all of these, all of the water cooler conversations or all of the idea sessions or brainstorming sessions and whatever onto Slack, onto Teams online so that we can all engage.

    So, that’s definitely a change that I’m seeing internally and that I’m not, I don’t see going away when the pandemic is over, and I see it becoming something that goes on to the future.

    Ashley: Yeah, that’s very wise. I think it’s very sticky kinds of behavior changes and work patterns that will be with us for a long time to come.

    Well, I’ve really enjoyed, this has been a fun conversation talking with you both and it’s just—it’s so much fun to share real experiences that we’re having in our jobs and our careers and also doing it in a way that hopefully this conversation can benefit some other folks, you know, along the way who may have similar or maybe different experiences that they might pick up from what we’ve talked about.

    So, before we wrap up, to check out things at OpsCompass, John—OpsCompass.com, is that correct?

    Grange: Yep, you can go to OpsCompass.com, check out more about us. We have a free trial, really encourage people to go jump in, check out the product. Again, it’s built by a bunch of DevOps engineer cloud nerds for our sort of brethren, if you will. So, love getting feedback and let us know if there’s any, if there’s anything that we can help you with.

    Ashley: Built by DevOps people, for DevOps people, right? [Laughter] 

    Wall: Exactly.

    Ashley: Exactly. Well, Amy Wall, it’s been fantastic talking with you. Thanks for sharing your story and your insights. 

    Wall: My pleasure.

    Ashley: And John Grange—similarly, your insights as well as kinda where we’re headed and a fun conversation with you. Both the best, have a great holiday, and we’ll see you into the new year.

    Wall: Thanks a lot, Mitch.

    Grange: Thank you, Mitch. Be safe.

    Ashley: You, too.

  • Plutora’s Bob Davis: Work From Home and Value Stream Management

    Plutora’s Bob Davis: Work From Home and Value Stream Management

    American writer Orison Swett Marden said, “Success is not measured by what you accomplish but by the opposition you have encountered and the courage with which you have maintained the struggle against overwhelming odds.” After the year that’s passed, with operations and development teams forced to scatter and work remotely, it’s a sentiment DevOps teams are currently all too familiar with.

    This demand to keep DevOps teams productive under the extraordinary circumstance of 2020 has placed an increased emphasis on effective management, including on value stream management tools, so leaders and team members can have greater visibility into delivery pipelines.

    To get a sense of the state of the value stream management market, I reached out to Bob Davis, chief marketing officer at value stream management platform provider Plutora. Below is an edited version of our conversation.

    George Hulme: Thanks for taking the time today, Bob. Could you tell us a little about Plutora?

    Bob Davis: We are a value stream management platform provider. When I first arrived here, we recognized that sales, marketing, financial and human resources teams all have their systems of record. They have Salesforce, ERP (enterprise resource management) systems, and various financial and HR platforms that enable people to practice their profession more easily. IT didn’t have anything like that at the time.

    We set out to provide that capability for the software development side of IT. Today, the market is caught up. Everybody is moving into value stream management as a platform to provide that visibility across an entire toolchain, from the idea to production. That’s where we play. We’ve been in this space since it began over two years ago. The market is just exploding with the work-from-home trend, and how the pandemic kicked digital transformation into high gear.

    Hulme: It appears that a significant percentage of the work-from-home trend is here to stay. I’m seeing surveys showing about 19% of people previously suspected that they’d be working from home in a year. That figure jumped now to near 50%.

    Davis: If you start to parse what work from home means, you’ll find it means many different things to different organizations. Some have a hybrid model with people working from home two to three days a week. I recently read a Gartner survey that said 74% of organizations were going to have some element of work from home. It’s not all or nothing.

    Some companies have decided that they are not going back to work until well into this year. All of these companies have to make sure they have governance compliance in place for this new workforce, and that they can successfully manage the complexities of software development. These challenges are at least an order of magnitude, if not more so, more difficult than typical office workers working from home.

    Hulme: Is one of the reasons behind those challenges struggling to maintain being on the same page across the organization?

    Davis: That’s a great point, George, because when we go out with our teams at many organizations, a lot of the effort helps people fast-track their processes. We are asked, “What is the best practice for automating builds? How often should I be automating builds? What KPIs do I establish to make sure that people are striving to accomplish what we need them to accomplish?”

    For example, one of the things that Lean and Agile methodologies promote are smaller work items, quicker check-ins, faster processes. They encourage cutting work down into smaller bundles to be done more quickly so that teams can iterate much more rapidly. We’ve seen that managers will often create a KPI for a performance management program to measure how often code gets checked.

    That’s horrible because now I can just check in code all the time. Yet, are people making actual progress? Are they actually delivering software, or are they just checking in small iterations of code all day?

    Organizations have to be very careful with how they manage people. They have to be cautious with what metrics they set up to keep their eye on delivering value and delivering software more quickly. This is something organizations struggle with. They want to know where to start and what metrics they need to implement. And how to make those metrics visible so people can see and understand them. That’s what provides the ability for product owners, managers, executives and other stakeholders to view the progress and status of what’s going on without disrupting people with calls and endless meetings.

    Hulme: That has to be tremendously more challenging with the work-from-home trend than years prior.

    Davis: I recently heard a great quote: “As people end up working from home, the need for human contact and human interaction, socialization, is peaking.” People are hungry for that. At the same time, the need for managers to not be in the face of the employees has never been higher. That is, the motivation and the productive nature of employees is proportional to how well they feel trusted. And it’s proportional to how well they understand where they’re headed and understand how to do their job and are left alone to do that job.

    It’s a leap of faith to leave people alone and simply trust them. You need systems that provide you the ability to collaborate; watch the progress. You need systems that will help you understand where people might be struggling, all without having to dig in and micromanage your people. Indeed, as we are learning, managers can effectively do this with Zoom, or Slack, or some other tool that provides good communication flow within a work-from-home environment. But in software, the handoffs and dependencies are so complicated that those tools are simply not enough. You need a collaboration tool that provides effective management in software development.

    Hulme: Do you believe remote development teams can communicate as collaboratively as they did in person, with modern software collaboration tools?

    Davis: Yes, I think they can. Especially when office collaboration tools, such as Zoom and Slack, and software collaboration tools work together. We can leverage Slack to communicate tasks. So we not only layer on top of the individual tools people have and integrate with them, the practitioners working within those tools can make it available to all of those stakeholders involved in that process. And when there are tasks or handoffs, the system can be configured to notify them how they prefer to work: email, Slack, instant messenger, task list on the dashboard. There’s a lot of different ways, depending on how people want to work.

    Not only that, but it can automatically alert people to what is happening and what’s needed. Fascinatingly, one of the interesting yet deceptively tricky questions to get an answer to is, “Where’s the status of a feature?” If a team is in the process of building something out, and they have a specific feature, such as check cashing in a banking app, it should be a pretty straightforward question to get answered.

    Yet, about seven or eight different teams are working on various aspects of that application. For instance, there’s a product owner who, without the right collaboration system, has to go and essentially track all of those teams down and find out where their status is.

    With a software collaboration system, you can make that query without bugging anybody. In some respects, you can collaborate more efficiently and more productively than you can when you’re all sitting in the same room. That’s because before, we would have walked over and interrupted somebody. Now you’re just looking at a dashboard, or you’ve gotten an alert on Slack, and you see what you need. Boom.

    Hulme: How important do you think it is to have useful data and that value stream knowing where things stand to keeping the system flowing and individuals knowing where they fit on deliverables?

    Davis: I think the ambiguity, unexplained delays and unforced errors are among the things that upset human beings the most. Just ask somebody that’s standing in a line that’s not moving, and it hasn’t moved in a while; how restless the crowd gets. The nature of software development is such that there are tremendous numbers of handoffs, no matter how you do your development.  It doesn’t, whether it’s an old fashioned waterfall or the most advanced development and deployment models in operations at places like Spotify — you have a lot of handoffs. And if you can’t see what you’re doing because you don’t have visibility into those parts, then you’re going to run into an incredibly frustrated team. And you are going to see a lot of finger-pointing when the question comes up, “Why didn’t this release go out?” And then there’ll be five or six different groups pointing to different reasons. You get a lot of anger, a lot of discontent.  And it’s something you have to avoid if you are going to succeed.

  • Meet the Winners of the 2020 DevOps Dozen² Awards

    Meet the Winners of the 2020 DevOps Dozen² Awards

    This is the moment you have all been waiting for. It is time to announce the honorees for the 2020 DevOps Dozen² Awards, and we couldn’t be more excited to share the names of the most outstanding leaders and tools in the DevOps community. Although, I must say, all the finalists have done an amazing job at making the DevOps community better through their mentorship, service and innovative ideas, and every single one is deserving of special recognition.

    The DevOps Dozen Awards recognize the best of the best in the maturing DevOps space and this year’s winners have demonstrated exceptional leadership and support to the community through 2020 and the COVID-19 pandemic. Last year was a tough year for all of us for sure, but it was also a year of agility, innovation and rapid digital transformation. The 2020 honorees have displayed resilience, determination, commitment and willingness to embrace change in a year of unprecedented challenges to drive their business—and the industry—forward. Congratulations to each and every one of the honorees.

    Winners have been chosen from among the finalists with general public voting being weighted for 40% of the final total and our judges selections for 60% of the weighted total. Our team has gone through thousands of votes to pick out the winners in each category—it was not an easy task. Many thanks to our panel of judges for making the hard calls and to everyone who voted and nominated candidates.

    Ladies and gentlemen, I am proud to present to you the 2020 DevOps Dozen² Awards honorees:

    DevOps Dozen Community Awards

    Best DevOps Industry Implementation

    Lloyds Banking Group, the largest financial services organization in the UK, is the winner of the Best DevOps Industry Implementation award. Lloyds Banking Group has invested heavily in driving the adoption of Agile development and DevOps practices across its business to strategically modernize its digital service capabilities and align with customer expectations.

     

    Best DevOps Survey/Analysis/Research

    The Best DevOps Survey/Analysis/Research award goes to Puppet’s 2020 State of DevOps Report. The report focuses on two areas that can help organizations scale their DevOps initiative: a platform approach to software delivery and applying DevOps principles to change management. It is the ninth year in a row that Puppet produces a State of DevOps Report. It is the longest-running and most widely referenced DevOps research in the industry.

    Best DevOps Related Video Series (Video)

    The Best DevOps Related Video Series is DevOps Unbound, a bi-weekly video series that focuses on DevOps, automation, CI/CD and testing. Top industry leaders join the series to explore the challenges and issues that software delivery and IT teams face on a daily basis.

     

    Best DevOps Related Podcast Series (Audio Only)

    The Modern Mainframe: Building a Better Software Delivery Platform is the Best DevOps Related Podcast Series. The Modern Mainframe is a podcast by Compuware that explores mainframe modernization and how to transform mainframe culture, processes and tools with DevOps to help your business compete in a digital age. Building a Better Software Delivery Platform is episode 9 of the podcast, featuring Compuware DevOps Architect Rick Slade.

    Best DevOps Books / eBook of the Year

    Standing On Shoulders: A Leader’s Guide to Digital Transformation by Jack Maher and Carmen DeArdo is the Best DevOps Books / eBook of the Year. This must-read provides leaders with practical, actionable information about the breadth of Agile, Lean and DevOps topics that are generally dealt with individually; and explains how each of these are necessary but alone are not sufficient to avoid market disruption of your business. The authors focus on how to build an employee and customer-obsessed culture with an organizational structure that drives speed and efficiency, while leveraging technology to enable speed to value that is faster, safer, better and cheaper.

    Top DevOps Evangelist

    The Top DevOps Evangelist award goes to Helen Beal, chief ambassador at DevOps Institute. Helen is a well-known DevOps evangelist leading the DevOps Institute Ambassador program’s efforts to provide broad-based thought leadership and localization. She is an analyst at Accelerated Strategies Group and an editor at InfoQ. Recently, Helen has been working with a group of ambassadors to develop a new, online DevOps Capability Assessment (DOCA), launching in 2021. Taking on strategic advisor roles with Plutora and Moogsoft has given her the opportunity to dive deep into value stream thinking and observability. She is the host of Day-to-Day DevOps, a BrightTalk series that focuses on topics ranging from neuroscience, to ChatOps, to AIOps and everything DevOps related.

    Best DevOps Transformation (Non-Vendor)

    The winner of the Best DevOps Transformation award is Fidelity Investments, a financial services company that supports financial institutions with innovative investment and technology solutions to grow their businesses. Fidelity’s embrace of cloud-based platforms has yielded tangible improvements, such as better operational resiliency.


    Best DevOps Virtual Event of the Year

    The DevOps Dozen award for the Best DevOps Virtual Event of the Year goes to DevOps World 2020. The virtual event, featuring more than 100 business and technical breakout sessions, focused on how DevOps is transforming the world of software delivery and how businesses are adapting their ways of thinking during the COVID-19 pandemic. Top industry leaders discussed where DevOps is headed and how the audience can best leverage advanced practices to succeed in the future.

    Most Innovative DevOps Open Source Project

    Grafana Loki was chosen as the Most Innovative DevOps Open Source Project. Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by Prometheus.

     

     

    DevOps Executive of the Year

    The DevOps Executive of the Year is GitLab CEO and Co-Founder Sid Sijbrandij. Sid’s career path has been anything but traditional. He saw the first Ruby code in 2007 and loved it so much

    that he taught himself how to program. It was during his time as a Ruby programmer that he first encountered GitLab, and quickly discovered his passion for open source.

    In 2012, he helped commercialize GitLab, and by 2015, he led the company through Y-Combinator’s Winter 2015 batch. Under his leadership, the company has experienced 50x growth in the last five years, expanded from nine to more than 1,300 remote team members across 65+ countries and regions and is now valued at $2.75 billion. A champion of the open source community and a pioneer in scaling remote organizations, Sid is altering conventional wisdom on DevOps practice.

    Best DevOps Presentation of the Year

    On Ramp to Open DevOps for Mainframe by George DeCandio, chief technology officer of the Mainframe Software Division at Broadcom, is the winner of the Best DevOps Presentation of the Year award. In this keynote presentation, George DeCandio explained what you need to adopt an open strategy and how you can integrate with existing DevOps tools such as Git and Jenkins, or into existing cross-platform CI/CD pipelines. George discussed how Zowe, OMP’s first project devoted to the mainframe, is opening mainframe system commands, data sets and source libraries so you can integrate with tools that know nothing about mainframe.

    Best DevOps.com Article of the Year

    How to Reduce Engineer Burnout During COVID-19 by Henry Jewkes, staff software engineer at Split, is the Best DevOps.com Article of the Year. Henry explains how to cope with burnout effectively as it becomes increasingly common during the COVID-19 pandemic.

     

    DevOps Dozen Tools and Services Awards

    Best End to End DevOps Tool/Service

    The winner of the Best End to End DevOps Tool/Service in 2020 is GitLab. GitLab has demonstrated to be the most efficient solution for DevOps teams to collaborate and build software. The GitLab solution is the result of the collaboration between thousands of community contributors and feedback from the more than 100,000 organizations that have adopted GitLab to power their DevOps transformations. The GitLab community contributes code, documentation, translation, design and product ideas based on their real-world challenges, making GitLab more useful and valuable.

    Best DevOps Repo/GitOps Tool/Service

    The DevOps Dozen award for the Best DevOps Repo/GitOps Tool/Service goes to GitHub, the most popular open-source version control code repository. GitHub is great to manage and maintain code in the cloud and contribute to projects quickly with automatic environment setup.

     

    Best CI/CD Tool

    CircleCI was chosen, by the public and the judges, as the Best CI/CD Tool. CircleCI is the leading CI/CD solution for software innovation at scale. The CircleCI platform allows teams to build and deliver software in the cloud or on their own infrastructure. CircleCI manages more than 35 million builds per month on Linux, macOS and Windows.


    Best Value Stream Management Tool

    The 2020 DevOps Dozen winner of the Best Value Stream Management Tool is Digital.ai Value Stream Platform. Digital.ai enables the world’s largest enterprises to accelerate their digital transformation initiatives by combining industry-leading enterprise Agile planning, application security, continuous testing, software delivery and AI-powered analytics in the first intelligent value stream platform. Digital.ai Value Stream Platform provides a unique view of the software delivery lifecycle through the customer experience lens to better align with business objectives and scale Agile and DevOps processes.

    The Digital.ai Value Stream Platform features end-to-end connectivity, visibility with AI-powered analytics, continuous testing and quality, release management and flow optimization, and measurable outcomes through quantified metrics. The platform allows organizations to set business goals based upon market needs, deliver products and technologies to achieve those goals, measure and analyze results, and make adjustments to continuously improve.

    Best Observability Solution

    The award for Best Observability Solution goes to Splunk Observability Suite, a comprehensive combination of solutions designed to help IT and DevOps teams tackle new monitoring challenges that other tools haven’t been able to effectively address. The Observability Suite helps users maintain the highest levels of business performance and adaptability, improve release quality and velocity, improve developer efficiency, minimize downtime, and deliver world-class digital experiences.

    Best DevSecOps Solution

    JFrog Xray was voted the Best DevSecOps Solution of 2020. JFrog Xray is a universal impact analysis product enhancing artifact security, container security and OSS license compliance across your DevSecOps pipeline. JFrog Xray scans your artifacts, builds and Release Bundles for OSS components being used, and detects security vulnerabilities and licenses in your software components.

    Best Testing Service/Tool

    Tricentis Tosca, a continuous testing platform that accelerates testing to keep pace with Agile and DevOps, is the winner of the Best Testing Service/Tool of 2020. With the industry’s most innovative functional testing technologies, Tricentis Tosca breaks through the barriers experienced with conventional testing tools. Simplifying end-to-end functional testing, Tricentis Tosca automates tests across all layers of modern enterprise architectures.

    Best Kubernetes Platform/Service

    The Best Kubernetes Platform/Service award goes to Red Hat OpenShift Container Platform. 

    Red Hat OpenShift is an open source enterprise Kubernetes platform offering a consistent hybrid cloud foundation for building and scaling containerized applications.

    Best Cloud Native Security Solution/Service

    Styra’s Declarative Authorization Service (DAS) is the winner of the Best Cloud Native Security Solution/Service award. Styra DAS was purpose-built to solve the authorization challenges of cloud-native, containerized application, and the infrastructure they run upon. Built on the open source project Open Policy Agent (OPA), Styra policy-as-code solutions have been proven in production, at scale, in many of the largest cloud-native deployments in production today.

    Styra DAS allows enterprises to define, enforce and validate authorization policy across services, teams, clusters and clouds. As businesses move their cloud-native applications from development through to production, Styra DAS provides the tooling to minimize the risk of human error, offload compliance overhead and ensure security and compliance best practices are enforced across your environment. Styra DAS simplifies policy creation with a built-in library of best practices and security policies, as well as a point and click interface for building custom policy from scratch.

    Best DevOps for Mainframe Solution

    It was very difficult to choose a winner in this category. There was a tie between two solutions, CA Endevor Bridge for Git by Broadcom and Compuware’s Topaz, and after a long discussion the judges decided that both should be honored as the Best DevOps for Mainframe Solutions of 2020.

    CA Endevor Bridge for Git is a component of the CA Endevor Integrations for Enterprise DevOps. It connects Git to Endevor via an Enterprise Git Server, such as GitHub, Bitbucket or GitLab. Git as well as traditional mainframe developers can easily collaborate on the same mainframe application managed in Endevor. Only code that is pushed from local Git repository to the Enterprise Git repository is recognized by the integration and gets propagated to Endevor.

    Topaz is a modern Agile platform of mainframe development and testing tools that integrates into the DevOps toolchain, empowering any developer, regardless of experience, to understand and work on any program, no matter how old or complex, so that their organizations can easily maintain and innovate from their base of mainframe investments.

    Best DevOps for DataOps/Database Solution

    The Best DevOps for DataOps/Database Solution is InfluxDB. Developed by InfluxData, InfluxDB is an open-source time series database that empowers developers to build IoT, analytics and monitoring software. It is purpose-built to handle the massive volumes and countless sources of time-stamped data produced by sensors, applications and infrastructure.


    Best New DevOps Tool/Service Provider

    The winner of this category is Opsera, the first continuous orchestration platform for DevOps teams. The Opsera platform automates any CI/CD toolchain, enables declarative pipelines and provides unified insights across the entire software delivery process.

     

     

     

    Winners will receive both digital and physical trophies and badges celebrating their achievements.

    Thanks for supporting DevOps.com and the DevOps community. For more information, visit the 2020 DevOps Dozen² Awards website and stay tuned for the 2021 DevOps Dozen Awards.

  • 4 Ways to Scale DevOps in 2021

    4 Ways to Scale DevOps in 2021

    January is a month often dedicated to planning, setting intentions and preparing ourselves professionally and personally for a fresh year. In my own capacity as a DevOps and SRE leader, many of the clients I work with will reinvigorate internal efforts to streamline how they work in Q1.

    I often advise clients to make very concrete goals and milestones for their technology organizations to become more agile, streamlined and modernized. Setting these goals is helpful to articulate to the wider business where you want to go and how you plan to get there. Here are a few DevOps-related initiatives your team may want to tackle in the first half of this year.

    #1: Tighten Security through DevOps

    Securing your organization’s infrastructure is an evergreen priority for technology leaders. When done properly, security should be baked into all DevOps processes (sometimes called DevSecOps) from the design phase all the way to application maintenance. To be effective and not slow down development, security processes need to move at the speed of today’s fast-moving environments, which is near impossible, or, at least very challenging, unless security is well automated.

    Automated security measures can be applied to the full life cycle of product development and should make development time faster and smoother in the long run if you can catch vulnerabilities early. Identify automation tools that work for your team and experiment with what works best.

    Similarly, in fast-moving environments, it’s tempting to play fast and loose with privileged access to unblock individuals and teams. Lax policies for user rights exposes the organization to too much risk from potential hackers. Implement a solution or protocol to keep access controlled. Policy and governance are critical for well-rounded DevSecOps. Communicate policies regularly with the entire organization. Ensure that all engineers know how to comply and enforce them.

    #2: Make DevOps an Organizational Culture

    Much like security, DevOps needs to evolve from an individual role to a cross-functional, holistic, cultural approach to developing software. Organizations should foster a DevOps culture rather than identifying specific individuals in DevOps roles.

    So how do you know when this culture shift has happened? A good pulse check is to see how quickly your company can adapt to change. How mired is your team in legacy code or infrastructure? Can individual teams operate autonomously? Teams and individuals that are independent and accountable are able to continuously experiment and learn at a much faster rate.

    DevOps cultural transformation won’t happen overnight – but it can be expedited if embraced by the entire company. I typically advise companies to focus on making incremental, consistent progress that builds autonomy, trust and transparency. These are the building blocks of a thriving DevOps culture.

    #3: Simplify Your Infrastructure

    Complexity, over time, creates duplication, unnecessary systems and technical debt. All of these have a cost, and create security vulnerabilities. Create organizational goals to clean up and reduce complexity. I often suggest teams create a roadmap to move toward self-service and building platforms. As you focus on building a DevOps organizational culture, you will likely notice that teams will identify opportunities to simplify and standardize, which will also remove complexity.

    #4 Review system SLAs and SLOs

    Establishing and monitoring key metrics are a fundamental part of any SRE role. Service level agreements (SLAs) and service level objectives (SLOs) need to be defined and monitored to ensure your team is fulfilling them. System availability (uptime, latency, etc) is core to any cloud SRE team. Define what reliability means for your organization. January is a good time of year to start fresh and articulate these metrics, how they relate to your core business and what investments or changes need to be made to achieve them.

  • How MLOps Can Help Get AI Projects to Deployment

    How MLOps Can Help Get AI Projects to Deployment

    Did you know that most AI projects never get fully deployed? In fact, a recent survey by NewVantage Partners revealed that only 15% of leading enterprises have gotten any AI into production at all. Unfortunately, many models get built and trained, but never make it to business scenarios where they can provide insights and value. This gap – deemed the production gap – leaves models unable to be used, wastes resources and stops AI ROI in its tracks. But it’s not the technology that is holding things back. In most cases, the barriers to businesses and organizations becoming data-driven can be reduced to three things: people, process and culture. So, the question is, how can we overcome these challenges and start getting real value from AI? To overcome this production gap and finally get ROI from their AI, enterprises must consider formalizing an MLOps strategy.

    MLOps, or machine learning operations, refers to the culmination of people, processes, practices and underpinning technologies that automate the deployment, monitoring and management of machine learning models into production in a scalable, fully governed way. Laying an MLOps foundation allows data, development and production teams to work collaboratively and leverage automation to deploy, monitor, manage and govern machine learning services and initiatives within an organization. In short, MLOps can help enterprises see AI projects through to deployment at scale by addressing the three previously mentioned barriers: people, process and culture.

    People

    There’s a skill, motivation and incentive gap between teams developing machine learning models (data scientists), operators of those models (DevOps, software developers, IT, etc.), and the business leaders who look for the results of that work. By providing actionable visibility into the different steps of the machine learning model life cycle for these different roles, MLOps can increase collaboration across departments so that enterprises can streamline the process of getting models operational and finally meet strategic goals.

    Process

    Operations teams are geared towards ensuring overall quality of service, optimizing runtime environments on their cloud, resource management and role-based access, among many other tasks. Data science teams are often unaware of the considerations these dependencies require, and, hence, models they create do not take these tasks into consideration. Additionally, lack of a proper native governance structure as it pertains to machine learning models – with system, performance, life cycle, and user logs – stifles troubleshooting, as well as hinders legal and regulatory reporting. Organizations that don’t properly monitor their models end up introducing potential risk to their organizations. When production models don’t reflect the ever-changing patterns in data and user behavior, these factors may affect the accuracy and overall performance of the model. Machine learning-based applications are far more sensitive to production environments than typical software applications. Therefore, machine learning models need to be validated and updated over time to ensure that they’re performing properly and leveraging the most accurate and recent data. As part of implementing an MLOps strategy, by having the right monitoring processes in place to detect drift – and many other machine learning-specific metrics – enterprises can ensure their models are delivering the most accurate results, and that their projects are more likely to move forward.

    Culture

    Fear of failure (or worse) can delay organizations from collaborating to operationalize machine learning models, or prevent this entirely. Leadership needs to be clear about their commitment to the process and fully support teams in enduring the hardships involved. This is only compounded by the fact that machine learning applications typically tend to involve processes that might introduce material risk to the company. To stay on top of such transformations while still producing trustworthy value, enterprises must keep careful tabs on all model deployment processes and the updates they entail. Many operations professionals are not aware of the unique characteristics and sensitivities of machine learning. As their role is focused on managing mission-critical production environments, they are often solely concerned with the implications on their work that deploying machine learning into production might have. While these are justifiable concerns, in the final analysis, they serve as trivial reasons for significant delays in progress and deployment. The way to mitigate all these risks and get all teams aligned around these common goals is to implement a solid MLOps strategy that matches the goals and unique position of the organization and its various teams’ responsibilities.

    MLOps: All Systems Go

    MLOps allows organizations to alleviate the people, process and culture issues posed by machine learning. MLOps provides a strategy and a set of processes and best practices, a technological backbone, for managing and scaling machine learning-based services through automation. It also provides for seamless collaboration between the data science teams responsible for generating models with the teams that are accountable for running the services in production environments. This combination of process automation with role-based collaboration and governance capabilities helps pave the way toward strategic AI goals. Specifically, MLOps can help organizations move from anticipating the management and scaling of machine learning services into production and turn that into reality.