Category: DevOps Culture

  • How To Build a Culture of Resilience Through Good Habits

    How To Build a Culture of Resilience Through Good Habits

    Good habits are hard to form. I’ve been listening to the audiobook “Atomic Habits“ by James Clear on my morning runs, and something struck me. At Gremlin, along with our software, what we’re trying to promote are positive new habits for our customers. According to the author, one of the primary reasons new habits don’t stick is because there’s often sacrifice without immediate gratification.

    Psychologically, we’re wired to want instant gratification. But not all habits give immediate rewards; in fact, many delay our gratification for some time. So how do we help ourselves pursue good habits? Put simply: We need to make them obvious, attractive and easy.

    One of the ways to make them easy is to focus on what the author calls “gateway habits”—the smallest piece of the habit that can reasonably be achieved in two minutes. So if your goal is to eventually run a marathon, the gateway habit is putting on your running shoes every day.

    To build a culture of resilience at your company, start small and create getaway habits. If a team runs a GameDay once a month (time dedicated to experimenting on your systems) or even simply runs their first single chaos engineering experiment, then award that person or team with immediate recognition.

    Here are some other ways to build a culture of resilience at your organization:

    • Recognize the change to new habits.
    • Create DNR (do not repeat) items.
    • Adopt “You build it, you own it.”
    • Track the four golden signals.

    Recognize the Change to New Habits

    Incentives are a great way of kick-starting a new habit, but they don’t necessarily sustain the good behavior. It’s identifying the improvements that result from the new habit that really makes it stick. We’ll get to some specific metrics you can track later in the article, but notice for now that identifying the improvements is when gratification starts to drive enthusiasm. Ideally, that enthusiasm grows until the new habit becomes part of your identity.

    In our example of running a marathon, the moment of most significant change is when the person starts to self-identify as a runner. Then, the habit is no longer a chore, but rather part of who they are. Ideally, we want all computer engineers to adopt a specific set of habits until they consider themselves site reliability engineers (SREs) as part of their identity. That’s when the habit is solidified. 

    Create DNR (Do Not Repeat) Items

    Engineers and product managers want to ship new products and features. There’s nothing quite as satisfying in software development as deploying new code and seeing what you built running out in the world. But, if what you built is consistently breaking or providing a bad user experience, then you are hurting your customers and ultimately your business.

    To make sure we are always learning and getting better, at Gremlin we have what we call “DNR,” or Do Not Repeat work. This work consists of action items from outages and incidents that must not ever be repeated, lest we fail to learn our lesson from these failures. Practically, what this means is all feature work is halted until the issues highlighted as DNR work are remedied and the fixes are verified. In other words, you don’t get to write new code until your old code is fixed. We all know that many teams struggle with the trade-offs of moving fast, but ultimately, if you don’t have strict guidelines in place, then more often than not engineers will prioritize shipping something over making sure it’s reliable.

    Creating a DNR item is an easy way to incentivize the behavior you want to see internally by appealing to the engineer’s desire to produce new features. We convince them to write better code because better code means they get to spend less time fixing things.

    Adopt “You Build It, You Own It”

    This is the driving principle of DevOps. It is the reason behind shifting left. When the team that develops the software is different from the team that operates it, then there’s a misalignment of incentives. If I am a developer being tracked (and promoted) solely on the amount of code I ship, my focus will be on getting more bits out the door and not on ensuring the features I release will withstand the burdens of operation. That’s another team’s concern.

    That’s the motivation behind the proliferation of the “you build it, you own it” mindset at top-performing organizations. Hell, my first day at Amazon, they tossed me a pager and said “Good luck.” And while that may sound daunting (and it was), I can tell you that it not only motivated me to make sure I built systems to last, but it also fundamentally changed the way I thought about architecting systems. Spoiler: I’m not a big fan of my pager going off at 3 in the morning.

    In other words, the person or team building the system needs to be the same person or team that feels the pain if that system is failing. But it’s not just about punishment and pain, that team also needs to be recognized and rewarded when their system is running reliably. This creates an alignment of incentives that promotes the kind of habits seen across top-performing teams.

    Track the Four Golden Signals

    In monitoring distributed systems, Google’s SRE book outlines the four golden signals of monitoring as latency, traffic, errors and saturation. If I could wave a magic wand and immediately improve the culture of an organization, then I would have service-level objectives (SLOs) tied to these four metrics. But going back to habit formation: If you make acquiring a habit too difficult upfront, then an engineering team will ultimately reject it. So if your organization isn’t mature enough to create SLOs, simply beginning to track these metrics will up-level your game tremendously. They will give you an understanding of what is not working well and help guide your priorities.

    To Summarize

    Imagine a world where, after a major incident happens, the points of failure involved become DNR work. The same failure is not allowed to happen again and no new feature work will be completed until the fixes are implemented. And more importantly, no new feature work will be completed until those fixes are verified via a chaos engineering experiment, which is then cataloged and run continuously against your system. Then you take that knowledge and share it with other teams so they can run the same experiments and make sure they are immune to those failures as well.

    This is how you build a culture of resilience.

  • The Secret to Winning at DevOps: Are You Up for the Challenge?

    The Secret to Winning at DevOps: Are You Up for the Challenge?

    The main idea behind DevOps is to enable companies to keep up with the increased software velocity and advancements in agile culture for a smoother end-to-end software delivery cycle.

    The main goal of DevOps is to accomplish integration and automation, which is why implementing this philosophy can be challenging. Not only do you need to replace older methods and practices, but you’ll also have to change the mindset of the developers and the operations team to ensure they work in sync.

    Several IT operations teams and software teams have adopted DevOps practices into their work culture for faster evolvement and improved innovations. The pipeline comprises continuous integration, testing, deployment, as well as monitoring application and system performance.

    Introducing new DevOps tools and changing the mindset to prepare teams for the fast-paced world remains crucial for a successful implementation.

    Despite the revolution that this philosophy brings to software development, several enterprises find themselves taking DevOps to an unproductive extreme. To remain productive, one of the aspects that teams need to work on is reducing rework, and the best way to ensure this is automation.

    Understand How DevOps Works

    Under a DevOps model, the development and operations teams are integrated into one to prevent them from getting siloed. This also improves collaboration and productivity.

    You see, it brings alive the possibility of both the teams thinking more alike, working together and sharing responsibilities. This is done by automating code testing and workflows, automating infrastructure and continuously measuring application performance.

    In some models, even the QA and security teams merge with the dev and ops. In cases where security becomes the primary focus, the name gets modified to DevSecOps.

    In essence, the focus of DevOps is on automating processes that were otherwise manual and slow. Teams use a technology stack and tooling that can operate and evolve applications more reliably and swiftly. As engineers will be able to accomplish tasks such as deploying code and provisioning infrastructure faster with reduced issues, teams can reach testing and maintenance stages quicker.

    Balance Between Standardization and Adaptability

    Software products are mostly developed from the customers’ perspective, and if not, from end-user experience. Often, developers work backward to identify customer needs and wants for ascertaining successful innovation.

    One of the biggest challenges when developing a software development life cycle (SDLC) strategy for organizations is to consider dynamic customer needs, strict compliance policies, unpredictable market trends and company goals. To ensure a consistent workflow, DevOps teams need to adopt standardization. In fact, workflows, technologies, processes, protocols and metrics need to be standardized before they can be automated.

    This is also the main reason why organizations adopting DevOps need to strike a balance between standardization and adaptability. One industry that has excelled at this has been the financial industry, which has been leading the charge when it comes to adopting the latest software delivery practices and technologies, including DevOps. Financial executives view DevOps as being a way to improve security and risk and governance strategies. 

    The result is that cloud-based financial services are now automating virtually all of their processes through their software delivering pipelines, which makes tasks such as scanning receipts, sending invoices, tracking expenses or making payments seamless as they sync to your account. This simpler process is beneficial for boosting developer productivity and resource utilization, and for enabling enterprise scale management. If anything automating processes is becoming necessary for achieving higher product quality, compliance and scalability. 

    As mentioned above, new DevOps tools need to be introduced to team members to keep up with the constantly evolving strategies and implementation. But to prevent the creation of silos between teams, mechanisms need to be developed to make the adoption of new technologies easier. 

    Achieving the delicate balance between standardization and automation will help eliminate communication gaps, performance bottlenecks and silos between the different teams.

    Benefits of Automation in the DevOps Landscape

    The following are the advantages of adopting a DevOps philosophy:

    • Code Development. Source control will keep everyone in the loop by managing, tracking and documenting any changes in code. This can be time-saving, and reduce the complexity of software projects.
    • Smoother Testing. Testing is a continuous process in DevOps frameworks that includes system communication, several test integrations, predicting and tracking issues, and integrating approved automated builds. In the absence of automation, executing and managing continuous testing could be a rather tedious job that might cause problems between developers and the operations team.
    • Better Visibility. The main job of the ops teams is to be aware of the code changes, ongoing problems and the impact of a specific code on the end goals. Plus, when they operate in a DevOps environment, they need to keep the developers in the loop as well.
      For example, if a system administrator from the ops team identifies code issues weeks after submission, it puts more pressure on developers. Now, the developers have two jobs: solve the problem in the previous code, and simultaneously work on making progress with the new code. This is what gets time-consuming, which can harm the company’s market standing. To remain ahead in the competition, innovation needs to be frequent and accurate.
      When there is a constant feedback loop between the dev, ops and QA, bottlenecks, and silos are eliminated, productivity is improved and customers are happier due to quicker innovation.
    • Continuous Integration and Delivery. Automation can help deliver appropriate software built, data, code changes and tests to target environments. An example is how web hosts for e-commerce businesses need to be updated frequently for robust deployments. Automated testing will help ensure that code is delivered properly and doesn’t introduce new bugs, thus creating a platform with a superior user experience.
      This, in turn, helps DevOps teams to introduce frequent software changes by deploying error-free codes and continuous testing.
    • Data Processing and Monitoring. The teams also need to measure and monitor the performance of their environment, which can be done by reading and analyzing system logs. But the existence of hundreds or thousands of servers in the environment can make it complicated.
      Automation will allow the teams to make sense of all the data and let them know how an application is performing and whether there are any bottlenecks.

    Getting the Balance Right

    Organizations need to realize that automation involves placing technologies around once-manual processes. The catch here is as the processes will become inherently repeatable, they need to be correct. Otherwise, organizations will only have flawed processes running faster, which will ultimately defeat the purpose of adopting DevOps in the first place.

    Companies need to understand adaptability as well. This can be done by mixing both the old as well as new systems. For this purpose, an inventory of all applications, data stores and development processes for promoting meta development processes that include design, development, testing, deployment, configuration management and so on can be made.

    In the end, the secret to winning DevOps is aligning DevOps tools with your organization’s goals – not following the footsteps of other organizations.

  • DevOps Deeper Dive: IT Terminology Matters

    DevOps Deeper Dive: IT Terminology Matters

    Much like any other profession, the IT industry does not exist in a vacuum. Social upheaval will have as much impact on IT professionals as it does on any other. As conversations concerning race relations become more heated and, hopefully, elevated, many in the IT industry are reconsidering the use of terminology such as master/slave to describe the relationship between applications and devices.

    GitHub this week announced this week it will be changing the term “master” as it is applied to its repository to a neutral term. Use of the phrase master/slave as a means to describe relationships between software and hardware has been employed since the very early days of IT. In fact, some would note the concept of slavery stretches back to the dawn of time.

    Nevertheless, too many of the terms used in IT evoke a sense of domination that reflects a white, male view of the world, said Dr. Shuli Goodman, executive director of LF Energy, an arm of the Linux Foundation committed to combating climate change by modernizing the power grid using open source software.

    “Language reflects our mental models,” she said.

    The IT industry in general would be better off embracing, for example, biological models rather than terminology that suggests domination and submissiveness, noted Goodman.

    Even IBM, which provides some of the oldest and most venerable platforms in the industry, is open to having this conversation.

    The company is committed to recognizing the experiences of everyone in the IT community, said Sanjay Chandru, director of IBM Z DevOps.

    “If that means we need to have a conversation about terminology, we’re open to that,” he said. “Personally, I think GitHub did the right thing.”

    The time to make a mental shift might never be better, said JFrog CEO Shlomi Ben Haim. The IT industry is transitioning toward a more distributed approach to computing that relies less on centralization. As more workloads shift to the edge, IT environments will need frameworks that span everything from the edge to the cloud, he said.

    As a result, the IT industry as a whole is shifting more toward a peer-to-peer relationship between software and hardware, he added. “We need IT to be more flexible.”

    The history of IT is marked by pendulum swings between centralized and distributed computing. Arguably, the rise of cloud computing represented a shift back toward a more centralized approach to computing that has a lot in common with the way mainframes were deployed and managed more than 50 years ago.

    PCs, on the other hand, were at the forefront of a wave of distributed computing that in many cases simply became too unwieldy to manage. Cloud computing afforded IT organizations an opportunity to centralize the management of workloads. However, with the rise of edge computing, workloads might soon be more distributed than ever.

    As is often the case when it comes to IT trends, it’s likely new terminology will soon emerge to describe the relationship between highly distributed instances of software and hardware. Hopefully, more perspective will be brought to bear not only on what those terms mean from a technical perspective but also how they might be perceived both inside IT and socially.

  • Fostering Better Collaboration Between ITOps and Security Teams Should Be Top Priority

    Fostering Better Collaboration Between ITOps and Security Teams Should Be Top Priority

    Last year, the average business lost $13 million to cybercrime, which is 12% more than in 2017 and 72% more than in 2014. When Tanium recently asked IT decision makers how they planned to reduce that risk in 2020, they reported making multi-million dollar investments across operations and security. Over the last two years, they increased operations budgets by 11% and allocated 18% more funding to security teams.

    However, despite massive budget increases, both operations and security teams continue to struggle. Only half of the teams that Tanium surveyed said they had full visibility into their environments’ vulnerabilities and risks (51%), and less than half said they had full visibility into all of the hardware and software connected to their networks.

    Businesses are investing more in tools than ever before, but the issue isn’t more investment — it’s the right investment. “More tools” aren’t bringing siloed IT teams closer together, and aren’t achieving the kind of total visibility and control of all endpoints needed for effective risk mitigation.

    Here are some ways to reconsider the crucial collaboration between IT operations and security teams.

    Find Areas to Align

    While just 27% of the enterprises we consulted on these issues would describe their IT teams as “embedded,” as many as 67% said that coordination among teams is extremely challenging. Aligning the security and operations teams is one way to overcome this challenge. Different teams using different tools and receiving different data sets have little room for compromise, but teams united by a common toolset are not only more likely to collaborate; they are also better resourced to mitigate risk and protect valuable data. As teams do away with the point tools and invest in coordinated, platform-based solutions, their ability to easily verify the quality of their data, trust their vulnerability scans and remediate threats at scale will significantly improve.

    Prioritize Visibility Across the Environment

    While most IT decision makers (80%) believed they could instantly act on the results of their own vulnerability scans, fewer than half (49%) thought they had full visibility into all the hardware and software assets. But without full visibility, the vulnerability scans are merely good enough, and unable to account for areas managed by other teams. That false confidence is even worse in IT departments that have a rift between security and operations.

    If businesses fail to gain a view of the entire environment, it could take them two weeks longer to patch IT vulnerabilities (37 business days versus 27.8 business days for teams with a healthy relationship). By implementing an end-to-end view of the entire environment, both teams will be able to gain the visibility of the computing devices they need to protect organizational data.

    Reduce Complexity Between Teams

    More tools lead to a more complex environment. Tanium’s research showed that IT operations and security purchased an average of five new tools each within the last two years, and large organizations reported using as many as 40 to 50 point solutions. It’s no wonder why this happens: As new problems emerge, each team seeks a new solution based on that individual problem, ultimately creating an environment too difficult to manage. To keep an organization nimble and responsive, ITOps and security must work together to select solutions that are capable of solving the range of problems that both teams face, and agree on what data is most important.

    Create a Culture of Improved IT Hygiene

    As many as 80% of the organizations we spoke to said that maintaining IT hygiene was the most challenging task for IT operations and security teams. Once the entire department begins to prioritize the fundamentals, response times will improve and prevention and detection methods will sharpen.

    Conclusion

    Businesses that do not take these steps are vulnerable to disruption. It is essential that IT operations and security teams unite around a common set of actionable data and are empowered to ask questions about the state of every endpoint across the enterprise, retrieve data on their current and historical state, and execute change as necessary. These teams must come together from day one to maintain performance and security within their organizations — or continue to face the threat of cyberattacks, outages and other business-crippling disruptions.

  • COVID-19, the New Normal and the Indisputable Importance of Mobile App Security

    COVID-19, the New Normal and the Indisputable Importance of Mobile App Security

    As the United States emerges from COVID-19 lockdown, it’s not back to business as usual. COVID-19 remains a very serious risk, and until a vaccine or treatment arrives, we will all need to remain vigilant. Further, it’s also certain that the new normal post-COVID-19 world represents a fundamental transformation in how businesses operate, with mobile business models taking center stage.

    For most businesses, their storefront was their most important asset for awareness and revenue generation prior to the pandemic. Having a good physical location was critical to bringing in foot traffic and allowing customers to easily discover them. In the new normal, however, digital location has become far more important as consumers are increasingly turning to their mobile devices. So, it’s critical for businesses to make apps that are easy to find and use in order to continue generating revenue going forward.

    The combination of the pandemic and growing mobile usage has made developing and updating apps not just a nice-to-have marketing tool, but a necessary task for business survival. An enormous number of previously casual mobile users are now depending on mobile apps for their banking, shopping and other day-to-day transactions. As such, businesses need to redesign their apps to ensure they’re easy and intuitive to use so they don’t lose those potential customers. This requires developers to iterate even faster to deliver an engaging, glitch-free experience.

    Unfortunately, in the mad rush to ship apps as fast as possible, security often gets short shrift in favor of features and functionality. According to the Verizon Mobile Security Index 2020, even before the pandemic hit, 43% of app developers said they knew they were cutting corners on security to “get the job done.” 

    Features Trump Security … Until They Don’t

    Now with business models hinging on mobile, developers can no longer rest on “features first, security later” mentalities. The struggle here is that implementing mobile app security is hard to do. It takes time, often extending the development cycle, and it’s expensive. Even if development teams are committed to implementing security, they may lack the skills to do so — good iOS and Android security engineers are scarce and in high demand.

    Eventually, however, poor security will bring consequences. Cybercriminals operate much like nimble startups, searching for opportunities, creating minimal viable malware and then continually improving it to become more effective. Case in point: the EventBot malware for Android that was discovered in April. It masquerades as a legitimate app, such as a banking app or other popular consumer that, once installed, harvest unprotected data from other apps on a device. EventBot also can intercept text messages (SMS) sent to the device, which enables it to capture the identity verification codes used by multi-factor authentication solutions. With access to these codes and the unprotected user credentials found in the app, hackers can easily launch account takeover attacks on tens of thousands of unsuspecting mobile app users.

    What’s more, the new normal post-COVID-19 world is causing a huge increase in app usage, cybercriminals and hackers believe that the time is ripe to start exploiting known mobile app security flaws. For example, it’s not a secret that most mobile apps lack basic encryption. Similarly, most apps can be tampered with, repackaged and distributed on non-official app stores. With malware like EventBot that can be embedded in popular apps that users already trust, the game for mobile app exploits has been upped dramatically.

    EventBot is just one example of why it’s critical for app developers to encrypt all app data (including the strings, resources and in-app preferences that are stored on the device), obfuscate code and shield apps from tampering and reverse engineering efforts. Doing so will stop EventBot and other potential attacks, and prevent cybercriminals from using apps as Trojans for additional attacks.

    Solutions to the Security Development Challenge 

    If a development team decides the best route is to implement security themselves, they should first make sure they have the appropriate skills in house. If so, a good start is to address each of the OWASP Mobile Top Ten vulnerabilities. 

    Other development teams turn to security software development kits (SDKs), which they will integrate into their apps to provide security. This reduces the scope of the coding but still requires developers to have extensive security experience, and it’s critical to vet SDKs before integrating them, because rogue and vulnerable SDKs are a serious problem in the mobile app industry.

    A final option is security automation through artificial intelligence. It’s fast, taking just minutes to completely secure an app without any coding, and compared to manual coding, it’s inexpensive. But, as you should do anytime you’re outsourcing security, do your due diligence to make sure the platform truly secures the app without introducing additional vulnerabilities.

    The new normal has elevated the importance of mobile apps as the primary way customers interact with businesses, and cybercriminals are taking note. So, in the race to provide an engaging, intuitive experience for customers, don’t neglect their safety. Focusing on features and functionality at the expense of security might pay off in the short-term, but the long-term consequences could be grave. Identify the security development model that will work best for your team, but make sure you implement security quickly. Cybercriminals will not wait for you to prepare before launching new, even more devastating attacks.

  • Work from Home: Changing Enterprise Risk and Careers

    Work from Home: Changing Enterprise Risk and Careers

    In recent weeks, there have been a slew of organizations announcing that their work from home policies will be extended through the end of the year such as is the case with Google and Facebook, or perhaps indefinitely such as Twitter and Square.

    It’s good news to many technology workers who, according to a recent CNBC|SurveyMonkey survey, prefer remote work (25%). Also, a recent survey, produced by Cybersecurity Insiders on behalf of Pulse Secure, found that 38% of U.S. companies experienced gains in productivity. In this survey, 84% of respondents believe they will institute broader and permanent work from home policies beyond the novel coronavirus crisis.

    What does the work from home policies mean for organizations going forward? When it comes to security and compliance, it means quite a bit. According to the Cybersecurity Insiders survey, 69% of respondents are concerned about work from home (WFH) risks, especially due to low user awareness training, poorly secured home and public WiFi networks, use of personal devices and sensitive data leakage.

    A full 78% of respondents expressed their desire to enforce the same level of security controls for remote users as they do for on-premises users. While 65% allow access from personal, unmanaged devices, two-thirds of security professionals anticipate malware, phishing, unauthorized user and device access, and unpatched/at-risk systems to be the most exploitable WFH attack vectors.

    “Sixty-three percent expressed that remote work could impact compliance mandates that apply to their organization; especially GDPR, PCI-DSS, HIPAA and those with data breach notification,” the report found.

    Interestingly, about three-fourths of those organizations surveyed said they have more than 76% of their employees working from up — that’s up from 25% in 2019. Still, a third of those surveyed said their organization is ill-prepared or not prepared to support remote working. Yet, 75% of businesses transitioned to remote working within 15 days.

    “Surprisingly, less than a third expressed cost or budget problems, demonstrating the urgency to support their business. Additionally, more than half (54%) expressed that COVID-19 has accelerated migration of users’ workflows and applications to the cloud,” stated the report.

    How are survey respondents securing their staff who work from home? The survey found the most common to be endpoint security, firewalls, virtual private networks and multi-factor authentication.

    The 2020 Remote Work-From-Home Cybersecurity Report is based on a survey of 413 security decision makers, conducted in May of this year, within multiple industries, including financial services, healthcare, manufacturing, high-tech, government and education.

    Interestingly, the work from home movement may also give a boost to the gig economy, as gig economy work moves from lower-paying taskwork to professional gig work. A recent report, How the Gig Economy is Reshaping Tech Careers and IT Itself, highlighted data that shows 72% of all gig projects were in large enterprise and professional services firms throughout 2018 and 2019, compared with 52% two years prior.

    “This rapid growth is spurred by workers’ interest in flexible careers as well as businesses’ interest in convenience and efficiency. There are signs that the gig economy is finding many adherents overseas as well,” stated the report.

    Whether or not the work from home movement is real or long-term is no longer the question, it’s for how long and how far the trend goes. Enterprise technology leaders had soon prepare for a much more remote and loosely connected workforce.

  • DevOps Agility Shines in the Midst of a Pandemic

    DevOps Agility Shines in the Midst of a Pandemic

    As a career developer and now a chief technology officer, I am experiencing firsthand how COVID-19 has forced us all into new ways of working. I’m also aware that these new ways may be with us for a while. Last month Gartner announced that 74% of companies intend to shift some percentage of their workforce to permanent work from home status. 

    The fears many technology leaders have is that working from home will disrupt the processes in place for coworkers to communicate and collaborate. I would argue that DevOps overcomes those challenges by design. Organizations have become increasingly confident in DevOps with research from Global Market Insights finding “DevOps Market size exceeded $4 billion in 2019, and is poised to grow at over 20% CAGR between 2020 and 2026.” Companies that hold onto practices that are less agile will find they hamper velocity and allow competitors to vault ahead in a rapidly changing digital environment. 

    A study by the software developer CA Technologies ⁠— now part of Broadcom ⁠— found that more agile companies achieve 60% higher revenue and profit growth than their peers. In another study of agile companies, this one from industry research firm Gartner, 74% of respondents reported better alignment between IT and the business.

    DevOps and Agile go hand-in-hand toward greater organizational success.

    Software Developers Feel the Need for Speed

    Developers working remotely will thrive on the unimpeded workflows and synchronous collaboration DevOps makes possible, even while separated. Today, when customers are consuming more digital services than ever, the traditional development methods just don’t meet the speed required. In a recent xMatters survey of 300 consumers, 90% said they are using digital services — from grocery and takeout food delivery to videoconferencing and banking. Eighty two percent said they will continue to do so even after the pandemic is history. Customers previously accustomed to brick and mortar services now have high expectations for uptime, performance and feature sets for digital services, so leaders will have to embrace DevOps to continually improve the user experience.

    One Team One Dream

    Given the various specializations within organizations, embracing DevOps must often begin by bridging the unique cultures of each team, including development, quality assurance, security and customer success. One way to do that is to establish shared Service Level Indicators and Service Level Objectives with a focus on customer experience. For example, working toward five nines digital service availability, sub-second website page loads and same-day security patch deployments as common goals will aid in the formation of a cohesive unit. Additionally, the team should feel executive-level DevOps buy-in, which should manifest itself in optimal technologies and appropriate alignment of talent. 

    DevOps Developers Are Hot, Don’t Let Them Burn Out

    Developers with experience working in a DevOps organization have always been in demand, and the rapid adoption of digital services is making these software professionals even more valuable. According to a recent LinkedIn report, DevOps is the single most recruited position on the platform today. Attracting and retaining these skilled workers can be extremely challenging. 

    One way to increase retention is to foster a culture that respects work-life balance. When surveying consumers about the impact COVID-19 had on the adoption of digital services, xMatters simultaneously asked 300 IT professionals about the impact this mass-scale adoption was having on them. Unfortunately, 88% said their work-life balance had deteriorated. Most DevOps teams were already accustomed to being on-call 24/7; so if they’re feeling COVID-19 has pushed them over a line, burnout is a real risk. It’s essential to recognize this and act on it. Providing DevOps teams with the right tools to automate CI/CD in a secure way, even while working remotely, goes a long way. 

    Time for DevOps to Shine

    The changes driven by the pandemic will have long-lasting effects on the frequency with which we use digital services to live and work. Customer experience will remain paramount and those metrics will be increasingly visible at the executive level. We will also see a greater focus on lean practices and cost reduction. I can think of no approach that does more to meet consumer expectations, address fiscal challenges and increase employee satisfaction than DevOps does. 

  • Working with SAFe and Microservices: Learnings from Developers

    Working with SAFe and Microservices: Learnings from Developers

    As developers, the prospect of working for a big company might bring about feelings of oppression, rather than opportunity. Envisaging endless team syncs, pointless meetings and processes wrapped up in bureaucracy inside a set of procedures. It’s easy to imagine why some are put off. For many though, the fear comes from the thought of being lost in a corporate structure where input is not valued, and skills are wasted.

    But every day, as developer concepts become further rooted into corporate behaviors, the line between the two worlds continues to blur. Products are no longer dreamed up in product silos, but from agile teams made up of a diverse cross section of a company. Marketing has dropped drip campaigns in favor of A/B testing, rapid iterations of messaging and data-driven analytics. Big companies no longer mean old school thinking, but fast-changing, inclusive places to really make an impact and be heard. 

    Working within the Scaled Agile Framework (SAFe) with an agile architecture of microservices helps us to do our jobs, but the learnings we’d like to share in this article are universal. An organization may not require the SAFe methodology, but the experiences and methods of working can be applied to many roles and are based on three fundamental questions every developer should ask themselves. 

    How Do I Plan My Day? 

    As with any role, a good start for us is knowing that the previous day went well; that the code we wrote meets the standards required for deployment. Before that, our individual microservices teams will meet to discuss immediate priorities. We let one another know what’s top of mind for us, and any issues we might be facing — and we resolve them together before a midday Scrum meeting.

    The Scrum meeting involves the Scrum master, product owner and the developer team and gives us a chance to give feedback and dive into the wider challenges or blockers we’re facing with our own tasks. We might be thought of as solitary creatures, but we actually tend to solve problems together. So, while we have ownership of our own tasks, problem solving comes from collaboration.  

    Whether working within the agile framework or not, communication is a huge part of our lives. Our advice to developers everywhere is to be vocal about the need to engage within their organizations. And to business IT decision makers, we know that not every firm has the deep pockets to fund a dedicated DevOps team to implement new tools, change culture or break down silos, but there are many communications and open source DevOps tools that boost collaboration and improve workflows — most are well-known to developers. So, give them the chance to explore how they might bring efficiencies to their work. Help them help the business and maybe suggest trialing some new tools. 

    How Do I Upskill on the Job?

    Developers are problem solvers. We love the opportunity to help each other overcome challenges. Peer-to-peer communication doesn’t just allow us to get back on course quicker, it lets different teams share knowledge and pitch in to solve problems. We don’t mind being transparent with our peers when we face an issue – in fact, we quite like it, as the offshoot of working together often leads to new skills and technical knowledge. 

    Learning the interactions between each microservice, for example, helps us map out the architecture and understand how our own work fits into the bigger picture. The more we talk, the more we see where bottlenecks might occur — and the better equipped we are to achieve larger objectives. As we have complete ownership of our services, from initial coding to deployment, it is our duty to ensure our services perform as they should in production. 

    This ownership is something all developers should aim for. Even when working in a more rigid waterfall approach, opportunities to collaborate should be seized and encouraged — even if the only payoff is personal development. Implementing a system of peer code reviews, for example, not only delivers more robust releases, it fosters a collaborative mindset.

    Do I Need to Be in this Meeting?

    Working with SAFe methodology allows the job to be broken down into iterations linked to business objectives. The most significant of these is determined by meetings that occur every four months, where goals are set and roadmaps established to achieve them. Engineering teams then divide up the features that will be passed on to the developer teams, who break them down into two-week sprints. 

    The sprints are what the developer teams work to, under direction from the Scrum masters and product owners. Breaking iterations into smaller sprints ensures we have defined goals, which keep meetings and interactions on track (i.e., daily Scrum meetings and bi-weekly sprint meetings). Without this focus, there’s a risk of derailing the prep required to focus on writing and reviewing code. If we need a discussion about certain features, we make sure to identify exactly who needs to be in that meeting. Above all, we’re all about optimizing our time together. The longer we spend away from our desks, the less time we have to perform our core roles. 

    Whatever your part in the software development lifecycle, never be afraid of asking the question, “Do I need to be here?” Your energies may be best used elsewhere.

    As you can see, these three questions are critical to developers but can be applied to just about any role in just about any organization. Planning, learning and focusing – seems we’re not so different after all.

     

    Tomasz Rumpca

     

    This article was co-authored by Tomasz Rumpca, Java developer and team lead at Finastra. Tomasz works on FusionFabric.cloud, Finastra’s open development platform solution. He is passionate about Java-related technologies and building user-friendly software. Outside of work, he enjoys spending time outdoors with his friends and family.

  • Who’s Responsible for Security? Apparently, It Depends

    Who’s Responsible for Security? Apparently, It Depends

    More than 10 years after organizations began implementing DevOps, responsibility for security still resembles the proverbial chicken and egg dilemma.

    GitLab’s 2020 Global DevSecOps Survey asked developers, security team members, operations pros and testers about sole responsibility for security in their organizations.

    About 28% of developers, 33% of security teams, 21% of ops pros and 23% of testers said responsibility for security rested only on their shoulders. At the same time, 29% of security teams said everyone was responsible, nearly as many as said they had sole ownership.

    Confused yet? So were many of our survey respondents, who had a lot to say about the fluid – and frustrating – nature of DevSecOps.

    “The team is trusted to do its own security research and implementation. We don’t know how good or bad we are.”

    “I am the only one who actually cares about security in my organization.”

    “I regularly put security suggestions in the box of suggestions, only to be ignored.’”

    “There’s a security team, but it doesn’t involve face to face with us, the dev team. So we just run the dev process without counting on them.”

    The Blame Game

    There’s a long history of developers and security pros not seeing eye to eye. In GitLab’s 2019 Developer Survey security pros were very expressive on the subject of developers simply not doing enough to enable security. Developers were equally unhappy, citing security’s “heavy-handed approach.”

    This year, we drilled down further to see if we could understand why dev and sec continue to see the world differently.

    Differences between the teams quickly became apparent. According to the survey findings,  65% of security team members told us their organizations have shifted security left. But the devil is in the details, and the details do not really support a shift left.

    A solid majority of developers are not running SAST, DAST or container scans, and only about half conduct compliance scans. Even if the scans are run, less than 19% put SAST results into a pipeline report a developer can access. Dynamic application security testing (DAST) fares even worse – less than 14% of companies gave developers access to those reports.

    So, developers don’t have easy access to critical data. On the other hand, security pros are frustrated that developers continue to either miss bugs altogether or find them too late in the process. Over half of security respondents (61%) agreed at some level that vulnerabilities were mostly found by security pros (not developers) after code is merged in a test environment (which is relatively late in the process). In other words, when asked how developers find bugs versus security teams, 93% gave developers credit for discovering only 25% or less of the bugs to be found in existing code, leaving three-quarters of the bugs for security to find at a later stage in the process.

    And as if that wasn’t sufficiently frustrating, 69% of security team members complained it was difficult to get developers to remediate bugs, even if their organizations included security as a developer performance metric.

    How DevSecOps Can Work

    Clearly, there is work to be done to get developers and security on the same page, but we are seeing a few glimmers of hope. Security pros are not quite the lone wolves they once were; many told us that DevSecOps has brought a welcome change to their responsibilities. Nearly 28% reported being part of a cross-functional team focused on security and almost the same number (27%) said they were more hands-on and involved in the day-to-day development activities. Almost 23% said they were now focused more on compliance and about 20% said they did not see any changes in their roles.

    In perhaps the most significant (and promising) finding, GitLab asked what skills would be most important to a security professional’s future, the majority (almost 28%) said soft skills like communication and collaboration. Interestingly enough, a majority of their developer counterparts agreed with that.

    So, while no one agrees just yet on who owns security or even how to prioritize security, it’s encouraging that both developers and security pros realize they need to prioritize communication and collaboration.

    At least one respondent reports success in figuring it all out:

    “We don’t have separate security, developers and operations; we are DevSecOps (and more).”

  • 6 Virtual DevOps Conferences You Can’t Afford to Miss in June 2020

    6 Virtual DevOps Conferences You Can’t Afford to Miss in June 2020

    Conferences and events make up to a trillion-dollar industry and have been playing a major role in connecting people from different parts of the world and exchange ideas. Because of the COVID-19 outbreak, the first major tech conference that got canceled due to health and safety concerns was the Mobile World Congress (MWC), the annual gathering of electronics makers.

    Along the way, similarly, Facebook also canceled all physical conferences and events through June 2021, including the major F8 Developer Conference and the most awaited Oculus Connect 7 virtual reality event that was supposed to be held in San Jose, CA.

    Even Microsoft, the giant, has announced all of its events are going digital-only until July 2021, including its flagship Microsoft Build and the prestigious Microsoft Ignite 2020.

    At the beginning of April, more than 30,000 people were expected to attend the prestigious Google Cloud Next ’20 conference, all set to happen in San Francisco. But, as the coronavirus crisis intensified all over the world, keeping the attendees’ and employees’ safety in mind, Google decided to move the entire event online.

    Today, we will see six virtual DevOps conferences you can’t afford to miss in June.

    TechStrong Con

    Date: June 4

    Cost: Free

    TechStrong Con is a virtual summit dedicated to and celebrating all things tech. The event, hosted by MediaOps, brings together some of the most prestigious industry leaders for 12 hours of immersive learning and networking. The sessions are divided into three tracks: Emerging Technologies, Security/DevSecOps and Digital Transformation. Attendees will have access to downloadable resources and will have the chance to interact with tech leaders and fellow DevOps practitioners.

    You can also be a part of the #TechStrongCon Challenge, which consists in sharing a photo of your work-from-home space during COVID-19 on LinkedIn for a chance to win either an iPad Pro or a DJI Maxic Drone.

    A portion of the proceeds raised from the event will be donated to charities dedicated to fighting COVID-19. For more information on the event and the challenge visit the TechStrong Con website.

    Agile + DevOps

    Date: June 8–11

    Free Pass: $0

    Conference Pass: $499

    All-Access Pass: $999

    The theme of the event is “accelerating software delivery with the power of Agile and DevOps.” This is an event by TechWell, and this time it is happening fully virtual. From the comfort of your own digital device, sitting at your home, or wherever you are, you will have access to all of the great content and experts the Agile + DevOps conference is known for. This time, the event will be streaming over 90+ talks—including five keynotes, 25 tutorials, more than 50 sessions and 14+ Industry Technical Presentations. All this is happening over an engaging and interactive premium virtual atmosphere. You can select the conference package that fits your needs and your budget.

    DevSecCon 24 

    Date: June 15 -16

    Cost: Free

    This virtual conference focuses mainly on the security aspect in development and operations and tackles the impact of development operations and security “run by practitioners, for practitioners.” 

    The aim here is to show attendees how DevOps and security can work together seamlessly to make continuously secure development a reality.

    This virtual expo allows for interaction with different vendors and companies. Check their website for updated details.

    swampUP

    Date: June 23-24

    Cost: $20 (all goes to charity)

    swampUP is JFrog’s annual DevOps conference, and this time it is happening in a virtual format with two full days of action-packed DevOps talks and training. The conference has a remarkable set of visionary keynotes and thought‑provoking DevOps sessions delivered by industry experts. 

    Leap into DevOps, DevSecOps and cloud-native best practices with practical training by experts delivered virtually. Sessions are experimented and thoroughly designed for developers, administrators and managers. This is regarded as one of the industry-recognized conferences of all time.

    DevOps Enterprise Summit London

    Date: June 23-25

    Cost: $240 – $480

    Gene Kim’s IT Revolution hosts this event. DevOps Enterprise Summit has great speakers and exciting courses provided by experts. It is a place for exchanging DevOps success stories and best practices. 

    Some of the big brands such as Adidas, Walmart, John Deere, Capital One and many others are participating. Attendees will get three days of immersive learning and interaction with fellow technology leaders.

    Cloud Foundry Summit

    June 24-25

    Attendee Registration: $50

    Academic Registration: $35

    Cloud Foundry Summit is where developers, architects, operators, CIOs and other IT professionals meet to share the best software and IT practices and innovate together. Simplifying developer experience is the theme of the conference where both days are filled with interesting sessions and hands-on labs. 

    This is where you will learn how to automate, scale, and manage cloud apps throughout their lifecycle. 

    It looks like virtual is the new normal for the events industry and for the companies looking to host future events. The upsides of the virtual format of the conferences are many: It is easy to attend, saves a lot of money we used to spend on travel, stay, food, etc. and eliminates the effort and fatigue that used to happen while attending a physical conference happening in some other city or country. Well, thinking positively about any situation makes you feel good, and I hope we will get out of this COVID pandemic as soon as possible.