devopsy.kinsta.cloud

Category: DevOps Culture

  • Secure Software Summit: Exploring Secure Coding Best Practices

    Secure Software Summit: Exploring Secure Coding Best Practices

    In an era where software is dominating the world, the security and quality of code must remain a high priority. Delivering secure and reliable software at a rapid pace is crucial for most organizations today, but it’s not an easy task. What security best practices do organizations put in place to successfully produce secure software? How should DevOps teams incorporate updated security practices and tools throughout the software development lifecycle? At Secure Software Summit, taking place Jan. 27 at 9 a.m. PT, the world’s leading cybersecurity experts will come together to share and teach the latest methods and breakthroughs on secure coding and deployment practices.

    The virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • Open source supply chain security
    • DevSecOps
    • Shifting security left
    • Security Chaos Engineering (SCE)
    • Security and compliance
    • Security metrics
    • Zero trust

    Secure Software features an outstanding lineup of innovators, practitioners and academics of secure software development, including:

    • Aaron Rinehart, co-founder and CTO at Verica
    • Dan Lorenc, founder and CEO at Chainguard, Inc.
    • Shinesa Cambric, principal program manager, Identity Signals and Protection Team at Microsoft
    • Vickie Li, developer evangelist at ShiftLeft
    • Fabian Yamaguchi, chief scientist at ShiftLeft
    • Jonathan Schneider, co-founder and CEO at Moderne, Inc.
    • Abhishek Arya, principal engineer and manager, Google Open Source Security Team at Google
    • Steve Springett, senior manager of product security at ServiceNow and chair of the OWASP CycloneDX Core Working Group
    • Jasmine Jackson, senior application security engineer at Disney
    • Suchakra Sharma, staff scientist at ShiftLeft
    • Harini Rangarajan, engineering manager, product security at Twilio
    • Mark Wireman, senior manager at Accenture
    • Shannon Lietz, vice president of Vulnerability Labs at Adobe
    • Vandana Verma, security relations leader at Snyk
    • Yash, head of security at Sendbird
    • Chetan Conikee, CTO at ShiftLeft
    • James Chiappetta, SVP of cybersecurity at Blackstone

    Attendees will have access to valuable resources available for download and will also receive a link to access the virtual environment on-demand. To see the full agenda and to register, please visit the Secure Software Summit website.

  • LogDNA Survey Surfaces Observability ROI Concerns

    LogDNA Survey Surfaces Observability ROI Concerns

    A Harris Poll of 200 senior engineering professionals suggests it may be a while before most DevOps teams are able to achieve true observability in their IT environments.

    The survey was conducted on behalf of LogDNA, a provider of an observability platform, and found nearly three-quarters of respondents (74%) are struggling to achieve their observability goals despite investing hundreds of thousands of dollars. In fact, well over a third (38%) said they are already investing $300,000 annually on observability tools.

    Despite those investments, less than half of respondents are very satisfied with their ability to use log data. Key areas of frustration include the challenges of collaboration with colleagues spanning multiple teams (67%), the fact that the tools are not easy to use (66%) and the routing of security events (58%).

    Nevertheless, the bulk of survey respondents said they are optimistic about observability. A full 85% of participants said they believe true observability is possible.

    LogDNA CEO Tucker Callaway said the core issue that many organizations fail to recognize is that observability is really a data literacy and management challenge. Organizations are collecting logs, metrics and traces from a wide range of tools and platforms without thinking through optimal data pipeline construction. The result is an aggregation of data that has not been normalized to simplify surfacing actionable intelligence, he said. In fact, many organizations quickly discover that all they’ve really accomplished is increase their data storage costs, said Callaway.

    In the absence of that data normalization, Callaway noted it becomes exceedingly difficult for cross-functional teams to query all the data being collected within a repository.

    At its core, observability promised to make it easier to identify IT issues before they cause a disruption. Observability in one form or another has always been a core tenet of any DevOps best practice. Initially, DevOps teams focused on continuous monitoring as the most effective way to proactively manage application environments. However, it can still take days, sometimes weeks, to discover the root cause of an issue. Observability platforms make it possible to correlate events in a way that makes it easier for analytics tools to identify anomalous behavior that might be indicative of the root cause of an IT issue.

    In contrast, traditional IT monitoring focuses on predefined metrics to identify when a specific platform or application is performing within expectations. Observability platforms combine metrics, logs and traces—a specialized form of logging—to make it easier for IT professionals to interrogate data being generated by a wide range of DevOps tools and platforms.

    Of course, the assumption is that DevOps teams actually know what queries to launch to determine what the root cause of an IT issue might be. In the longer term, machine learning algorithms should make it easier to identify anomalies within IT environments. In the meantime, however, achieving observability still requires a fair amount of DevOps expertise that is not always readily available.

    Eventually, observability will become much more automated than it generally is today. As that transition occurs, IT teams should find the ROI of observability is steadily improving.

  • Predict 2022: Back to the Future

    Predict 2022: Back to the Future

    After a year of innovation, rapid digital transformation efforts, new challenges and settling into a new normal, it is time to look back at all the lessons learned and look forward to the future. What does 2022 has in store for us? Will 2022 be a breakthrough year in terms of progress and opportunity? At Predict 2022 Virtual Summit, taking place Jan. 19-20, top industry leaders will share their speculations on what the future holds in the realms of DevOps, cybersecurity, digital transformation, cloud-native and IT.

    Predict 2022 is a free virtual event featuring a conference lobby, presentation theater, expo hall and more. This event is a great opportunity for networking and learning about the trends, technologies and looming topics that could have the most impact on technology in this new year.

    Predict 2022 features a stellar lineup of industry experts, including:

    • Tracy Ragan, CEO and co-founder at DeployHub, CDF board member
    • Mark Miller, senior storyteller at JupiterOne
    • Mike Jones, H4unt3d Hacker Podcast, content creator at Knight Ink
    • Caroline Wong, chief strategy officer at Cobalt
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Donovan Farrow, CEO at Alias
    • Nicole Dove, CIA, CRMA, business information security officer at WarnerMedia
    • Niladri Choudhuri, founder and CEO at Xellentro Consulting Services LLP
    • Emmet B. Keefe III, operating partner and founder at Insight Partners
    • Matthew Guarini, VP, senior research director at Forrester
    • Mike Vizard, chief content officer, GM/editorial director at Techstrong Group/Digital CxO
    • Mitch Ashley, CTO at Techstrong Group and principal at Techstrong Research
    • Ori Inbar, CEO at Augmented World Expo
    • Thomas Krane, principal at Insight Partners
    • Ali Khan, partner, US Consulting Solutions at PwC
    • Jim Walker, principal product evangelist at Cockroach Labs
    • Keri Pearlson, executive director at MIT (CAMS Research Consortium)
    • Russ Finney, lecturer and director of MIS Undergraduate Programs at The University of Texas at Austin McCombs School of Business
    • Marnie (Huss) Wilking, CISO, advisor, board member at Wayfair
    • Patricia Titus, chief privacy and information security officer at Markel Corporation
    • Rob Zuber, CTO at CircleCI
    • Steve Chin, author and VP of developer relations at JFrog
    • Whurley, founder and CEO at Strangeworks, Inc.
    • Chris Hughes, co-founder and CISO at Aquia
    • Tracy Bannon, senior principal, software architect and DevOps advisor at MITRE Corporation
    • Christina M. Rhylander, acquisition and policy specialist at MITRE Corporation
    • Daniel Elkabes, vulnerability research team leader at WhiteSource
    • Vanessa Pegueros, board member and cybersecurity leader at OneLogin
    • Alan Shimel, founder and CEO at Techstrong Group
    • Charlene O’Hanlon, CCO at Techstrong Group

    Attendees will be able to interact with sponsors and peers, download information and participate in raffles, giveaways and other interactive activities.

    MediaOps CEO and DevOps.com Editor-in-Chief Alan Shimel will also be announcing the 2021 DevOps Dozen² Awards winners during the event.

    To check out the full agenda and to register, please visit the Predict 2022 website.

  • New Relic: Observability Tops 2022 DevOps Agenda

    New Relic: Observability Tops 2022 DevOps Agenda

    If 2021 was the year when IT organizations became aware of the need for observability, then the coming year should see observability aspirations realized.

    A report published by observability platform provider New Relic postulates that there are no less than 11 factors converging in a way that will make observability an absolute requirement for organizations.

    At the top of that list is a simple fact: Observability is now required to drive digital business transformation initiatives that typically span multiple processes. In fact, a global survey of 1,300 IT leaders, software engineers and developers conducted by New Relic found 90% of respondents view observability as critical to the business.

    Second, as a result, observability is now starting to be applied in both pre- and post-production environments as organizations take a more holistic approach to managing the software development life cycle, the report noted.

    Third, the report suggested that IT teams are looking to make better-informed decisions based more on facts than intuition. To do this, teams are using data collected from across the enterprise application environment. In fact, the fourth factor advancing observability in the enterprise is that the cost of instrumenting application environments is dropping, which the report notes is making it easier to collect relevant data.

    The fifth and sixth factors reflect a desire to rationalize the number of monitoring tools that IT teams currently use and the fact that usage-based pricing has simultaneously made it less expensive to leverage observability platforms as needed.

    The seventh factor is the overall shift toward open source software that enables observability platform providers to collectively leverage innovations faster. The eighth factor, closely linked to the open source trend, is the rise of more complex open source platforms such as Kubernetes that require much higher visibility to successfully deploy and manage.

    The ninth trend identified in the report is increased adoption of DevOps best practices that encourage IT teams to view observability as a core tenet of any IT management strategy. The tenth factor cited by the report is the need to drive increased collaboration among IT professionals.

    Finally, the eleventh factor driving further adoption of observability is the need for increased application reliability as more organizations appreciate their dependence on software to deliver essential services.

    Buddy Brewer, a group vice president and general manager for New Relic, said now that observability platforms are becoming more accessible, the next big challenge will be teaching IT professionals what questions to ask as they troubleshoot both legacy monolithic applications and a wide range of emerging microservices-based applications. The results of those queries then need to be easily shared with both developers and internal IT operations teams that must work together to maximize application performance and availability, he added. The latter requirement is why New Relic decided to acquire CodeStream to make telemetry data available with integrated development environments (IDEs), noted Brewer.

    There is, of course, no shortage of observability platforms for IT teams to adopt. In fact, the biggest challenge now is getting every application stakeholder to agree to standardize on an observability platform—no small feat, as many DevOps teams may already have a preference for one approach over another.

  • Best of 2021 – Why DevOps Will Cease to Exist

    Best of 2021 – Why DevOps Will Cease to Exist

    As we close out 2021, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the twelfth in our series of the Best of 2021.

    Nowadays I feel like there is no need to explain why DevOps as a methodology exists, as it is widely understood and accepted.

    But the reason DevOps engineers exist is not to ensure the success of its namesake methodology, nor, if we’re being honest, is the practice evolving into a role that’s viable for future progress. Rather, it’s on the verge of becoming obsolete.

    Surprisingly, in many cases having a DevOps engineer can actually get you further from the DevOps methodology objectives, rather than closer.

    How Does One Become a DevOps Engineer?

    I only recently stumbled upon DevOps courses in high-tech academies.

    Before it was an actual field of study, I’m pretty sure no one’s first step into the software development world was in a DevOps role.

    I personally started as a NOC engineer and later became a Linux administrator – developing a passion for the cloud and automation. Only years later did I dive into my first DevOps position. Others have made even lengthier journeys, starting from helpdesk support roles managing organizations’ PCs, printers and networks.

    The thing is, the starting point for people who choose a software development career starts exactly there: developing software.

    Typically, they either go to college or university or learn development online or via a bootcamp, where Linux, networking, virtualization, high availability and scaling are barely taught. And, of course, some extraordinary senior developers become infrastructure experts, but personally, I would call those folks architects and not DevOps engineers. This is probably the reason why almost every organization is in need of someone who’ll take on those responsibilities as a DevOps engineer.

    Signs of the End

    The number of cloud solutions is steadily growing every year, with cloud services becoming the dominant method of consuming business services. Gartner estimated a 40% increase in cloud services business revenue from 2020 to 2022.

    “Software as a service (SaaS) remains the largest market segment and is forecast to grow to $104.7 billion in 2020 (see table, below). The continued shift from on-premises license software to subscription-based SaaS models,” according to the firm.

    Worldwide Public Cloud Service Revenue Forecast (Millions of U.S. Dollars)

    New PaaS, SaaS and IaaS products are launched every year to make the development and maintenance of other applications easy and effortless.

    Hell, some SaaS products go as far as making it unnecessary, with platforms like WIX, Shopify, and Auth0, resulting in fewer developers being required to develop those kinds of applications. On top of that, there are already products that run almost entirely on Serverless services. Recently the term Storageless was coined and started to pop up here and there.

    At the same time, the number of developers is increasing every year. According to Statista between the years 2018 and 2019 the number of developers grew by almost a million. So, while the number of developers is growing, a big part of their responsibilities are being automated.

    This gradually frees up more time for developers to deal with DevOps challenges, which are also being automated by services like Coralogix, Datadog, JFrog, CircleCI, Gitlab and many more.

    Some companies, like Monday.com, have already acknowledged that it is not optimal to have a separate team or a single person in charge of all of the operations and maintenance of applications and that it is better to have developers responsible for their application stack from end to end.

    Although I opened by saying there is no need to explain why DevOps as a methodology exists, sometimes what gets forgotten is that DevOps evolved as a way to break down the silos between development and operations. But many organizations don’t recognize the irony of then having a separate team in charge of all operations and maintenance – that just defeats the purpose.

    Hopefully, as this trend grows, universities and coding courses will acknowledge these issues as core challenges in software development and include these subjects and principles in their curriculum.

    The Future As I See It

    This could be wishful thinking on my part, but I believe sometime in the future we will reach a point where all developers will be required to understand and practice DevOps. A developer who understands the cost of running their application, how Kubernetes assures it is always available and resilient and how to build more scalable and more secure application stacks will simply be better at their job and more valuable to their company. The opposite is also true; a DevOps engineer will be able to build better CI/CD pipelines, better monitoring solutions and cloud architectures if they are taking an active role in development and actually knows the application stack and his team’s pains and needs.

    Even if I’m wrong – and I do hope I am – I would argue that if you are a DevOps engineer or a tech lead of any sort, promoting the idea that DevOps is a part of every developer’s job is in your best interest.

    The developers who understand how to support their own environments, run internal services on private networks and understand the solutions that are available to them will simply be better at their job, enabling companies to let automated processes do their thing and focusing talent where it’s needed most to make the best use of our skill sets. Thankfully, this standard of excellence is becoming easier to reach every day; and (Do I dare say it?) perhaps, in the near future, DevOps will become less of a role and more of a service waiting for its eventual, unpreventable automation.

    Reading this, you might think that I am a self-loathing DevOps engineer who wishes to become a developer. Nothing could be further from the truth. Development Operations is my field, and I believe it’s full of talented individuals who I’m proud to call colleagues and friends. However, at the end of the day, we need to be realistic. Now that the “Operations” part of the work is mostly automated, we must focus our skills on the “Development” part.

  • Best of 2021 – The ‘Great Resignation’ in DevOps? Bah, Humbug

    As we close out 2021, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the tenth in our series of the Best of 2021.

    Like me, you have probably heard a lot about the “Great Resignation” lately. I’ll admit—at first I did not think it had anything to with tech jobs, especially not DevOps or cybersecurity jobs. After all, there aren’t many workers in those fields who aren’t well-paid (though, of course, when it comes to pay, it’s all relative). 

    When I first heard about the Great Resignation, I assumed it referred specifically to fast food workers or, perhaps, other restaurant, hospitality and retail industry jobs. You know—the kind in which people struggle to make $15 an hour. But then I began to hear it applied to better-paying tech jobs. Finally, I interviewed several executives who cited the Great Resignation as one reason that they were undermanned in key development, DevOps and cybersecurity positions.

    I know what you are thinking: Tech execs will latch on to any excuse to explain why they are short-handed in these skilled positions. I agree with you, to a point. But I have had the chance to speak with several folks at some in-person conferences I’ve attended recently (It’s just not the same online!) and I began to see a trend. The almost mythical work-life balance/quality of life trend was back with a vengeance.

    During the COVID-19 pandemic, many workers—even in highly compensated, challenging jobs like software development, DevOps, QA and cybersecurity—had actually changed their perspective as a result of working from home all those months. True, many of them had already been working from home. But they still had a “mothership” that they went to; however occasionally. They still gathered with coworkers at conferences or off-site meetings; they still were part of the “culture”.  With COVID-19, despite the best efforts of HR teams and managers to foster and nourish that “culture”, it just wasn’t the same. Much the same way we fooled ourselves into thinking Zoom and Teams were as good as in-person, we thought that we could keep our teams tightly bound and drinking the company culture Kool-Aid. 

    In place of that corporate culture, when workers weren’t working (and it did take some time for many of them to learn how to use the on/off switch), they began to actually do other things. They spent time with their immediate families. They tried new hobbies, they started (and completed!) DIY projects and more. Lo and behold, they found there was life beyond code. 

    This radical notion of doing things that were not work-related was not solely due to a failure to pay these people enough money. It was not about letting them work with the tools of their choice. It wasn’t even about who they worked with. At the end of the day, it was because they discovered they had a life, and that they enjoyed that life.

    I welcome this trend. I think it will mean less burnout and more productive humans, at the end of the day. Heck, we may even see birth rates rise and divorce rates fall. We may all live happily ever after. 

    When it comes to the Great Resignation, in the immortal words of John Belushi, “Bu-uut nooo.” Notwithstanding all of the above being true, I don’t think this is what’s leading developers, DevOps or cybersecurity folks to leave their jobs in droves. They are setting boundaries, yes, but they aren’t quitting just because of pay. No—they are leaving for the same reasons they did before. No sooner do they settle into their new jobs than they are being contacted by the ever-present recruiters offering them more money, more benefits and now more work-life balance. Add to this the growth in demand for these positions worsening an already understaffed market and there you have it. A shortage of workers to fill open positions. This convergence of circumstances makes it easier for them to hop from one job to the next, as well.

    At the end of the day, we still don’t have enough software developers, DevOps folks, QA or cybersecurity talent. This is driving the market. But Great Resignation? Bah, humbug!

  • Best of 2021 – From Agile to DevOps to DevSecOps: The Next Evolution

    Best of 2021 – From Agile to DevOps to DevSecOps: The Next Evolution

    As we close out 2021, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the ninth in our series of the Best of 2021.

    As the workforce shifts to remote locations, networks are becoming more diffuse as the edge gets farther away. At the same time, the number of devices and applications on those networks continues to rise. Some estimates suggest that, by 2030, there will be 15 connected devices for every person on the planet.

    The rapid expansion of the remote workforce and their associated application needs has created a significant challenge for both application developers and the IT professionals tasked with deployment and maintenance of applications. Finding the right balance between speed of release and stability and reliability of applications – never an easy task – is paramount for the success of any organization.

    Agile and DevOps evolved to help organizations strike this balance, providing the best possible customer experience in the shortest realistic time frame. But have Agile and DevOps fulfilled that promise?

    The Promise of the Agile Manifesto

    While Agile as a methodology has been known and followed for nearly two decades, the ways in which organizations have applied Agile have been as varied as the organizations themselves.

    The Agile manifesto set out four basic values when it was first written in 2001:

    • Individuals and interactions take precedence over processes and tools.
    • Working software takes precedence over comprehensive documentation.
    • Customer collaboration takes precedence over contract negotiation.
    • Response to change takes precedence over mindlessly following plans.

    Agile processes are applied across a range of development activities, from development of standalone applications to development of cloud-native business applications. The Agile Manifesto also contains several more principles that further explain what the values mean when put in practice.

    These Agile principles can be condensed into a few areas of focus:

    Prioritize the customer over the product

    Agile development requires continuous customer engagement throughout the entire development process, with the end goal being frequent product delivery based on specific customer feedback. While this can present challenges for an Agile team, particularly when customers demand changes late in the development cycle, Agile maintains that the best way to elevate customer experience is to make the customer part of the development process.

    Trust Agile Teams to Self-Organize and Self-Manage

    Agile focuses on smaller teams that remain in constant communication with customers, as well as with each other. These teams should include both developers and those with knowledge of the larger business requirements being met through development. For these teams to work effectively, trust is key. Agile posits that self-organized teams, given leeway to pursue their projects in the way they see fit, result in the shortest development cycles.

    Keep it Simple

    Agile teams require simplicity. This correlates with Agile’s disdain for overuse of process. Agile seeks to minimize the total amount of work required, thus minimizing overall development time.

    Agility Leads to Agility

    Just as Agile teams continuously improve their product and the customer experience, they also constantly improve themselves. Constant evolution of teams and the processes they employ (remember, teams before processes) improves team agility itself.

    While the Agile values and principles seem simple, effective application of the values and principles is another story entirely. Indeed, at times, the implementation of Agile development has violated the very first value of the manifesto by focusing on which tools and processes should be used. But, in an environment where more users are clamoring for more products and services, implementation of Agile methodologies is not just important, it is imperative.

    Building on Agile with DevOps

    The precise meaning of the term itself and the scope of DevOps remain a source of debate. At a high level, DevOps is the marriage of the development cycle with post-development activities, such as deployment and maintenance.

    According to open source contributor Barbara Ericson of Cloud Defense, “Instead of IT operations and software development being siloed off from each other, DevOps breaks down the traditional boundaries that previously existed between them in order to achieve continuous integration and continuous delivery (CI/CD) of quality software features and applications to end users.”

    Just as with Agile, the effective implementation of DevOps requires cultivating a DevOps culture within the organization. However, Agile and DevOps are also not mutually exclusive. That is to say, DevOps is not merely a replacement for or an evolution of Agile. Although Agile and DevOps differ in their structures and approaches, they can work in unison to achieve the ultimate goals of speedy deployment and enhanced customer experience.

    While Agile and DevOps share common goals, they have not always agreed on how to achieve those goals. DevOps differs in many respects from Agile, but, at its best, DevOps applies Agile methodologies, along with lean manufacturing principles, to speed up software deployment.

    One area of particular tension between Agile and DevOps is that the latter relies heavily on tools; in particular, when it comes to the automation of testing and deployment processes. But DevOps can overcome the resistance of Agile developers to tool usage simply by applying Agile principles themselves.

    Effectively, DevOps proponents must convince Agile teams that dogmatic adherence to the underlying principles of Agile is actually inconsistent with Agile in the first place. Ironically, Agile developers who insist that the process is always bad actually violate Agile principles by refusing to acknowledge the benefits offered through change, another Agile principle.

    The challenge is to have the Agile development teams trust in the automation efforts of DevOps, while at the same time encouraging the DevOps team to consider the business goals of deployment rather than pursuing speed of deployment for its own sake.

    With constant communication between the Agile team and DevOps team (another Agile principle), development can achieve a degree of comfort with DevOps tasks and processes. This means that testing and deployment automation can proceed quickly, resulting in a decreased time to market, overall.

    Ultimately, Agile and DevOps can work together most effectively when they recall their shared goals: smaller change increments based on feedback resulting in faster delivery cycles.

    Continued Evolution: DevSecOps

    As networks expand and businesses continue to integrate cloud-based services (in many cases, building multi-cloud environments), security issues become more and more complex. One area in which Agile is lacking is in integrating security into the development process. Unfortunately, in an Agile environment, application security is often an issue addressed after development, rather than as part of the process. Enter the next iteration of DevOps: DevSecOps.

    DevSecOps revolves around three basic principles: ensuring data security while minimizing inconvenience for users in accessing data, using development tools that identify risks as early as possible in the development process and ensuring data encryption using technologies such as secure sockets layer (SSL) and virtual private networks (VPNs).

    While DevSecOps and Agile may also disagree about the priority of tools, security must become an integral part of any development project. This is why Agile, DevOps and DevSecOps must all work together to ensure not only rapid deployment but secure deployment.

    The Next Evolution

    Agile and DevOps were both important evolutions of the software development process, but DevSecOps is the next evolutionary step. Despite a few disparate characteristics, Agile, DevOps and DevSecOps can and should work in unison to achieve their shared goal: the best possible customer experience and short deployment cycles.

  • Best of 2021 – The Next Evolutions of DevOps

    Best of 2021 – The Next Evolutions of DevOps

    As we close out 2021, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the seventh in our series of the Best of 2021.

    As society continues to recover from the global COVID-19 pandemic and some semblance of normal starts to return, technology continues to move forward. The pandemic certainly changed what normal means and people, processes and technologies all have adapted and evolved to meet those challenges. The narrative that the pandemic caused of your organization’s digital transformation is true for many practitioners. With 2022 just around the corner, DevOps is on the cusp of maturation of previously bleeding-edge paradigms and a focus on engineering efficiency. Here are five DevOps evolutions you should keep an eye on going forward.

    Engineering Efficiency is Front and Center 

    Engineering efficiency is a particularly broad umbrella term. At the foundational level, engineering efficiency focuses on making someone (for example, an engineer) more productive. There are a multitude of disciplines that intersect, from organizational design to engineering/developer experience. Engineering efficiency is increasingly critical for organizations today. The pandemic had two major impacts on the technology sector in terms of resources and staffing. The first, at the start of the pandemic, was the unprecedented and unpredictable availability of resources; physical locations were being shut down because of the medical severity of the pandemic and the “getting hit by a bus” factor was playing out in real life. Second, during the recovery period, the Great Resignation began, and with it, a fight for resources that has become increasingly intense. Both have meant that the availability of resources, especially ramped resources, is scarce. 

    The Spotify model of tribes/guilds of engineering resources is a promising evolution; folks can frequently move around, reducing the toil that engineering resources face and allowing for engineering resources to not only ramp up more quickly but also increasing engagement and retention. The industry continues to march toward standardization in areas that were typically bespoke, such as the release process, and I think we’ll see that continue to evolve, as well.

    Git is Ubiquitous

    Leveraging a source code management (SCM) solution used to be reserved for software engineers. But as the proliferation of “something-as-code” has touched multiple levels of the technology stack from networking, storage and, ultimately, a development pipeline, the march of operations-focused engineers adopting many of the traits of software engineers continues. Having iteration in your infrastructure stack with more ephemeral/disposable infrastructure is becoming the norm. Saving and packaging the multitude of configurations for the “something-as-code” source control is a natural area of evolution. 

    Building off of source control are the package managers—your Docker registries, Helm chart repositories, etc.—for more deployable artifacts; that said, getting those artifacts to production is a process. Because Git is becoming ubiquitous across the technology landscape, this leads to the continued adoption of GitOps. Since the seminal piece was written by Weaveworks in 2017 defining the GitOps paradigm, leveraging GitOps is seen as a viable paradigm for many organizations five years later, especially when starting with greenfield initiatives. 

    Kubernetes is No Longer Bleeding Edge

    In 2022, Kubernetes will celebrate the eighth birthday of its first commits on GitHub. Taking a jog down technology memory lane, eight years before Kubernetes (in 2006), VMware was still a private company and it would be a few years before vSphere was even released (remember how it felt to run a workload on a virtual machine in 2014?). The Kubernetes ecosystem still moves quickly, but placing workloads on Kubernetes is not a novel concept anymore. As application infrastructure and architecture have adopted the Kubernetes way (in other words, being idempotent and ephemeral), there is maturity around running a suitable workload on Kubernetes.  

    Kubernetes by design is highly pluggable. If you do not like the opinion or implementation of something inside Kubernetes, you can replace that opinion. Don’t like how Kubernetes handles ingress traffic? Then choose from one of the many ingress controllers available today. That is just one example of dozens of pluggable areas. Because of this, Kubernetes is viewed as a dynamic, non-static resource. Using Kubernetes takes trial and error and getting your cluster to be robust, performant and reliable is an ongoing journey that requires ongoing iteration. 

    Authors Can Be the Enforcers

    There is no question that in a modern software stack, we are inundated with data. The metrics soup and the continued science of and exploration of observability (metrics, traces, logs) provide us with a lot to work with. Making decisions, even automated ones, based on that data continues to be critical. With the rise of site reliability engineering (SRE) practices, reacting or anticipating spikes in usage, failures and even security-related items are par for the course for modern teams. 

    These decisions can be authored into policies that specific platforms understand, such as autoscaling rules for a cloud vendor or something like Open Policy Agent in the Kubernetes ecosystem. With so many items shifting left toward the development team, finding the right resource, skillset or institutional knowledge to author these rules can involve the input of several teams. Because of the rise of “something-as-code,” regardless of whether the author of these rules is a software engineer, DevOps engineer, platform engineer or anyone in between, that author has the ability to enforce. 

    Shifting Left … But Complexity Shifts Left, Too

    The old adage is that complexity is like an abacus: You can shift complexity around, but it never really goes away. With the movement to shift responsibility left to development teams, this also means that associated complexity is shifting to the development teams. Modern platform engineering teams provide the infrastructure (compliant Kubernetes clusters) to teams and any workload that is run on those clusters is up to the development team that owns it.  Typically, development teams then focus on features and functionality. Managing lots of non-functional requirements—and even core infrastructure requirements such as networking—can be a burden; think about how your organization would handle a service mesh.

    If you are a DevOps or platform engineer, making your internal customers—your development teams—successful is a great goal to work toward. Crucial to this is disseminating expertise. This can be in the form of automation and education. A common practice with the DevSecOps movement is to have some sort of scanning step as part of the build or deployment process, disseminating the internals as far as how the scan is performed, what happens if something is found, etc. Gaining internal adoption is a journey and having a good developer experience built around clarity and stability are important. 

    Evolution in 2022

    Even with all of the challenges, bumps and learnings that the last year has given us, technology continues to evolve and advance and even lower the barriers of entry to continually become more inclusive. Focusing on improving engineering efficiency and reducing toil will allow for more participation and lower the barriers to entry.

     

  • Only 30% of Orgs Fully Implement DevSecOps

    Only 30% of Orgs Fully Implement DevSecOps

    With the pressure to release more rapidly, security is shifting left within the continuous development pipeline at most organizations. This imperative is increasing with the rise of cyberattacks. Yet both a lack of training and poor visibility are stalling many DevSecOps rollouts, a recent CSA study found.

    DevSecOps is still a relatively new practice and has yet to reach maturity throughout most organizations. Though nearly all companies are on their way, only 30% of security professionals say they fully implement DevSecOps in practice today. That leaves most organizations in some state of DevSecOps ideation and planning.

    CSA recently released its Secure DevOps and Misconfigurations 2021 report which was commissioned by Trend Micro. The report found that misconfigurations commonly arise from default security settings. A lack of internal guidance and accessibility of security resources commonly hinder DevSecOps maturity, too.

    Below, I’ll review the other major takeaways from the report to see how they can inform organizations as they move to implement DevSecOps.

    State of DevSecOps Adoption

    DevSecOps is all about increasing the security around rapid deployment. It literally puts the security into DevOps by shifting security automation left and de-siloing the boundary between DevOps and IT security teams.

    While most engineers realize the benefits of DevSecOps, the state of each organization’s DevSecOps journey is very different. While an impressive 90% of organizations are in some phase of the journey toward DevSecOps, only 30% are implementing DevSecOps while 24% are in the planning phase, 18% are designing and 18% are still refining their DevSecOps strategy. Just over one in ten security professionals say their team has no plans to invest in DevSecOps at all.

    Looking to the future, 42% say they will implement full DevSecOps within the next 12 months. But due to its current nascent state, misconfigurations are still getting through. The primary reason cited for these misconfigurations was flawed or lacking internal guidance (33%).

    Many professionals say there is simply not enough training, support or internal knowledge around vulnerabilities and misconfigurations. Other top reasons for misconfigurations include insecure default settings (18%) and negligence (16%).

    Outside of misconfigurations, groups also report challenges with identity, authorization and access. Ensuring the correct privileges is vital to avoid escalation attacks, which are a prevalent issue. Between 2019 and 2020, 80% of companies experienced a data breach of some kind, many of which were due to misconfigured access controls. OWASP also reported that broken authorization is a top vulnerability for high-traffic web API endpoints.

    Common Threat Mitigation Practices

    To mitigate these threats, development and security teams must maintain best practices, yet certain issues prevent DevSecOps from emerging. For one, 60% of security professionals say their top challenge is insufficient visibility into security or compliance gaps—this is by far the most common challenge—and 11% also cite inconsistent cloud account onboarding. Finally, 10% say time-consuming, slow and/or insufficient architecture holds them back.

    One way to mitigate threats is to introduce routine security reviews more frequently. Yet it’s hard to set a definite benchmark here, as the frequency at which organizations review their cloud infrastructure for vulnerabilities or misconfigurations varies widely. Currently, 22% perform such security reviews daily, 22% monthly, 18% weekly and 23% quarterly, according to the survey. This rate will likely increase as DevSecOps becomes more commonplace and automated within the development life cycle.

    Staying up-to-date with modern security frameworks is another facet impacting DevSecOps adoption; and organizations tend to follow multiple frameworks to inform their security strategy. More than three-quarters (78%) follow the National Institute of Standards and Technology (NIST) guidelines, 67% follow the Center for Internet Security (CIS) benchmarks, 66% follow Cloud Security Alliance (CSA), 54% follow International Organization for Standardization (ISO) and 44% say they follow security recommendations from Amazon Web Services (AWS).

    For example, NIST, the government-operated standards-setting body, recently set cybersecurity guidelines that recommended the use of zero-trust and service mesh across departments. These security guidelines can be thought of as architectural benchmarks, especially for large, highly-regulated industries.

    DevSecOps Training Types

    Finally, investing in community resources and training is another way to increase DevSecOps awareness. Only half of survey respondents reported their DevSecOps best practices resources were moderately accessible—thus, the onus is on leaders to democratize such knowledge within their organization.

    The majority (81%) of respondents cited online articles and training as their primary form of learning about cloud security tools and vendors. Workshops, conferences and webinars follow closely. Organizations also adopt many internal knowledge-sharing methods in response to incidents. A full 85% said they conduct awareness training followed by table-top exercises (52%), attack simulations (45%) and protocol or response framework training (37%).

    Future DevSecOps In The Cloud

    It appears that most teams are still formulating their DevSecOps strategy. But looking to the future, 42% say they will implement full DevSecOps within the next 12 months. Simultaneously, more cloud traction is projected throughout the industry.

    Right now, 40% of organizations have between 41% to 99% of their workloads in the public cloud. And 55% of organizations will have between 41% to 99% of their workloads in the public cloud in the coming year. The type of workloads will also likely evolve in the coming year, as more organizations move to container platforms, Function-as-a-service and other serverless capabilities. To fully reap the benefits these new technologies promise, organizations must undoubtedly respond to a new class of cloud-native vulnerabilities.

    About The Report

    The Cloud Security Alliance (CSA) is a not-for-profit organization with a mission to widely promote best practices for ensuring cybersecurity in cloud computing and IT technologies. The Secure DevOps and Misconfigurations survey was conducted from July 2021 through September 2021 and collected over 900 responses from a global pool of IT security professionals working in various sectors and organizational sizes. For a full copy of the report, you can swap some personal information for a PDF download here.

  • Best of 2021 – Seven Reasons You Shouldn’t Hire a DevOps Engineer

    Best of 2021 – Seven Reasons You Shouldn’t Hire a DevOps Engineer

    As we close out 2021, we at DevOps.com wanted to highlight the most popular articles of the year. Following is the fifth in our series of the Best of 2021.

    DevOps is a culture, not a title. Therefore, companies should follow DevOps principles, rather than hiring one savant to fix an entire organization’s delivery model.

    I recently spoke with Uri Zaidenwerg, DevOps lead at Replix, to understand the current state of DevOps. As more robust DevOps tools emerge and practices proliferate across organizations, developers are now better equipped to own their applications end to end, including deployment, security and even cloud costs.

    Extracting DevOps from the development cycle could defeat the purpose of de-siloing development and operations. Below, we’ll outline some reasons why you should focus on building a holistic culture instead of filling a DevOps engineer role.

    1. DevOps Is a Culture, Not a Role

    The first reason is also the most encompassing — DevOps is not a title; it is a culture. DevOps functions best as a mindset adopted across IT. Instead of hiring a dedicated role, all “developers should be doing operations,” said Zaidenwerg.

    This means giving developers better visibility into DevOps KPIs, such as deployment frequency, deployment time, change failure rate, time to detection and availability, which we’ll explain in detail below.

    2. Developers Know Their Application Code Best

    Developers know their code better than anyone else. Diagnosing errors in an unfamiliar environment is tricky, and only programmers truly comprehend the ins and outs of their own code. If armed with DevOps skills, they could address problems much more efficiently than external eyes.

    Zaidenwerg worked as a DevOps systems administrator, and described “what it’s like to have to monitor availability of an application that you did not code or build.” It’s difficult; simultaneously diagnosing multiple applications that you don’t know intimately is also quite challenging, he explained.

    If you are unable to link errors to application processes quickly, it could hurt availability and SLAs. Instead, encouraging developers to diagnose issues could reduce time to remediation because they have more context, noted Zaidenwerg.

    3. Developers See the Surrounding Environment

    In addition to understanding how individual applications function, developers also have unique perspective into the surrounding environment — they realize the intricate network of dependencies and interconnections that make up a microservices system.

    To see what’s going on, you really need to know how to code. “DevOps engineers need to be software developers,” said Zaidenwerg. Handing off DevOps tasks to an administrator who doesn’t have coding knowledge can severely limit their ability. They will not be able to dig into the code to address real issues or make pull requests confidently.

    4. Separating Roles Keeps Ops in a Silo

    Relegating DevOps responsibilities to a centralized team goes against a fundamental principle: de-siloing departments. “DevOps was invented to make that gap smaller,” said Zaidenwerg. Having a separate role would thus appear to contradict one of the fundamental tenets of the methodology.

    “The point of a DevOps practice is that developer teams are empowered to control their own operations, not that you have specialists who know how to script operations,” said Tom Marsh, principal developer at Novartis, on Quora.

    5. One DevOps Engineer Can’t Fight a Flood

    As it stands, there are aren’t enough DevOps engineers to go around. According to answers on Quora, the ratio of DevOps engineers to developers tends to stand between 1:10 to 1:12. Zaidenwerg said he’s seen worse — from 5:50 to 6:120. Instead, he said, “Zero to zero is the optimal number.”

    One DevOps engineer against a tidal wave of requests and application deployment pipelines is just not sustainable. “Can you imagine the amount of features and code that has been written?” asked Zaidenwerg. “The amount of fires they need to put out is huge.” And what happens when that single DevOps engineer goes on vacation? To avoid delays, he encourages developers to own their CI/CD process from end to end.

    6. What Happens When DevOps Engineers Automate Their Job Away?

    Another creed of DevOps and SRE practices is to introduce automation – with the ultimate goal being to automate their job away. But, if this were actually to occur, what happens to the DevOps engineer? Do they sit back and rake in the dividends of some upfront work for years afterward? It would make more sense to have programmers introduce automation into their workflows.

    7. K8s + Other DevOps Tooling Empowers Developers

    Powerful DevOps tools like Kubernetes, ELK stack and cloud infrastructure solutions now make it far more realistic to delegate more responsibility to the programmer themself. Democratizing “as-a-service” solutions for monitoring, load balancing or storage enables everyone to “share the burden of the DevOps work,” said Zaidenwerg.

    Many organizations have begun to treat Kubernetes as a source of truth. Zaidenwerg wholeheartedly encourages this practice. “Everything should be managed on K8s, from K8s,” he said. “Try and think of K8s as your lowest layer.” Standardizing microservices around K8s helps retain platform-agnosticism for multi-cloud, he added.

    How to Get There? Track DevOps KPIs

    So, if we aren’t delegating DevOps tasks to a DevOps engineer, how can we encourage developers to embrace DevOps principles? To Zaidenwerg, the answer boils down to how we define success. Instead of gauging success using traditional development output metrics such as productivity, scrum or number of tasks completed, we need a culture that measures developer work using DevOps key performance indicators (KPIs).

    There are many DevOps KPIs to consider. Some could be:

    • Deployment frequency: How often do you commit?
    • Deployment time: How long does it take from committing to the live environment?
    • Automation: How automated is the build process?
    • Availability: Is the program globally available and highly performant? What is the latency and uptime?
    • Monitoring: Are you proactively monitoring and fixing issues in live environments?
    • Optimizations: Is the application cost-effective? Can it be more efficient? Are there idle resources running?
    • Policy as code: Are security policies automated as code? “Security needs to be written in code … if it’s done manually, you’re f**ked,” Zaidenberg said, bluntly.
    • DRP: Is the application resilient? What is the disaster recovery plan (DRP)?

    Of the above KPIs, optimization stands out, as rising cloud costs are an ever-present hurdle these days. Zaidenwerg encouraged developers to track cloud environment expenses. When you have a daily graph of spending, you can use this visibility to “create supporting systems to automatically take idle resources down,” he said. Others have described this as BizDevSecOps.

    Encouraging DevOps Culture

    Our cheeky headline is not meant to devalue those with DevOps in their title — on the contrary — hiring someone with this rare experience could greatly assist organizations in introducing DevOps principles. They could act as a model to help cultivate this culture.

    In addition to tracking KPIs, Zaidenwerg recommended a top-down approach to spread DevOps principles. The methodology must be sanctioned and led by the CTO, architect or tech lead, depending on the company’s size. A DevOps culture is especially paramount for SaaS or IaaS companies, whose architecture must be more than error-proof —  “It must succeed every single time,” Zaidenwerg stated.

    Disseminating modern cloud best practices is also critical for building a DevOps culture. When you transition from hardware to the cloud, you often encounter similar tech (load balancers, firewalls, availability zones, etc.), yet with different names and implementation processes for each function, complicated by nuances between cloud service providers (CSPs). All this will require “translating on-premises best practices to cloud best practices,” described Zaidenwerg.

    Another significant issue arises from the fact that DevOps isn’t really taught in college-level computer science courses. Looking to the future, Zaidenwerg (and myself) hope to see more emphasis within the education system. Instilling a DevOps mindset early on would better prepare developers for more real-world settings encompassing deployment, availability and security-as-code.

    Whose House Is It?

    Zaidenwerg likens a software application to someone’s house. The homeowner knows every detail — where the utensils are, how to work the shower nozzle, what day trash is picked up, etc. Invite a stranger into a new house, and they will be at a loss.

    Similarly, inviting external Ops to manage a foreign infrastructure will put them at a loss. “If you let someone else deal with infrastructure, then you have two parties and no one is fully aware,” Zaidenwerg said.

    To summarize — DevOps is a culture, not a role. Treating DevOps as a role, instead of as a practice, could defeat the purpose and cause siloed, slower-moving teams. Instead, tracking KPIs and empowering developers with DevOps tools could help them keep their house in order.

    Of course, this is an evolving practice, and each organization will have its own understanding of what it means to implement DevOps. Now, do you still think it warrants the title? Please let us know in the comments below!