devopsy.kinsta.cloud

Tag: developers

  • Motorola Solutions: Driving a Thriving Security Culture

    Motorola Solutions: Driving a Thriving Security Culture

    It’s crunch time in the cybersecurity industry. For too long, many companies have remained unmoved by the increasing threat of cyberattacks, despite increased digitization of their products and services. Customer data is the new gold, and some organizations are leaving the door to their vault wide open.

    In saying that, secure development is complex and not without its challenges, especially at scale. In my experience, it is an uphill battle to win over developers on secure coding and best practices. In the mind of a busy programmer working to achieve strict delivery deadlines, security is not a priority over feature development and function—it is instead seen as a tedious task that interrupts their creative flow. However, if we are going to ready ourselves in the battle against those who seek to do harm, this culture needs to change.

    Marilyn Barrios is the senior cybersecurity training manager at Motorola Solutions, running the security training program for its team of more than 6,000 developers across the globe. Her goal is to ensure that those on the front lines of the company’s extensive software development are equipped with the knowledge, tools and ongoing training required to combat the growing global cybersecurity threat.

    To accomplish this, Barrios created an impressive internal security culture, one that thrived not only from a core skills perspective, but also in understanding its paramount importance in overall software quality. Her people-first, positive approach engaged the development team, created excitement about security and morphed into something far more powerful than a simple compliance exercise.

    “Ensuring that our products are secure is our highest priority. That’s why we’re working to create a culture of security-first thinking across the company—so people not only understand cybersecurity and why it is vital to maintaining a high standard of software quality, but are also excited to learn more,” she said.

    With such a large development team covering multiple facets of the business, insight into each individual’s security knowledge and current skill level could be elusive and difficult to collate. Barrios sought to streamline this process, working toward a holistic solution that would deliver key metrics and relevant training in the languages and frameworks that were actively being used in the business while remaining engaging enough to be revisited—even for more senior engineers.

    Marilyn and her team worked to implement an immersive, engaging training experience for their developers. Starting with a boot camp run by security superstar Jim Manico, the developers learned offensive coding techniques before playing in tournaments to test their defensive skills against the attacks they had just seen in action. This setup proved effective and eye-opening for the participants.

    “In really diving deep into how cyberattacks can be executed, the team saw how easy it was to do a lot of damage at the application level,” Barrios noted. “By then practicing how they can defend against these attacks, developers’ eyes were opened to how they can help if they keep security a priority in their work. They enjoyed the experience and it was also beneficial for them.”

    I was proud to see how well she and her team at Motorola Solutions executed a comprehensive, engaging and fun security training program that not only lifted security awareness IQ overall, but also helped to identify a new group of champions to keep the critical message of cybersecurity best practices thriving long-term within the organization.

    It was also interesting to learn that the eventual winner of the tournament did not start the program as the most experienced and security-aware developer. The boot camp was instrumental in rapidly upskilling the individual, and the gamified aspect of the training ensured a high level of engagement and information retention.

    “Our eventual tournament winner was so excited with the boot camp, and he was so engaged with the training tool. He practiced so much in a two-month period, improving so significantly, that he ended up winning the tournament,” Barrios said. “From there, he recruited even more champions, piqued their interest in security and helped them along to become advocates in their respective groups.”

    Barrios’ broader goal of creating a strong buzz that encourages an organic security culture to grow within the company is certainly on track.

    Gamified training, team events driven by tournament initiatives and the incentive to keep engaging with AppSec have resulted in something very positive: Developers not only are working to have a better understanding of security, but also actively seek to uphold company best practice initiatives day to day.

    Motorola Solutions saw measurable improvement when using tools and training compatible with the creative, problem-solving mindset of many developers, enjoying a training participation rate of more than 90%, with security accuracy increasing 24% across the global tournament that followed. Its internal security champion program has also seen immense support, growing by more than 1000% in the last 18 months. The company currently boasts 173 champions across its various product lines and will double that again over the next year. It has set a goal of at least one champion per scrum team—an initiative that holds incredible value in continuing momentum and spreading positive security influence across the organization.

    Driving a positive security culture takes time, planning and dedication, but alongside the right tools and training, Barrios’ advice is a sound reminder that clear goals and communication are powerful in achieving widespread support and change: “Always tie objectives to the ‘why.’ You should know why you’re trying to meet a goal or influence change; don’t just give a direction with no context.

    “For us, it’s easy: we make it personal. Motorola Solutions is responsible for delivering key communications over mission-critical infrastructure and devices for public safety and commercial enterprises. First responders, citizens and front-line workers alike are relying on this technology to be as secure as possible, so we emphasize the importance of learning best practices,” she said.

    With every other day seemingly bringing bad news about the latest large-scale data breach, it is refreshing to see an organization with a highly successful security program—one that can only get stronger as its developers continue to train and become the security superheroes we need to protect our digital world.

    — Pieter Danhieux

  • The Terrain of DevOps is Strewn with Pitfalls

    The Terrain of DevOps is Strewn with Pitfalls

    As Gene Kim, one of the leading thinkers in DevOps, once said, “DevOps is not about what you do, but what your outcomes are.” What he’s telling us is that DevOps is about enabling a rapid flow of work that transitions from development to testing to operations, but the bottom line is that it’s about achieving results. Unfortunately, this too often gets lost in modern-day DevOps practices.

    In this article, I will discuss five common pitfalls that occur in DevOps if you don’t pay attention to the endgame and how your organization can avoid falling victim to them.

    DevOps and Automation: Measuring the Wrong Outcomes

    Some people believe that, at its core, DevOps is about trying to automate everything. But ask yourself this: Once you automate, are you really delivering a better outcome?

    The answer is not always yes. While metrics such as deployment frequency or mean time to repair (MTTR) are interesting DevOps indicators, they are no more interesting to determining if your team is delivering actual value than measuring the number of lines of code submitted or counting the number of keystrokes by the development team. You measure outcomes by determining a baseline from where you start and compare that with where you end.

    We need to understand that DevOps is about much more than automation; it’s about the entire pipeline and how your team moves from ideation to delivery to production. Even large companies with world-class DevOps teams don’t always clearly see the problem and can struggle managing the value stream and putting together multiple pipelines. An anonymous but real-life example of this is an organization I know that had been doing DevOps for 18 months, yet hadn’t delivered anything into production in that span. Are they really doing DevOps? DevOps is a process, but if it produces zero value, it’s not delivering on its promise.

    The key is focusing on delivering value and measuring value delivery into production. However, before you can begin measuring value, you have to define what it means to each individual deliverable. Common metrics include the number of story points, actual revenue from product comparison and customer satisfaction. With your clearly defined metrics in place, you can measure value as it gets delivered to the customer.

    DevOps and Fragile Environments

    One Achilles’ heel in the DevOps process is the pre-production environments where code gets deployed and tested. Automating a delivery pipeline relies completely on code being built and deployed to various environments. Fragile environments mean that the developers and testers are wasting time dealing with problems originating from the environment and not the code itself.

    While we wish all environments could be on-demand; the fact is, most are not. Another DevOps expert, Randy Bias, has an analogy about pets versus cattle in describing servers, and the same analogy can be used for environments. If environments are not standardized and repeatable, you have to be willing to move on from it like a farmer moves on from livestock; you can’t hold onto sentimental attachments like we have with our pets. What’s most important is that in no case can an environment be singular in nature.

    One element of the solution is to create code and automate, but the key is building up environments that are complete. Every environment needs proper builds, proper data and proper tests validating the environment. Additionally, the automation must have the stability to perform successfully every time. If you have piece of automation that fails even just 5% of the time, that’s unacceptable.

    The only way automation works in an environment is if you can trust the environment. When the environment is unstable, it’s like playing Russian roulette: No one knows exactly where the danger lies. It could be in the environment, the code, the data, the middleware … a number of places. When a problem arises, developers are often the last line of defense, but dealing with an issue such as this pulls them away from getting real work done.

    Disconnected Teams

    On this point, I’d like to share a warning: Disconnected toolchains lead to disconnected teams. The planning, development and testing teams can lack cohesion, and the release and operations teams often struggle to be on the same page. Each of these groups have their own tools and management, but they need to be able to communicate with each other effectively to make things work smoothly. In an ideal world, planning initiatives would flow into features for the development and testing team, which would flow into release pipelines and operational changes. Every team still can speak its own language, but the tools need to be interconnected and unified across the teams.

    Mismanaging Hybrid

    The term “hybrid” has many different uses in the software development space. Hybrid methodology refers to combining waterfall, agile and DevOps practices. Hybrid environments means your environment is housed in multiple locations such as the cloud, on-premises, virtual or code. There’s also hybrid geography, hybrid architecture, hybrid style—the list goes on.

    The key to transitioning to DevOps is properly managing the different types of hybrid. If you can’t manage hybrid delivery, you can’t manage your entire delivery and you can’t improve your delivery holistically. Organizations must learn to manage in a world of hybrid delivery and be able to handle cloud and on-prem, as well as teams all over the planet.

    Fixing Non-Constraints

    The Theory of Constraints is about pinpointing the bottlenecks in your process and fixing them. Any work that’s not focused on eliminating the constraint will not result in improvement and could be considered a waste of time.

    It’s important to remember that if you haven’t fixed the bottleneck, you haven’t improved anything. At the same time, if you’re automating the non-constraints, you’re wasting efforts by trying to improve what doesn’t need improving.

    As we’ve pointed out, DevOps does not equal automation. If an organization has messy processes and tries to automate them, they’ll be left with an automated mess. Therefore, organizations will see the best results from automating their constraints and just as important, not automating the non-constraints.

    — Jeffrey Keyes

  • 5 Guaranteed Ways to Kill DevOps Developer Productivity

    5 Guaranteed Ways to Kill DevOps Developer Productivity

    “A developer is an organism that turns coffee into code.” I still laugh when I see that quote as it reminds me of my hardcore developer days, when my cube always seemed to be directly next to the coffee machine and caffeine was management’s way of ensuring we had the energy to develop well into the wee hours of the evening.

    What is developer happiness? I like to believe it hasn’t changed dramatically over the years. It’s about giving developers the right tools and the freedom to do what they do best—produce meaningful code. That means reducing distractions so they can meet or beat expectations and timelines, ultimately driving revenue for the organization.

    I trust your company is not in the practice of molding reusable human coffee filters. But are you doing everything you can to help your developers be as satisfied and productive as possible, or are you taking the “necessary” steps to ensure they are buried in context-switching hell?

    If the latter is your aim, read on to learn about five guaranteed ways you can totally kill developer productivity.

    Saddling Developers With ‘Plumbing’ Work

    Companies frequently look at developers primarily as technical resources instead of true innovators, so they get saddled with plumbing work. In DevOps and continuous delivery (CD), that’s writing a lot of ad-hoc scripts to string together pipelines, define infrastructure and manually create deployment plans. If your company is on the road to cloud adoption, it’s imperative to get unnecessary scripting under control because things only get more complicated as you start to incorporate the many different cloud platforms and services that are available.

    Making Developers Deal With Security After the Fact

    A fail-safe way to kill developer productivity is to make them deal with security after a release has left development. Too often, they first build code, QA then tests it and finally someone from security checks it to make sure there are no holes well after the code has been written. If security problems are found after coding is done, the release is halted and must go back to the developer to fix. This often occurs either just before the production release or, worst case, just after. In either case, not only does it take longer to resolve the problem, it also prevents the developer from moving on to the next big thing.

    Expecting Them to Chase Down Features and Status Requests

    Because development pipelines are often not integrated with the higher-level CD pipeline, those outside of development have no way of seeing the status of features, deployments and releases. Understandably, their only option is to ask developers to provide status information or call a status meeting which, of course, are additional interruptions that divert them from feature development. Developers don’t like it, and it doesn’t exactly help anyone else in the pipeline be more productive, either.

    Bogging Developers Down With GUIs

    GUIs are a great democratizer in large organizations. They offer a user-friendly way for people across the company, regardless of technical know-how, to access the information they need to be productive. But many developers see them as a waste of time. And while even the most GUI-resistant developer needs them every so often, they are not their preferred way to work.

    Taking Away Their Favorite Tools

    Standardizing your software delivery process is a must to increase efficiency, but standardizing on tools is not. Taking away their favorite tools is highly recommended only if you’re keen on decreasing developer satisfaction.

    What are the Alternatives?

    Managers and leaders can help developers by taking as much of these mind-numbing tasks off their plates as possible. They can do that by automating the release process and integrating CI pipelines into the CD pipeline. Doing so allows everyone to plug in to what’s happening in development without having to interrupt developers, and they can continue to use their beloved tools and simply connect them into the release pipelines.

    It’s also important to standardize most of your operations work upfront—infrastructure, provisioning, compliance, security. All this advance work will allow developers to consume environments on-demand and just deploy without extensive scripting or re-scripting for changes and maintenance.

    Keep in mind, if you shift security left, closer to the development process, you need to automate it. Otherwise, it becomes someone’s manual task—a developer, DevOps engineer or security person—and that will slow down the delivery process. For example, SAST test and SCA scans can be automatically run on every check-in. DAST tests can be automated to run after each build. This way, any security holes are caught as early as possible, while the code is still fresh in the developer’s head.

    Finally, reduce the amount of work developers need to do through GUIs. Give them a way to kick off releases from their respective CI pipelines and the ability to define release pipelines—infrastructure, configuration, security and so on—in code.

    Coffee Machine or Barista?

    Doing these five things—relieving developers of unnecessary scripting, standardizing compliance requirements and security checks upfront, reducing the need for developer-provided status updates, enabling them to work in code and allowing them to continue to use their favorite tools—will make the difference in whether your developers feel like the office coffee machine or a master barista.

    — Dan Beauregard

  • SREs: The Happiest – and Highest Paid – in the Industry

    SREs: The Happiest – and Highest Paid – in the Industry

    According to the 2019 StackOverflow survey completed by 90,000 developers around the world, whether you are already a Site Reliability Engineer (SRE) or thinking about becoming one, looks like you are onto something.

    SREs, also called DevOps specialists, are a pretty unique type of talent; one that has knowledge in both software development and system infrastructure. And because the world of infrastructure is so vast, these professionals also need to juggle networking, security, system administration, hardware and anything else that could make an infrastructure unstable or down (yes, I am looking at you, A/C). That makes any day at work unique.

    SREs, for the most part, are in charge of making sure that your favorite website apps are loading, and fast. Their work is not customer-facing but highly critical. According to Gartner, the average cost of IT downtime is going anywhere from $5,600 per minute to—when you work for Amazon—$2 million for every minute down.

    That’s one of the reasons why SREs are among the highest paid in the industry, well, right behind their fellow managers! They also rank among the ones with the most coding experience—it takes time and hard work to get there.

    And all of this leads to happiness! With an interesting job and high pay, SREs satisfaction is among the highest in the industry, and they rank in the top three of the ones not actively looking for a job. SRE for a day, SRE forever!

    But here’s the problem: There aren’t a lot of SREs out there and hardly any computer science programs cover the topic. A recent tweet from Target software engineer Jessica Schalz illustrates the point very well:

    As TechRepublic reported, these professionals are among the most wanted in the tech industry and 33% of IT leaders report having a hard time hiring profiles with these skills. A potential reason for this lack of talent might come from the fact that the profession is failing at attracting about half of our population: women. SREs are 30 times more likely to be men than women. Training non-bearded SRE talent is possible. The Holberton School, a coding school I co-founded where 40% of the students are women, is leading a lot of students to be hired as SREs.

    And the good news is that we are not alone: CloudFoundry and Infrastructure Masons are also taking action to move the needle. And industry leaders such as Tammy Bütow and Abby Kearns are showing the way.

    As former software architect Eduards Sizovs pegged it: Great developers are raised, not hired. The industry is spending tons of money and energy and trying to attract the best talent when it would often be more efficient to take juniors that can grow to their need.

    “There is a new generation of developers of all races, genders, backgrounds coming up who can do these jobs,” said Max Johnson, DevOps engineer at Pypestream. “Businesses should widen their hiring scope and consider non-traditional sources that train as good, if not better, talent and coach them further for these highly skilled jobs.”

    LinkedIn is among the first to understand the value of investing in people—so it’s probably not a coincidence that it’s among the best places to work in the U.S. From an internal, employee-led perspective, the company has developed a number of in-house programs for both career and technical development. For example, its Women in Tech (WIT) organization leads a number of programs to connect, inspire and grow women technologists. From an external standpoint, with its REACH engineering apprenticeship program, LinkedIn is redefining the way it identifies, recruits and trains talent. REACH is an apprenticeship program that creates opportunity for every individual with the passion and potential to either develop or restart their career in engineering. The program guides participants through various levels of technical roles at the company, with the end goal being that each individual builds their skill set and gains the experience needed to become an engineer.

    “Reinventing our approach to recruiting and developing junior talent has been a great way to expand our funnel and has brought forward more diverse perspectives, forming a more robust team,” said Casey Brown, senior manager, SRE at LinkedIn and core team member of the REACH program.

    As you have probably understood, SREs are a niche talent (43% of them even picked Vim as their favorite editor). But as I recently tweeted, they are ruling the world, and more of them are needed. Let’s get creative to train and hire more of these amazing professionals!

    — Sylvain Kalache

  • Different Organizations, Different DevOps Outcomes

    Different Organizations, Different DevOps Outcomes

    The main motivation behind inventing DevOps platform was to help close collaboration between developers and IT operations. Basically, DevOps emerged as a great platform to bring closer together developers and beneficiaries of the app development process. DevOps initiates a cross-disciplinary practice spanning across development and operations.

    The ultimate benefit of the DevOps approach is removing the barrier between development and deployment of software applications in specific business processes. Regardless, not all businesses reap the benefits of DevOps platform.

    Does DevOps really suit all businesses of different sizes and niches? What are the key considerations for utilizing DevOps platform? These are the questions we will try to answer through this article.

    Do All Businesses Require DevOps?

    The common and widespread consensus is that any software development company geared for innovation must embrace a DevOps environment. Any business that considers innovation and smooth deployment in the software development process—a key factor in their long-term growth strategy—should take advantage of the benefits of a DevOps platform. Whenever any service provider needs to adopt new strategies to keep pace with the evolution in the software space, DevOps will come as an irreplaceable platform choice.

    Despite this consensus and widely accepted perception, there are different opinions in the market. Many industry experts believe that to reap the benefit of the platform you need to have a dedicated DevOps team in place. If you have a DevOps culture and in-house DevOps team in your company, you can gain a competitive advantage.

    The Key Benefits of DevOps

    The main benefit of DevOps is faster delivery of software with much-improved quality. There can be several other benefits depending on the industry.

    While some companies refer to the huge reduction in downtime since they adopted DevOps culture, there are still many others who simply give credit to the platform because of its integrated approach that makes the process more agile and fast-paced.

    For most companies, the domino effect of getting better software at a faster speed ends up delivering sustainable growth and revenue opportunities.

    Here’s a look at the role of DevOps platform across three types of businesses: small companies and startups, midsize companies and large business houses.

    Small Companies and Startups

    In smaller companies and startups where resources and human capital remain under-supplied, the responsibilities ascribed to developers, engineers and deployment professionals often tend to get blurred or overlap. Because of the scarcity of human resource, developers and engineers are often assigned multiple responsibilities. Naturally, in such companies, it is common to see cross-functional teams ready to engage into various development projects with ease. This makes them ideal business organizations to embrace and grow with DevOps culture.

    Midsize Companies

    As the companies tend to grow bigger in size and resources, they have a bigger (and often unbreachable) divide between verticals such as operations and development. In such organizations, staff are less likely to be open to cross-functional responsibilities, as many have been in the same job doing the same tasks and feel settled. This brings in a stagnant organizational process, where strong departmental divide rules the business process outcome.

    This stagnant work culture makes such companies less appropriate candidates to implement DevOps environment. For these companies to reap the benefits of a DevOps platform, mass organizational changes should be brought in the team structure. Building a separate cross-functional DevOps team to handle some focus projects can also be good practice for them.

    Large Companies

    Large companies enjoy the luxury and abundance of resources, and this makes them much better-placed compared to other organizations. Companies such as Amazon, Facebook, Google and Microsoft have the diversity, huge experience and robust abilities to bring together cross-functional specialists from development and operations to work on ambitious projects. These organizations are known for having product-oriented units, comprising specialists from both development and operations.

    Apart from their cross-functional expertise, product-focused approach and abundance of resources to roll on new projects, large companies also can make a big difference to the teamwork and motivation through a highly unified vision and strategic long-term objectives shared by every member of each team. This is why large companies always stand as suitable candidates to embrace DevOps approach and environment for their projects.

    Fixing the Right DevOps Strategy: 3 Things to Consider

    Beyond the organizational differences and core strengths and weakness for embracing a cross-functional DevOps approach, we must look into the key aspects that make a right strategy for any organization to incorporate DevOps into their scheme of things. Question is, despite the shortcomings and lacking, how can you embrace DevOps environment and reap the benefits? Here we provide some clues:

    • Making Change a Habit. Some strategists believe that any organizational change will face a lot of friction, causing substantial harm to the immediate business outcome. But there should be no reluctance to change for this. Rather, by bringing constant changes, people get used to the friction and pain and it becomes normal. This is one way to replace traditional IT mindset with DevOps.
    • Starting Small with a Neat Team. Obviously, finding the appropriate and credible skilled employee for your DevOps projects is not always easy. This is why it is advisable to create small startups or units, in which sharing the common vision and embracing a cross-functional approach becomes the order of the day. On top of that, do your best to bring out the best from your team and hire some experienced ones with knowledge of DevOps.
    • Continuous Development Mindset. We all know how the DevOps platform always focuses on continuous development approach. It is easier for the software developers to embrace such approach, but for operations staff, you have to slowly make them think of infrastructure as evolving and slowly building components. That’s something challenging but not impossible.

    Conclusion

    DevOps has emerged as the most promising development approach for modern software developers. Though for many development companies the friction emanating from strict role divides is becoming an obstacle, the positive push by DevOps for cross-functional approach looks indomitable.

    — Atman Rathod

  • Dev and Ops: Not from Different Planets

    Dev and Ops: Not from Different Planets

    At a conference, I heard a speaker remark that “Dev people are from Mars while Ops people are from Venus.” That’s catchy and captures what a fair number of managers believe instinctively. But is it really true? I’m not convinced.

    We all know that DevOps enables us to deliver software faster, with fewer bugs and much less downtime than traditional approaches. But DevOps is new, complex and often challenging for teams to embrace. Developers often guard their tools and operations shake their head each time they hear about some new asset bundling package they have to support. I think the first few meetings of Dev and Ops probably do a lot to build the notion that they are from different planets.

    In my experience, however, the opposite is true. To borrow a different popular catchphrase, they are more “brothers (or sisters) from a different mother.” When you examine the makeup of Dev and Ops people, you find more similarities than differences. Here are some examples of their common ground:

    • Consistency and Standards. Both Dev and Ops are technical endeavors that place a huge premium on things being “precisely” correct. Whether coding a service or setting up an AWS instance, “in the ballpark” doesn’t cut it. For this reason, both camps try to establish standards for how they work. Whether keeping Dev teams all using the same environment or Ops trying to keep Dev, testing and products all running the same, both need to benefit from building consistent environments.
    • Coding Skills. Whether coding or scripting, Devs and modern Ops teams need to be comfortable in a variety of highly technical tools. Build scripts, deployment, automated testing and reporting all require some coding skill.
    • Common Tools. If you look at the DevOps ecosystem, you’ll increasingly see tools that are intended for both Dev and Ops tasks. Dev people, for example, use Git for reusable code; Ops uses Git as well for configuration of things such as Docker. Also, Dev uses Jira to track bugs while Ops uses Jira to track tasks.
    • Shared Metrics. While their focus may be different (code versus pipeline), both Dev and Ops share many metrics of success—consistent delivery, fewer errors, responsiveness to customers and uptime, to name a few.
    • Test-Driven. Dev and Ops both embrace the “fail fast” mantra. They want to know if a change will break anything as soon as possible, long before it ever impacts a customer. Both often start with automated tests, which are run on Dev or local instances, to verify the changes are non-breaking.
    • Love of Automation. Neither Dev nor Ops enjoy manual, error-prone work. Both gravitate to tools that automate routine tasks, reducing variances and errors.
    • Star Wars. Finally, both groups are avid “Star Wars” fans. Just watch how they open automatic doors using the force or name servers or other things with sly “Star Wars” references (such as “Secret Rebel Base”). In fact, next time you’re in a DevOps meeting and somebody is wondering if Dev and Ops can get along, bring up Jar Jar Binks and marvel at the immediate—there will be a completely concordant reaction from both sides.

    So, are Dev and Ops from different planets? I don’t think so. I see Dev and Ops as being like those twins separated at birth, who, when reunited decades later, laugh the same, have the same twitches and both married spouses with the same first name. And in the best DevOps shops I have seen, that’s a really good thing.

    — Joshua Platt

  • DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    In this DevOps Chat we speak with Cyara CEO and co-founder, Alok Kulkarni, about how DevOps is helping in the customer experience arena. Cyara has carved out a leadership role in bringing DevOps to CX. Alok is a delight to speak with and very wired into this space.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.


    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Alok Kulkarni, CEO and Co-founder of Cyara. Alok, welcome to DevOps Chat.

    Alok Kulkarni: Hey, Alan. Great to be here.

    Shimel: It’s our pleasure to have you here. So, Alok, let’s—before we jump right into what I wanted to talk about today, I think the first thing we should do is a little level set. Maybe we have some folks who are familiar with Cyara, maybe we have some folks who are not. Why don’t you give us kind of a quick background on Cyara?

    Kulkarni: Sure, Alan. So, Cyara is a customer experience assurance platform, which allows customers to accelerate their CX development right from the design through to testing and all the way through to customer experience monitoring for customers’ journeys end to end.

    And so, what’s different about us is, we support the entire software development life cycle from the design through the functional integration testing right through to user acceptance testing, including load testing and production monitoring. And, in the CX world, we’re able to do this from an end customer perspective across all the different channels that the customer might be interacting with the organization. So, that’s just a brief summary of what we do.

    Shimel: Sure. And you are the Co-founder and CEO.

    Kulkarni: Mm-hmm.

    Shimel: And just, while we’re here—

    Kulkarni: Yes, and—

    Shimel: —give us a little bit of your own personal journey. How did you come to be the co-founder and CEO at Cyara?

    Kulkarni: Sorry, go ahead.

    Shimel: Oh, I’m sorry. I was going to say, if you can give us a little bit of your own personal journey, how did you come to be the CEO and Co-founder of Cyara?

    Kulkarni: Oh, great question, Alan. Sorry, I lost you there for a bit. I was working at another software company, which is currently the leader in customer experience management technology, and one of the things I found in those days—this was in the late 2000s—was, every time we put the technology in production, the customers, the end customers used to deal with this new technology and the enterprises would be sitting there with white knuckles hoping and praying that it would all work—because there was no platform in those days which would enable them to test and monitor the technology that they were putting in for the customers from the outside in. So, essentially, it was like playing Russian roulette.

    So, I felt, being an architect at this company and managing the solutions engineering group at this technology company called Genesys that, there had to be a better way. And one of the—the idea came to me when we were rolling out a large implementation for an Australian government organization when it failed. I thought that there must be a better way of doing this.

    So, hence, I felt—imagine if there was a cloud-based platform that was technology agnostic which enabled enterprises to just use and simulate customers from the outside in to be able to test and monitor, not only the infrastructure, but the applications from an end to end customer journey perspective. It would really take the risk out of deploying new and innovative solutions in the market. And so, that’s how it all happened. So, I got together with my buddies and we built Cyara.

    Shimel: Excellent. So, you know, in so many ways, there’s so much DevOps there, if you will, Alok. And first of all, the idea of—and we see this in security, we’ve seen it with other forms of QA—the idea of waiting ‘til after something is deployed to see if it works or not, you know, that white knuckle moment? Why?

    Kulkarni: Mm-hmm.

    Shimel: I mean, why, in this day and age, do companies still want to do stuff like that, right? And this is, especially when we talk about sort of the modern software factory and CI/CD pipelines and so forth, right? We shouldn’t let software out there that hasn’t been fully vetted and tested. Why would we let software and things in the wild, where we haven’t already tested what our customer response, and our customer experiences are going to be and whether they will work?

    It just seems like such a no-brainer. Why do you think it took so long for people to come to this realization?

    Kulkarni: So, I think that’s a great question, Alan. And, you know, when we were sitting there noodling on whether we should start this, I remember going to my co-founder, Bonny, and asking him, “Hey”—because he wasn’t from the industry, and when we came up with this idea, he goes, “Surely, there’s somebody doing this.” Because it’s exactly what you said—it’s a no-brainer. And I said, “No, there’s actually no one doing this.”

    And I think the reason for that is, one is, I don’t think people in the—if you’re not in the industry, you don’t even know that this is a problem, that’s one. Second thing is, even if you were in the industry, it is so complex. I mean, there are so many different moving parts, so many technologies. Then you have enterprise processes and systems and systems integrators and so forth.

    So, by the time you’ve put that whole, all those components together, it becomes very difficult to build something simple that would solve these problems. So, when we did it, it just took off. And now, like you say, I think customers are realizing that there is a technology or a solution out there that can help them. So, we’ve had a tremendous, I guess, following of customers who actually just continue to expand what they do with Cyara and we’re signing new customers on as we go along.

    So, just this last quarter, we signed about 25 Fortune 500 companies to our platform. So, I think it’s catching on, and now, what we’re seeing is the next wave, like you mentioned, this whole DevOps wave that’s really taking firm hold in the way that more and more organizations are putting out a software or capability. And I think in the CX world, that’s changing as well. So, I think, we’re also creating awareness that you can bring DevOps to CX and although the tool set might be a little different, you can actually do it. So, we’ve had a tremendous amount of traction in the market with that.

    Alan Shimel: Absolutely. You know, Alok, it talks to something else that we’ve seen in DevOps. When we first started devopsy.kinsta.cloud on March 11th of 2014, I think it was, so it’s almost five years now—the whole, “What is DevOps?” argument was raging. And there was a large percentage of the community that had a very orthodox view of DevOps, that if it wasn’t purely about software development and deployment in terms of operations and APM, it wasn’t DevOps, right? That’s what—there was a very narrow definition of DevOps.

    We’ve seen that expand, right, to what I call DevXOps now.

    Kulkarni: Mm-hmm.

    Shimel: We’ve seen DevSecOps, we’ve seen DevBusOps, we’ve seen DevSalesOps. It’s really taking that DevOps mindset that DevOps can do and applying it to everything.

    So, really, we’re almost seeing here DevCXOps, right, if you will.

    Kulkarni: Yeah, totally. Yeah, I think we are in that era now of DevCXOps, just like you mentioned. Because, just like software organizations were putting out new capabilities in a rapid manner, I think customers were expecting customer facing technologies, and the way they’ve been—the way that they’re interacting with organizations to change rapidly as well. Because everyone’s time poor, they need the answers as soon as something goes wrong or if they want to buy something, they’re impatient, because we all have things to do and we’re on 24/7.

    So, it’s imperative for companies providing customer experience to keep up with that. And I think DevOps provides a great framework to do that, and it’s aligned so, as you say, if you’re already in DevOps and the digital world, you can bring it to the CX world. And I think it’s really catching on.

    Shimel: I don’t disagree. I think another thing, Alok, and you hit on it there, is customer expectations. You know, one of the sort of forgotten heroes or the forgotten catalyst behind all of the DevOps kind of movements is what really—people don’t go fast just to go fast. Well, maybe some do, right? There are speed freaks, right? [Laughter]

    But, you know, people who adopt agile DevOps and these sorts of frameworks and methodologies do so to be more responsive to customers. And that’s really—and it’s nitty-gritty. That’s what it’s about. Because that’s why companies do things, to serve their customers better. And that’s really the guiding principle behind CX as well, right? How do I respond to customers better, especially in a world where customers demand more? They want 24/7 support and response, and they want it right away, and they want it now and they want it to work, right? There’s a low tolerance if your cellphone coverage is not good, or your internet—as we spoke about—your Internet at 30,000 feet on a plane is not working, and people get really upset about that now. And in so many other ways, customer demands are driving this. Correct?

    Kulkarni: Yeah, totally. And you know, what’s sad is, we’re fickle. You know, we’ve been conditioned to now have choice. So, if we don’t like the service a particular company is offering, you know, we switch, and switching is so easy, because it’s very easy to find another provider who provides a similar service and offering and then if they have a better customer experience, you think when you actually have that moment of need where you actually need help and they’re providing it to you promptly and they’re resolving your issues quickly and they’re doing it how you want to be treated, maybe it’s a late night chat or a phone call because it’s super urgent or it’s complex. Or maybe it’s like, “I don’t want to talk to anyone today, but I need the information for my support, because one of these technologies that I’ve got isn’t working, so I need a knowledge base that I can refer to.”

    Any of these customer-facing technologies play a very important part in customer loyalty and thereby, shareholder value for the company that they’re dealing with.

    Shimel: Agreed, agreed. So, Alok, if you don’t mind, I want to talk a little Cyara—I’m sure you don’t mind. [Laughter]

    Kulkarni: [Laughter]

    Shimel: So, do you offer this as more of a Platform as a Service or as a SaaS based offering?

    Kulkarni: Yeah, it’s a SaaS-based offering, so we have a cloud infrastructure environment which spans, which goes across the globe. Just last year, we placed 4.4 billion call seconds’ worth of synthetic interactions to assure customer experience around the world, and some of the largest brands of the world use it.

    So, some customers, they use our platform to provide the whole design experience—like, the design, the customer experience in Cyara is able to, as a result, get a full automation and regression test suite that they can run as part of their DevOps factory, and then we have a real time customer experience monitoring platform.

    So, for example, if you put something out in production, our platform actually is able to generate synthetic customer interactions from the outside in. So, we can actually emulate, Alan, contacting an organization on your behalf and actually see what experience you’re going to get, whether your interactions or your calls connected on time, whether the web chat gave you the right responses, whether the screen froze or not, and you can do this all in real time.

    So, customers have a direct feedback loop that they can implement. So, as soon as something goes into production and it doesn’t work, before a real customer is able to have a poor experience, we’re able to detect it early on and the customers can then roll back the technology that they had implemented and then roll the previous last known good version out so that they maintain the sanctity of the customer experience.

    So, it just—to me, that just goes hand in hand with the whole DevOps paradigm.

    Shimel: I agree. It certainly does. So, Alok, if I ask you to kind of peer into your crystal ball of the future, where do you see this going now?

    Kulkarni: So, as you mentioned, Alan, there’s a lot of companies out there who are not even aware that they can apply the whole DevOps—they can bring CX to DevOps and, as you call it, DevCXOps, and make it happen. So, I feel, over the next two years, we’re going to see a tremendous wave of customers adopting this framework, because they’ve already done it on the digital side and the CX side tends to be—I think they’re in an adjacent area and I think they are moving to this new model.

    So, we’re going to see a lot of customers offering it, and I think we’re going to see a lot of new, innovative technologies coming out with integrated solutions for that. So, I think for Cyara, we want to support our customers as they go on this journey. So, we’re integrating with a number of platforms out there that enable the whole CX DevOps pipeline scenario. For example, we’ve just integrated with Splunk, we’ve integrated with ServiceNow. So, in Cyara, you can actually get real time incident notification of any technology that you’re implementing and automatically create service requests so that you’re able to keep ahead of the whole customer experience pipeline.

    And the other thing that we’re doing is also investing heavily on the design aspect of it. So, we’re working with companies like Amazon and so forth to offer a platform that is able to take customers that are moving to the cloud or moving to cloud contact centers, which is becoming, which is a new wave that’s still catching on and enable them to essentially drive this whole assurance through to all their customers.

    Shimel: Excellent, excellent, excellent. Well, Alok, as we—I think I told you before we started, the time goes really quick. We only have a few minutes left. I wanted, also, I’d like to finish up with kind of wrapping this whole thing back into the DevOps, back into what Cyara is seeing from customers.

    Companies I’ve been involved in, and I’ve founded a few, you know, we had sort of a customer support, a customer help team. It was separate from developers, it was separate from Ops. It was part of the engineering team, but it was almost a red-headed stepchild within that engineering/IT team. Is that still the case? Is that a problem? Is that something Cyara runs into when you’re talking to folks? What’s the story?

    Kulkarni: So, I think you, again, Alan, are right up there with it. So, I think one of the decisions organizations that we deal with are grappling with is, do they make engineers who understand software and make them CX developers, or do they make CX developers who have real code domain expertise and bring them onto the DevOps world?

    And I think that’s a question a lot of companies are asking themselves—like, do we need to really understand this space from top to bottom, or do we get developers? Is it easier for developers to learn this versus the other way around?

    And I think that’s currently in the experimentation stage. So, a lot of companies who have tried the old model feel that it’s just very hard to change the mindset of the old engineering folks to—you know, who’ve been traditionally used to waterfall and doing large scale implementations and using systems integrated to put those out to really just come onto this whole new, you know, go fast, break things mentality versus getting those guys to understand CX.

    So, I think there are two horses running right now, and I think we’ll see the results of that in the next year or two. But what I am seeing is a lot of companies trying to get their developers onto the CX world, because they’re finding that that seems like a much easier path.

    Shimel: I don’t disagree with you. Crazy. Interesting times.

    Kulkarni: Yeah.

    Shimel: Anyway, Alok, I know we’re doing some other, you’ve published some more—well, not you, but Cyara has published some nice articles on devopsy.kinsta.cloud lately, we’ve done some other activities.

    Where else can people find out more information, though, about Cyara?

    Kulkarni: Well, they can obviously come to our website, so Cyara.com, that’s C-Y-A-R-A dot com. And I think we have, we’ve built a huge library of resources thanks to our fantastic team that we have at Cyara, and they can also—I think over there, there’s a whole library of collateral that they can view. We’ve got a YouTube channel that they can subscribe to.

    And we also have Cyara Academy. So, as part of that, they can go in and if they want to actually get trained on Cyara, we offer that on demand as well. And you don’t—I think there are some courses where you don’t have to pay. So, I think you can, if you’re new to this space, I think it’s a great place to get scaled up, because I think this is a very exciting space. Because, as you’ve said, Alan, every company, to be successful, needs to really deliver a superior customer experience to their end customers and I think it’s just the core of any fundamental for any company to get this right.

    So, come on over to Cyara.com and get yourself educated.

    Shimel: Cool. Well, Alok Kulkarni, CEO and Co-founder of Cyara, thanks for being our guest on this interview, on this episode of DevOps Chat, and we hope to have you back on again soon.

    Kulkarni: Thanks, Alan. Would love to come back.

    Shimel: Alrighty. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard, Container Journal. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • 5 Questions to Ask Remote Web Developers

    5 Questions to Ask Remote Web Developers

    Great web developers are waiting to be hired. Your company could seize upon the opportunity—but only if you’re willing to be patient, dedicated and a little creative.

    Don’t scare away qualified remote web developers with a few poorly worded questions or a mistimed probe. Ask direct and concise questions that can help you understand the candidate.

    Be sure to include the questions listed below to ensure you’re interviewing a remote web developer to the best of your ability:

    1. Have You Worked Remotely Before?

    Remote work is different from many traditional forms of work. For a company to properly manage a remote web developer, the web developer must have a solid understanding and knowledge of remote working environments.

    If an exceptional web developer candidate hasn’t telecommuted before, it doesn’t bar them from the pool of qualified candidates. However, it is easier to onboard and retain remote web developers who have had the experience of working remotely beforehand.

    2. Are You Familiar with Popular Web Development Frameworks?

    Remote web developers, like any other web developer, must stay abreast of the latest trends and advancements in the web development field. To master their craft, they must keep a running knowledge of the latest tools, frameworks and web programming languages.

    An experienced web developer should, at the very least, be aware of a large and robust framework such as Bootstrap. They should be able to explain how the framework works, why web developers use it (it’s much better to utilize a framework to save time, in most cases) and the drawbacks of utilizing a premade framework.

    3. How Much Experience Do You Have with Web Programming Languages? Are You Familiar with Server-Side Languages?

    Every web developer should be proficient in HTML and CSS. Scripting languages such as Angular.js, Express.js and JSON are important, too. JavaScript adds interactivity to websites. HTML acts as the skeleton and CSS acts as the design.

    Preferably, an experienced remote web developer candidate will have three to five years of experience with these languages.

    It’s also important to ascertain whether the web developer you’re interviewing has the ability to code the back end of websites. Do they know how to set up a database? Do they understand how to store values in a website’s database?

    4. Which Content Management Systems Do You Use?

    A content management system (CMS) helps streamline organizing, adding and managing content for a website.

    One of the most popular CMS is WordPress. Web developers leverage CMS to utilize built-in structures and architectures to create dynamic blogs and alluring corporate websites.

    Setting a website up with a CMS also makes it easier for writers, marketers and designers to tweak already-developed websites. They can add content without needing the web developer to intervene.

    5. Are You Comfortable with Regular Phone and Video Meetings? Do You Have Experience with Telework Software?

    Remote work has unique challenges. One of the most challenging aspects of working remotely is maintaining communication. Miscommunication can occur more easily for remote workers, so it’s important that you keep communication lines open and stress the importance of speaking clearly and confidently.

    It’s much better if a candidate already has experience with telecommunication software such as Zoom, Skype or Slack. Knowing how to interact via these technologies will lessen the chances of miscommunication in telework environments.

    Conclusion

    How you conduct a remote web developer interview is entirely up to your organization. There are several methods for conducting technical interviews, telework interviews and startup interviews. Each one of them is effective in a unique way; very few are ineffective or harmful. Adding a few questions to your interview script could help make whichever strategy you employ more effective.

    Ask remote web developers about their experience working remotely. Remember to ask about experience with certain telework software programs and telecommunication applications. On the technical side, be sure to ask about programming skill, familiarity with web frameworks and their experience with CMS.

    Companies that seek to hire remote web developers should take note of the interview questions listed above. By asking these five questions, interviewers can gain a great deal of insight into a web developer candidate’s habits, passions and challenges.

    Using these interview questions should make the vetting and hiring process easier for everyone, helping interviewers assess a candidate’s adaptability, experience and dedication.

    — Anthony Coggine

  • Successful Strategies for Hiring Full-Stack Developers

    Successful Strategies for Hiring Full-Stack Developers

    Full-stack development is a complex web programming discipline involving multiple levels of web design and coding.

    Due to the complexity of the skill, it may be difficult to strategize a method of attracting a full-stack developer. Full-stack developers are the full package—they understand the development of both the front end and back end of a web application.

    To hire full-stack developers, you’ll need patience. Full-stack developers are incredibly valued as they bring insight, perspective and technical prowess to the table. Their understanding of software development is complete, making them helpful team members to any and every development team.

    With the right tips, you can find the perfect candidate for your open position. The following strategies will ensure that you attract the best full-stack developers to your company.

    Leverage Tech Communities

    Tech community boards are invaluable resources for hiring managers. They are communities that thrive on the question-and-answer formats along with teamwork and collaboration. They often feature complete profiles of their developers, which will grant you a deeper look into how they interact and cooperate within the confines of their respective communities.

    Stack Overflow and GitHub are perfect examples of all-inclusive development communities. Each allows users to upload code and ask questions. In the case of GitHub, many users frequent the site as early as high school or college. Therefore, you have the chance to watch and document the growth process of your candidate in a way that you never could before. You can also follow the candidate’s question-and-answer history to observe how they learn and how quickly they adjust.

    Each of these opportunities grants the hiring manager intelligence that would have been previously impossible to acquire and will give you a depth of understanding with your candidate that will be vital when making your final decision. These sites give hiring managers an advantage and insight that can be positively crucial when hiring a full-stack developer.

    Write an Enticing Full-Stack Job Listing

    Finding a full-stack developer can be quite a difficult task, as full-stack developers are in short supply. To attract top talent, you’ll need to entice them, make your job opportunity seem unique.

    The job listing should:

    • Include a hook that captures the developer’s attention (e.g. “Work your dream developer job from home!”).
    • List all duties (e.g. database management, front-end web development, back-end engineering).
    • List all tools, libraries and platforms necessary for the job.
    • List the team members who will work with them.
    • Include a concise description of the kinds of projects the team will be working on.
    • List the benefits of the full-stack developer role.
    • Include a summary of what your company does.
    • Have a call-to-action (e.g. attach your resume below; email us for more information).

    Utilize Niche Job Boards

    Full-stack developers have a plethora of technical skills. To find technically skilled people, your best bet is to use job boards such as Dice, Stack Overflow Jobs and GitHub Jobs. If you researched and connected with people through online tech communities, then it should be even easier to leverage these tech job boards.

    Some other niche job boards that can be helpful for companies looking for dedicated full stack developers:

    • co
    • CrunchBoard
    • Authentic Jobs
    • RemoteOK
    • WeWorkRemotely
    • Top Tech Jobs
    • Startup Hire
    • IT Job Cafe
    • Tech Careers
    • iCrunchData

    Conclusion

    Your company needs to employ helpful hiring strategies to find and hire top full-stack developers. One of the best ways to start your hiring journey is to research, of which this guide is hopefully a part.

    Research includes investigating and interacting with online tech communities. The information you’ll gather will be invaluable during the hiring process, helping you find leads, build connections and write effective job listings. Remember: An enticing job listing is a key to attracting top developers.

    Finally, you’ll want to leverage specialized job boards to find and attract full-stack developers. Use tech and remote job boards to find qualified candidates more quickly and efficiently.

    Hiring full-stack developers can be difficult, but by no means is it impossible. Simply use the strategies above, conduct your own research and start following leads. Sooner rather than later you should find a full-stack developer.

    — Greg Robinson

  • How to Troubleshoot CPU Problems

    How to Troubleshoot CPU Problems

    Diagnosing and troubleshooting CPU problems in production in cloud environments can be tricky. Your application might have millions of lines of code, so identifying the exact line of code that is causing the CPU to spike might be the equivalent of finding a needle in a haystack. This article shows how to find that needle (i.e. CPU spiking line of code) in a matter of seconds/minutes.

    To help readers better understand this troubleshooting technique, we built a sample application and deployed it to an AWS EC2 instance. This application when launched caused CPU consumption to spike up to 199.1 percent. Here are the steps we followed to troubleshoot this problem:

    1. Identify threads that consume CPU.
    2. Capture thread dumps.
    3. Identify the lines of code causing the CPU to spike.

    Identify Threads Causing CPU Spikes

    In the EC2 instance, multiple processes could be running. The first step is to identify which process is causing the CPU to spike up, and the best way to do that is to use the ‘TOP’ command present in *nix flavor of operating systems.

    Issue command ‘top’ from the console

    <<start:code>>

    $ top

    <<end:code>>

    This command will display all the processes that are running in the EC2 instance, with high CPU consuming processes displayed at the top. When we issued the command in the EC2 instance, we saw the below output:

    Fig: ‘top’ command issued from an AWS EC2 instance

    From the output you see process #31294 is consuming 199.1 percent of CPU, which is high consumption.

    Now that we know which process in the EC2 instance is causing the CPU to spike, the next step is to identify the threads within the process that are causing the spike.

    Issue command ‘top -H -p {pid}’ from the console. Example:

    <<start:code>>

    $ top -H -p 31294

    <<end:code>>

    This command will display all the threads are causing the CPU to spike in the 31294 process. When we issued this command in the EC2 instance, we received the below output:

    Fig: ‘top -H -p {pid}’ command issued from an AWS EC2 instance

    From the output you see:

    • Thread Id 31306 consuming 69.3 percent of CPU.
    • Thread Id 31307 consuming 65.6 percent of CPU.
    • Thread Id 31308 consuming 64.0 percent of CPU.
    • The remaining threads consume negligible amounts of CPU.

    Now that we have identified the threads that are causing CPU to spike, the next step is to capture thread dumps so we can identify the lines of code that are causing the CPU spikes.

    Capture Thread Dumps

    A thread dump is a snapshot of all threads that are present in the application. Thread state, stacktrace (i.e. code path that thread is executing) and thread ID-related information of each thread in the application is reported in the thread dump.

    There are eight different options to capture thread dumps. You can choose the option that is convenient to you. One of the simplest options to take thread dump is to use tool ‘jstack’ which is packaged in JDK. This tool can be found in $JAVA_HOME/bin folder. Below is the command to capture thread dump:

    <<start:code>>

    jstack -l  {pid} > {file-path}

    <<end:code>>

    where pid: is the process Id of the application, whose thread dump should be captured and file-path: is the file path where thread dump will be written to.

    Example:

    <<start:code>>

    jstack -l 31294 > /opt/tmp/threadDump.txt

    <<end:code>>

    In this example, the thread dump of the process would be generated in /opt/tmp/threadDump.txt file.

    Identify Lines of Code Causing CPU Spikes

    The next step is to analyze the thread dump to identify the lines of code that are causing the CPU to spike. We analyzed our thread dumps through fastThread, a free online thread dump analysis tool.

    Once we uploaded the captured thread dump, the tool generated this report with multiple sections. On the right top corner of the report is a search box, where we entered the IDs of the threads consuming high CPU—basically, the thread IDs that we identified in step No. 1: 31306, 31307 and 31308.

    fastThread displayed the threads’ stack trace, as shown below.

    Fig: FastThread tool displaying CPU consuming thread

    You can notice all the three threads to be in RUNNABLE state and executing this line of code:

    <<start:code>>

    com.buggyapp.cpuspike.Object1.execute(Object1.java:13)

    <<start:code>>

    Apparently following is the application source code:

    <<start:code>>

    1: package com.buggyapp.cpuspike;

    2:

    3: /**

    4: *

    5: * @author Test User

    6: */

    7: public class Object1 {

    8:

    9:         public static void execute() {

    10:

    11:                   while (true) {

    12:

    13:                               doSomething();

    14:                   }

    15:       }

    16:

    17:       public static void doSomething() {

    18:

    19:       }

    20: }

    <<end:code>>

    You can see line No. 13 in object1.java to be ‘doSomething();’. You can see that ‘doSomething()’ method is doing nothing, but it is invoked an infinite number of times because it doesn’t terminate but loops due to line No. 11. If a thread starts to loop an infinite number of times, the CPU will start to spike. That is what exactly happening in this sample program. If the non-terminating loop in line No. 11 is fixed, the CPU spike problem will go away.

    Conclusion

    To summarize, first we need to use ‘TOP’ tool to identify the thread IDs that are causing the CPU spike, then we need to capture the thread dumps. The final step is to analyze thread dumps to identify exact lines of code that are causing CPU to spike up.

    Enjoy troubleshooting and happy hacking!

    — Ram Lakshmanan