staging-devopsy.kinsta.cloud

Tag: developers

  • How to Build a Highly Qualified Cloud-Native Team

    How to Build a Highly Qualified Cloud-Native Team

    If you’re reading this, you more than likely are aware of the struggles involved in recruiting and building a team of technical professionals skilled in cloud-native computing technologies such as Kubernetes, Helm, Prometheus and service mesh. The Linux Foundation and edX’s “2020 Open Source Jobs Report” found 93% of hiring managers are having difficulties filling open positions that require open source skills like these. The report also found that cloud and container technologies are the most in-demand aside from Linux, which itself is a necessary basic skill for cloud professionals.

    So the question is, between a talent shortage and rapidly increasing adoption of these technologies, how can any leader manage to build out a qualified team? Based on our experiences as a vendor-neutral provider of training and certification for many of these technologies, we’ve learned some tips and tricks that, with some effort, can help you establish a team that can handle any cloud-native project you throw at them.

    Don’t Rely on the Same Old Recruiting Strategies

    It’s important to understand that the most promising cloud developers, engineers, administrators and other team members may not have the most prestigious qualifications. You may often find a high school dropout who has completed a cloud computing bootcamp and passed a Kubernetes certification exam will be far more able to perform the functions of a job than a recent graduate with a computer science degree. This means you need to set the job qualifications appropriately.

    If your organization is going to limit these hires to those holding a college degree, you are reducing an already limited talent pool even further and you’re going to miss out on some incredibly talented individuals. Instead, look at demonstrable skills and experience rather than only education. Some of the most talented contributors to these open source projects themselves don’t hold degrees; if the people building these technologies don’t need one, then neither do the ones implementing and administering them.

    Of course, you should continue to look at candidates with computer science degrees—after all, you’re trying to expand your access to talent, not reshuffle your sources. College degrees are a valuable indicator of intelligence and tenacity in completing a rigorous program. But do not take the degree as evidence they can perform any cloud-native tasks. Look at their specific skills, what the university curriculum was, any external training or self-study they conducted and verifiable credentials.

    Structure job postings as a list of skills and abilities necessary to be successful in the role rather than specific educational requirements or years of experience—in fact, many of these technologies are so new that no one has more than a year or two of experience with them. Avoid absolutes where possible and encourage folks to apply even if they don’t check every single box. And if you do want to ensure that someone is up to the challenge, you can require they hold verifiable certifications. The trick here is to find the certification most respected in the industry for a particular skill set, and prioritize performance-based certifications that test abilities to knowledge-based ones that only test memorization.

    Go Where the Developers Live

    Do not expect a wave of great applications just because you throw a well-crafted job posting on the internet. Many of the most talented cloud-native pros out there don’t bother looking for opportunities as they are already constantly bombarded with them. You need to find them where they are spending their time, which is likely message boards and forums such as StackOverflow and Reddit. LinkedIn can sometimes be effective, but experience shows this type of expert is less likely to spend time there than individuals working in many other professions.

    And do not simply bombard these professionals with job opportunities, either. You need to make your organization stand out and demonstrate why they should want to come work for you. The Open Source Jobs Report asked opens source pros what would make them consider moving jobs—while to no one’s surprise salary is a top incentive, 65% stated the opportunity to work on interesting projects would tempt them, while 58% desire a better work-life balance and 51% want more flexible schedules or telecommuting options.

    Talk these up in your outreach, but you should also put your money where your mouth is. Sixty-three percent of the hiring managers surveyed this year said their company has decided to contribute to an open source project, either financially or by contributing actual code, for the express purpose of attracting developers who work on that project. If your organization is using open source technologies but not giving back to the community, you will miss a significant opportunity to raise your profile among target recruits.

    Take a Chance and Help Them Grow

    Let’s say your company is participating openly in open source, being a good community member, offering competitive benefits, being open to considering individuals from a broad range of backgrounds and advertising your open roles in ways that both get in front of and attract talented cloud-native professionals. Despite all this, you still have not been able to recruit enough talent to tackle the needs of your organization.

    The first recommendation when you’re at this stage is to look at your existing resources: Are there talented individuals in your organization who do not possess the skills necessary to perform these tasks but possibly could with the proper training? If so, give them the chance to grow into such a role. You can start off with very little risk involved; ask them to complete a free introductory training course and report back after. Consider how long it took them to complete the course and ask them how they feel about this type of work. It should be apparent quickly who is enthusiastic and excited about learning a new technology and who is not. You can then sponsor those who show promise for more advanced training courses and certifications to demonstrate they have gained the necessary skills to move positions.

    If you don’t have anyone internally who either can or wants to train for a cloud-native role, look at recruiting someone with promise and make clear from the start that the expectation is they will complete training and gain an appropriate certification within a specified time period. Look for individuals who have already demonstrated both grit and an ability to learn. Perhaps they have an entry-level IT certification that is far from meeting your requirements but still shows that they can complete this kind of program. You’ll find many candidates are strongly enticed by such an offer.

    This is reinforced by the data from the Open Source Jobs Report: 54% of developers surveyed stated that lack of employer-sponsored training is a major hindrance to their job and 70% stated that increased training would make them more effective. 70% of hiring managers also stated that they’ve seen more requests for training from employees the past year.

    Summary

    We know it’s a tough job finding qualified cloud-native talent to fill open roles, and it is not expected to get easier anytime soon. By putting in a concerted effort, being thoughtful and flexible about the types of applicants you consider and giving existing and potential employees the opportunity to grow into these roles, you and your team can be successful.

    This article is part of a series of articles from sponsors of KubeCon + CloudNativeCon 2020 North America

  • How To Foster a Culture of Citizen Developers

    How To Foster a Culture of Citizen Developers

    What can leaders do to encourage a thriving environment of citizen developers in their organization?

    Over the last several months, businesses of all sizes have had to embrace rapid change, as have their workforces. When it comes to IT departments, even before the pandemic many were fielding requests to implement new technology, customize solutions to niche problems and automate specific tasks at rapid rates. Unfortunately, these increased demands coincide with an ongoing developer drought, and paired with the pandemic, have put an added strain on some already thinly stretched IT teams.

    As a result, there has been an observable rise in citizen developers being tapped to relieve some of this burden. “Citizen developer” here is used to describe any programming novice or non-developer who has been tasked with the responsibility of constructing custom applications. This person has some familiarity with programming but may not have been formally trained and, therefore, may use their own set of tools and workarounds to complete the work. If leaders don’t make an effort to create standardization, the consequence can be high variability in quality, efficiency and output.

    And it doesn’t seem to be a passing phase. I recently spoke with Dave Garrett, chief strategy and growth officer at Project Management Institute. As we look to the future, Garrett believes that citizen developers will play a critical role in helping organizations stay agile and ensuring projects move forward without delay.

    Though it won’t solve all of your pressing technical concerns, the good news is that with smart strategies, a citizen development emphasis can ease the burden on IT teams and improve output. Garrett spoke to a sea change of new techniques being developed to respond to these growing needs.

    4 Elements of Strong Citizen Developers Culture

    1. Standard Toolsets

    To start, build a solid foundation by choosing standard toolsets. Be sure all development staff is made aware of the toolsets you’ve deemed standard, clarify that adopting them is a priority and ensure that all have access. Standard approaches to using these tools should also be established and communicated, such as programming languages and stylistic standards.

    “If you have a standard toolset and approach, then you have many people who can help,” Garrett said, emphasizing that by doing so, you are building a broader base of support. Having a larger pool of employees to pull from helps an organization stay on top of the necessary tasks and creates more freedom for open collaboration. As a bonus, professional developers are freed to focus on more advanced tasks, such as machine learning and or mathematically complex programming.

    In deciding which toolsets and approaches to make standard, Garrett said, ask yourself, What will get them from A to B most quickly and efficiently? One approach to this is low-code or no-code tools. He considers such platforms transformational in empowering citizen developers to express ideas tangibly without a great deal of coding.

    2. Technical Training

    From here, ensure that all development staff, especially your citizen developers, have been technically trained in adopting the standard toolsets and approaches that have now been established. This may include offering training in low-code UIs and instilling fundamental programming concepts such as boolean logic and conditional programming such as If/Then/Else statements.

    “Set a foundation of success for learners,” he said. For example, have them build something of value during training, making it as actionable as possible for the use cases they will be handling.

    3. Discouraging Use of Shadow IT

    Once you have established toolsets and training, leadership should do whatever’s possible to enforce the established standard’s adoption and discourage the use of shadow IT—tools, applications and workarounds not approved by leadership within the company. Shadow IT, as a practice, can be messy, creating high variability and making quality-control and collaboration difficult. “You want to avoid it,” Garrett said.

    4. Good Mentorship and Governance

    Another benefit of having a standard toolset and eliminating shadow IT use is that it enables more efficient mentorship—critical for inspiring citizen developers. IT teams are advised to identify a mentor or group of mentors proficient with the standard tools to offer ongoing guidance to the team’s citizen developers.

    Quality mentorship goes hand in hand with quality governance. “Governance” here is used to mean technical admins who enforce the use of technical standards, tools and programming styles. No-code tools require access control that reflects a citizen developer’s permissions.

    Building in Hyper Agility + The Two-Pizza Rule 🍕🍕

    One way to think, Garrett said, is hyper agile. This can apply to team size, smart PM cycle lengths and brainstorming techniques.

    Team Size

    In thinking of ideal team size, ask: How can the team be optimized to work quickly and efficiently? One suggestion Garrett had was to ensure your team isn’t too large to effectively train, mentor and govern. For example, as a rule of thumb, he mentioned the old “two pizzas” rule: A team size shouldn’t require more than two pizzas to share a meal.

    Sigh. Remember things like in-person training? Pizza parties? Obviously, old meetups can’t be executed exactly to plan these days, except with some clever contactless delivery tactics, but you get the idea. A strategically sized team will create an efficient workflow and collaboration in your team dynamics.

    Cycle Length

    As projects come in, an agile cycle length, or sprint, for completing a specific set of work should be determined. What is an efficient amount of time to expect a team to turn out a project? To determine this, sprints should start with a planning meeting during which the product owner defines the work criteria. The development team determines a realistic time frame to complete the work scope. The scrum master or team manager typically makes this call.

    The lengths of agile sprints can vary—some may be two weeks, while others may be 30 days—depending on the scope of work. Most project management experts recommend you aim to keep your cycle length consistent, so teams get used to working within a set amount of time.

    Brainstorming

    Bringing attention to how your team ideates together is an excellent way to build agile collaboration. Brainstorming as a development team fosters collaboration and allows you to aggregate the talent and pull ideas together for the best output, whether you’re trying to solve a niche problem or simply join forces around how best to complete the sprint.

    Garrett recommended bringing people together in smaller groups for round-robin brainstorms and creating as you’re ideating. “Thus, iterations happen fast,” and all team members are given a chance to express their ideas in a tangible way.

    Once citizen developers see success, you can then use the excitement of building applications and solutions together to drive things forward, he said. Your anchor is a cool product that gets people excited—great for both morality and high-quality output.

    When Are Citizen Developers Appropriate?

    The question should be asked: When is it appropriate to call on citizen developers? Garrett recommended performing a suitability assessment to identify the best use cases for citizen developers. This will help the organization understand when it’s smartest to bring them in.

    The easiest way to answer this may be to consider: When isn’t it appropriate? Assigning advanced processes to citizen developers such as algorithm-heavy, mathematically complex programming or core product functionality is usually inappropriate, he said. Instead, utilize citizen developer talent for constructing internal business utilities that can be automated easily.

    There are formal suitability assessment tools that look at scores and attributes for applications to help you make this call. “However, everyone’s different,” Garrett noted. “You have your own ways of working, given context, goals and what you’re trying to accomplish.” So it may make the most sense to perform your own internal suitability assessment.

    Do the Numbers

    According to a recent PMI report, over the past five years half of organizations have recognized team members who brought innovative ideas forward, but:

    • Only 25% required dedicated time for innovative thinking and idea generation.
    • Only 19% hosted a creativity lab or hackathon facilitated by a professional.

    By contrast, their research shows that those promoting innovative practices see stronger results. Case in point:

    • 80% of organizations that encourage project leaders to expand their role have invested in at least one innovative idea in the past five years.

    The trend PMI sees on this front is that organizations want to innovate, but don’t always know how to make it happen. So, how might they push innovation forward? If you can implement a strong citizen development toolset, you can “enable innovation to bubble up,” Garrett said. The hope is this guide offers a blueprint for fostering just that.

  • Bootstrapping DevOps for the Internet Computer

    Bootstrapping DevOps for the Internet Computer

    All startups face unique sets of challenges and issues at each stage of their existence. The DFINITY Foundation, a Swiss-based not-for-profit with the remit to extend the functionality of the internet, is no exception. Like any new organization, we have had to evolve and adapt our DevOps and other practices in response to different obstacles.

    After learning to clearly communicate our vision for an open development platform where software runs directly on the internet, we created a road map to translate this vision into a decentralized architecture with distinct features that could be built and shipped on a periodic cadence. Consisting of five milestones, the road map culminates in a public launch in Q4 of 2020—and we haven’t missed a single deadline despite the disruptions of a global pandemic.

    Incorporating a focus on operational responsibility on top of our focus to ship features without losing speed was a major challenge this year ahead of the release of our developer network, called Tungsten. Sustainably bootstrapping operational responsibility for this release, as well as future releases, was imperative.

    We’ve all heard horror stories about operational teams that run through a checklist in a perfunctory fashion without identifying the root cause of a problem. Even worse, they are quick to give up and are resistant to launching changes, increasing the complexity of their workload.

    Pushing Forward With DevOps

    We were determined that this wasn’t going to happen to DevOps at DFINITY, so we embedded these core cultural touchstones into the organization.

    1: Create SLOs and SLIs for cross-functional clarity

    At the end of 2019, well before there was a service to operate, we started thinking about service level objectives (SLOs) and service level indicators (SLIs). These are critical for providing a common, quantifiable vernacular for R&D and Operations teams to measure how a service should be performing.

    An SLI is a clearly defined indicator for one aspect of a service’s performance, ideally focusing on user-visible service behaviors. The SLO sets the target for the indicator, as well as a window of time over which it is measured.

    To communicate the SLIs and SLOs, training materials were presented across the organization, including speaking with various engineering teams, discussing best practices at management meetings and giving an overview at an organizationwide meeting. In addition, the leadership of R&D teams signed off on the approach.

    To provide clear operational expectations as well as a forcing function, we established an early version of the SLOs as a high-priority OKR.

    As an additional consideration, it is crucial that your SLOs reflect aspects of your service that are visible to the user. As Charity Majors, CTO of Honeycomb.io, noted, “Nines don’t matter if your users aren’t happy.” SLOs are not a one-and-done deal; they need to be updated as the service evolves and as your ability to capture the UX improves.

    Having SLOs in place gave staffers with operational responsibility clear expectations to fulfill. If the service is performing within the SLOs (and if the SLOs are representative of user happiness), then things are running smoothly.

    #2: Engineers developing the software should also help run the software in production

    To bootstrap the team with operational and support capabilities, we needed to ensure that we didn’t create a siloed team lacking engineering skills. Operations in this context is a software engineering problem, which meant we needed to involve developers.

    The same engineers developing the software should have skin in the game in terms of how the software is running in production. If there are problems, these engineers are in the best position to diagnose them and propose and implement the necessary fixes. Getting organizational buy-in for this took some time.

    We emphasized the need for senior engineers to be able to operate the software being built. We didn’t want to fall into the trap of throwing a handful of junior engineers into the deep end without proper supervision or training, so we also established an expectation that all engineers should be able to operate the software irrespective of seniority.

    We built two teams of between five and 10 developers in each of our office locations in Palo Alto, California; San Francisco; and Zurich, which were initially staffed with volunteers across the organization. Each week, one team member at each site managed primary operational responsibility for the service instead of their regular project work, and they knew that the entire staff would help if there were any problems. We plan to rotate new people into these ad hoc teams every six to nine months.

    #3: Create optimally sized, communicative teams

    Operational team size is also important. If the team is too small, people are on-call too frequently. If the team is too large, they will be on-call so infrequently that they will either forget how to operate the production stack or their knowledge will become outdated.

    We share status updates through a daily log and informal shared communication channels such as Slack. There is also a weekly meeting to relay responsibility from one person to another.

    This has helped us identify capability gaps. With team members based across the world, we’ve come to acknowledge that if a problem requires a team’s expertise outside of its working hours, then rolling back first and investigating later is absolutely fine.

    The DevOps team decided early on that we weren’t going to start with 24/7 support, instead providing support during business hours in Europe and the U.S., where the majority of our early-access customers are located.

    We’ve been transparent to the wider organization throughout this process, calling out what is and what is not working well, and how we’re working to improve our processes.

    Conclusion

    We were fortunate that unprecedented global events like COVID-19 didn’t significantly affect our operations. That said, shaping our processes in-person and being physically present for people when they first go on-call would have been valuable, and we definitely felt the impact of losing that. But we’ve successfully bootstrapped our DevOps teams nevertheless, and we look forward to continuing to evolve as a team.

  • 5 Ways Traceability Is Changing to Bolster the Remote Workforce

    5 Ways Traceability Is Changing to Bolster the Remote Workforce

    Traceability has always been a useful tool in the development process, but it has become especially important since the COVID-19 outbreak and the increased remote workforce. 

    Where developers and engineers were once working side-by-side, with the ability to discuss their process and keep their team informed, they are now navigating a remote collaboration landscape. According to a 2017 study done by Stack Overflow, there is a correlation for developers between remote work and job satisfaction, and the highest job satisfaction ratings are seen from developers who work remote full time. As technology has grown to make this process easier, remote working is expected to become a norm. 

    Advanced traceability has the potential to hold teams together by allowing increased visibility into each move throughout an entire project. Without traceability, it would be nearly impossible to keep remote teams aligned and on schedule.

    Product development tools have continuously been forced to evolve to keep up with the multi-dimensional nature of requirement, test and risk management. For these processes to be successful, all related variables must work together continuously, at scale, and across teams. 

    We’ve only just started to see how traceability tools can use updated capabilities to streamline the product development process, but we know enough to discuss two things: what’s happening now and what the future may hold.

    Traditionally, traceability could be compared to a map. While not limited to a single view, maps exist to help you navigate your way to a destination. Similarly, traceability leads product developers through every step of their processes, eventually helping them reach their goal. If your map was constantly changing you’d never be able to figure out where you were going, but what if people ahead of you could update it as they went along? This would keep you in the loop of the upcoming twists and turns, and no one would feel blindsided. Traceability makes it easy to share similar production changes with your entire team, all at once.

    In the traceability process, links are built automatically which lets major decision points, reviews and approvals be captured in final documents and reports. This allows for faster and more informed decision making and these live references can exist across versions. 

    With the switch to remote work across the globe, and no immediate end in sight, developers don’t have the option of working side-by-side with their colleagues. Because of this, it is pertinent that they are able to streamline their work in every way possible, and increased traceability is expected to be a pillar of that transition. 

    At the end of the day, connecting the dots is all about making sense of everyone’s decisions. Why did they follow that process, and what factors led them to make the choices they made? 

    In the early days of traceability there wasn’t always room to include every piece of information that you might find relevant down the line. Legacy tools such as the act of manual reporting through Word documents left much to be desired. Today, that’s becoming less of an issue, as developers are allowed more meaningful accountability and insight into interconnections as they happen.

    As we look ahead, we can expect to see these capabilities grow in five different ways.

    Less Manual Effort

    Updating your traceability reports with as little manual effort as possible will be essential to a streamlined, remote workforce. As traceability becomes more advanced, the work to create and maintain it should not become more difficult. 

    More Nuance Captured, Related and Parsed for Meaning

    Improvements in software will make data gathering more precise, and increase the number of items a team can consider relevant, traceable information. This will take additional workloads off of the developers as more items are automatically traced and easily accessible.

    More Attributes Can Define and Predict a Project’s Success 

    If you have a more data-rich, detailed record of activities, it is possible to understand the past with more context and less reliance on costly manual documentation or memory. 

    Dispersed Systems Holding Relevant Information Will Start to Feel Closer and More Interconnected

    Through more dense integration and aligned processes, systems feel more controlled and connected, giving users a more seamless experience.

    Expansion of Communication and Review Capabilities for Stakeholders Who May Be Impacted by Changes

    The availability of a full audit trail of participation will make a big difference in the ease of the review process. The ability to easily see who is impacted by changes will allow teams to proactively manage the effects of said changes.

    In response to the COVID-19 pandemic, and the number of companies who are maintaining their remote work policies, we can expect to see more innovations related to product development workflows. These innovations will enable easier remote collaboration between colleagues and across teams, overall streamlining the product development process.

  • What Developers Really Think About Pentesting

    What Developers Really Think About Pentesting

    A developer in their natural habitat is often spotted in a state of deep concentration, coding awesome features to tight deadlines. Feature-building is often our favorite part of the job, and really, it’s the fundamental outcome of the software development life cycle (SDLC). 

    However, as we have discussed before, many of us are still prioritizing features over security best practices. After all, in most organizations, it is set up to be someone else’s job and adequate security training for us is limited. Penetration testing and static analysis scanning tools (SAST) are just part of the overall process to mitigate security risks, operating rather independently from what we do — until the code bounces back to us for hotfixes, of course.

    It’s at that moment that many developers think, “Do the pentesters hate me?”

    These interactions often define a team and culture. The concerning thing is, the lack of communication, understanding and overall collaboration has created tension, at least on the side of the developer.

    Think about it: Imagine you’ve spent a few hundred hours sculpting a marvelous statue, and then someone comes along with a hammer and starts smashing bits off it after they’ve told you its foundations are not up to scratch. That’s the perceived dynamic between a tester and developer — the latter has their software darlings slaughtered by an outsider that hasn’t labored through the process with them; instead, they’ve extended the workload and delayed the satisfaction of shipping code. 

    Having moved into the security space long ago, I can see both sides of the story. And no, pentesters don’t hate developers. The pentester is in all likelihood, overworked and under a lot of pressure. As such, a constant stream of common security bugs that could be quite easily fixed at the code level take up time, resources and headspace away from the really serious issues. 

    I always saw pentesters as kind of like parents. They want you to do well, and when you don’t they’re not mad, just disappointed.

    Now that I’ve put that (perhaps slightly unfair) image in your mind, let’s explore this a little deeper. What has caused this world view among developers?

    Resentment for Being Told What to Do

    Nobody likes feeling as though they’ve done a bad job, or that someone doesn’t like their work. Sadly for developers, when static analysis and pentest results come back to them, it can feel like a report card. They’ve been given low grades, but at the end of the day, their bosses assess them on the features they’ve built and the time they’ve delivered them, not whether there were vulnerable elements in the software or not.

    For the poor pentester, this is a case of “don’t shoot the messenger.” It’s nothing personal — they are tasked with finding bugs, and they found them. Granted, at a person-to-person level, maybe some pentesters are grumpier than others, but they’re not (or shouldn’t be) out to crucify development teams. It would be far easier for both teams if they were on the same page with what constitutes security best practice. Developers are not expected to be perfect; realistically, the testing team is there to protect them from shipping vulnerable code.

    Minor Issues vs. Higher Priorities

    It’s true, a developer’s highest priority will always be the building of features, and in this crazy world of rapid digitization, it will have to be done at speed. While some coders have a personal interest in security and secure coding, the general sentiment is that security is “someone else’s problem,” which inevitably includes pentesters. 

    Most common vulnerabilities are indeed minor issues to remediate — once known, the fixes are simple to execute for things like cross-site scripting (XSS) and SQL injection. The problem is, many developers don’t realize they’re introducing them in the first place, and these seemingly minor issues are the small window of opportunity an attacker needs to cause devastating problems for a company. According to Akamai, between November 2017 and March 2019, SQL injection vulnerabilities accounted for 65% of all web-based attack vectors. For a vulnerability that has had a known fix for more than 20 years, that is a sobering statistic. 

    Some pentest teams do assist in the remediation of security bugs, but others will provide a report of the bad news and expect developers to work through hotfixes, even if they have moved onto a different project by the time this happens. And in some cases, the development team may be faced with a report that includes bugs they can’t (or shouldn’t be expected to) fix. It still has to be part of the findings, and again, not taken personally.

    The “happy medium” for this would be pentesters, security personnel and development managers acting in more of a mentor role to ensure the team has what they need in terms of effective training and tools, giving individual coders the best chance to succeed and code securely from the very beginning of the SDLC. Both teams really should be meeting half-way to ensure security is considered from the start, as part of a healthy DevSecOps practice. 

    Lack of Knowledge vs. False Positives

    Static analysis is an element of the security process in the SDLC, and static analysis scanning tools (SAST) play a fundamental role. And yes, false positives are an issue with these and other types (DAST/IAST) of scanners. It’s an annoyance in what is already a slow process, requiring manual code review and putting pressure on both developers and pentesters alike. Pentesting personnel have taken time to meticulously set up custom rules to avoid inaccurate readings and provided company-specific guidance, yet some false readings slip through and end up in front of a head-scratching developer. 

    This process isn’t perfect, but the other problem is that many developers lack enough knowledge to mitigate a lot of common vulnerabilities on a consistent basis. With security training rare in tertiary education, and on-the-job training varying in its effectiveness, it stands to reason that there may be some overconfidence at play as well (and it’s not their fault, we as an industry need to get better at equipping them with what they need).

    Remediation Tasks

    Sometimes, there is an assumption by overworked engineers that pentesters are just hanging in the wings, waiting for the moment to strike by testing an application and raining on the development team’s parade. They are over-testing, they’re nitpicking, they’re creating extra work. 

    The only problem with that is they, too, are overworked (more so, in fact, the cybersecurity skills shortage is at dire levels and getting worse) and simply don’t have the time to test without reason. They are not the sole decision-makers in prioritizing testing; it could have been requested by senior leadership, a customer, as part of a security audit or even determined as a result of a bug bounty program. 

    For a developer, being pulled off current feature-building sprints to work on security fixes is annoying — especially if it’s not their work. Perhaps a previous team did the last update, or another vendor. However, security is everyone’s problem. That doesn’t mean every developer has to take ownership of security bugs as though they have made them all themselves, but they do need to come to the party in terms of security being a shared responsibility. 

    Where to from Here?

    Sometimes, a mindset shift can be all it takes to make significant headway in solving a problem. We’ve talked about the rather frosty reaction a developer has to less than favorable pentest results, but what if they could turn it into a challenge? Perhaps they could think of the pentester as a friendly competitor; someone they can beat at their own game. After all, a security-aware developer that can eliminate common bugs as they write code is going to make their job much more difficult. By contrast, a developer with no focus on security is going to be comprehensively bested by their pentester counterparts when they can easily break their software. 

    Pentesters and developers may not be joined in harmony 100% of the time, but their relationship can be vastly improved when an organization addresses security as a key priority, and empowers teams with the right knowledge and tools to succeed — especially developers. It comes down to whether a company-wide, positive security culture is a priority, and if we are to fight the (currently) losing battle against common vulnerabilities, it absolutely should be.

  • Eclipse Foundation Moving to Brussels

    Eclipse Foundation Moving to Brussels

    The Eclipse Foundation announced today it will begin to transition its headquarters from Ottawa to Brussels as part of an effort to advance international expansion.

    Mike Milinkovich, executive director of the Eclipse Foundation, said with so many open source organizations based in North America, there is a clear need for an open source organization to have a larger presence in Europe. As nearly half of the strategic members that provide funding to the Eclipse Foundation are based in Europe, it made sense for the Eclipse Foundation to take on that role.

    The Eclipse Foundation is now home to 375 open source projects resulting in more than 240 million lines of code. Some of the most widely employed Eclipse Foundation projects include the Eclipse integrated development environment (IDE) and Jakarta, which is a follow-on to Java Enterprise Edition platform, previously owned by Oracle. In total, the Eclipse Foundation’s projects represent more than 13 billion Euros of investment.

    In general, Milinkovich said contributions to open source projects have accelerated in the wake of the COVID-19 pandemic. Developers who are staying home to help combat the epidemic apparently have more time to contribute to projects. The expectation is by moving to Brussels, more European developers will contribute to projects involving technologies such as internet of things (IoT) initiatives that address industrial use cases, he added.

    The Eclipse Foundation plans to establish a new legal entity sometime in July, with personnel relocating or added to a Brussels office over time depending on the nature of the Eclipse project being supported, Milinkovich said.

    It’s not clear to what impact being headquartered in Europe will have on open source projects, which are by their very nature global. However, Milinkovich noted most of the recent live events hosted by the Eclipse Foundation have been held in Europe. It may be a while before anyone is attending an IT conference in person, but Milinkovich noted European developers already play a major role in the Eclipse Foundation projects.

    Between the Eclipse Foundation, the Linux Foundation and the OpenStack Foundation, there is no shortage of opportunities for developers to contribute to open source projects. Many of those projects count on contributions from developers who work for IT vendors that have a vested interest in a specific project. In fact, many open source projects provide a way for IT vendors to defer the cost of creating a core piece of technology that doesn’t provide differentiated value. Rather than reinvent the wheel, it makes more economic sense to share open source code with potential rivals.

    Of course, it’s then up to each IT team to decide whether to employ that open source code themselves versus relying on an IT vendor to provide a curated instance of it under a support contract. Regardless, the total cost of IT would be prohibitively higher right now if it were not for the proliferation of open source software. It’s also worth noting many IT vendors that build platforms on top of open source software would be considerably less profitable.

  • Pulumi Tightens DevOps Platform Integration

    Pulumi Tightens DevOps Platform Integration

    Pulumi today released the 2.0 release of its open source platform for automating the provisioning of IT infrastructure in the cloud, providing tighter integration with a dozen different continuous integration/continuous delivery (CI/CD) platforms and source code management (SCM) systems. Via the latest update Pulumi also now includes CI/CD Apps, through which pull requests will trigger Pulumi previews and updates.

    In addition, Pulumi has added tools to preview changes, while making it easier to share architectural patterns, libraries and best practices.

    Finally, Pulumi 2.0 adds additional tools to enforce policies, simplify testing and manage secrets.

    Pulumi is designed to enable developers to provision cloud infrastructure using familiar programming tools such as Python, JavaScript, TypeScript, Go and .NET/C#. That approach eliminates the need to master YAML files or other proprietary languages and templates.

    Pulumi CEO Joe Duffy said the goal is to accelerate the rate at which management of IT is shifting left toward developers by providing them with the “superpowers” need to manage cloud infrastructure. Thus far, Pulumi claims to have more than 10,000 users of its tools.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, it is expected the rate at which control over IT has been shifting left will accelerate. As part of an effort to either contain or eliminate headcount, many organizations will reduce their reliance on IT operations staff by giving developers more direct control over IT infrastructure.

    At the same time, however, Duffy noted that many IT operations personnel are finding it relatively simple to master Python, which they can then use to leverage Pulumi to automate the provisioning of large amounts of cloud infrastructure to become more efficient. Some organizations may prefer to retain IT operations staff that have learned how to program.

    It remains to be seen to what degree tighter integration with CI/CD platforms might encourage developers to take more control over IT infrastructure. Support for the CI/CD platforms supported by Pulumi—Jenkins, Spinnaker and GitHub—will make it easier for developers to achieve that goal. Less clear is the degree to which developers want to take control over infrastructure. Regardless, many of them may soon have little choice in the matter.

    Of course, Pulumi is not the only framework via which the provisioning of cloud infrastructure can be automated. It does, however, make it easier for developers to provision infrastructure without having to spend time learning the nuances of another set of programming tools. Even in organizations that do shrink the size of their IT staffs, there will still be pressure on developers to deliver more code faster. The amount of time developers may want to allocate to managing IT infrastructure is likely to be limited at best.

    Whatever the path forward, many organizations will soon discover they can’t afford to wait any longer for their internal IT cultures to embrace best automation and DevOps practices. Economic pressure to optimize constrained IT resources are likely to become intense. No one may know for certain how long the downturn may last, but it is already apparent many organizations will be trying to do a lot more with less in the days ahead.

  • What the Best Developers Do to Be Great at Their Jobs

    What the Best Developers Do to Be Great at Their Jobs

    Good developers are in demand—great ones, even more so. With software development employment in the U.S. expected to grow by 21% by 2028, the need for engineers is only going to surge further.

    But this doesn’t mean that the labor landscape will become uncompetitive: Now more than ever, individuals with a passion for software are entering the field, and organizations will only be looking for the best. As the amount of people going into software development goes up—with global numbers expected to reach 27.7 million by 2023—it will become increasingly important to demonstrate your skills and dedication to the profession.

    The gap between a good developer and a great one is bigger than you may think. Here’s what the best developers do to excel at their jobs and lead in their field.

    The Best Software Developers Know How Their Skills Fit Into the Big Picture

    While a good coder handles the responsibilities they have within their role, the best coders make sure they see the big picture. They take the time to understand the foundations of how businesses work, including revenue, profit, bottlenecks and the strategies of departments other than their own. 

    This might mean investing extra time into general business self-education or holding meetings with other departments, but great programmers know it’s worth it in the long run. They recognize the importance of grasping how the cogs of an organization come together to keep things running—and exactly how they fit in.

    By having this 360 view, they can hold influence in areas outside their remit and clearly match the business’ mission to their own work. Valuable coders will use their problem-solving mindset to propose solutions to company-wide problems and put themselves in the shoes of other team members.

    Rest and Relaxation Is Vital for Productivity

    Far from the stereotype of frequently pulling caffeine-fueled all-nighters, the best developers know that, like the powerful systems they work with, they also need some downtime to recharge.

    Great coders challenge the stereotype of having a bad diet and inactive lifestyle and prioritize their own health and well-being. They recognize that as soon as you pass the threshold of 50 hours of work a week, you’re no longer productive. In fact, working too much can be counterproductive, as you’re much more likely to make mistakes.

    Great developers know when to shut down their computer and spend time with their families, do some exercise, spend time in nature and eat a healthy meal. This time to recharge is essential in order to go back to work refreshed and ready to tackle any problems with a clear and rested mind.

    Continuous Learning Is Crucial for Progression

    Ideally, all developers should be making efforts to advance their education in the field they’re in. As a developer, if you stop studying, you’re bound to get stuck at one point or another. The best coders make this a special focus in their lives, and make sure they’re always up to date with the latest developments in the technologies they work with.

    It could be a new coding language, new frameworks or a new technique. Great coders are constantly making a concerted effort to advance their own education. Ultimately, they are always asking “why,” and are unafraid to experiment using their newfound skill.

    Developers can easily find online courses to supplement formal education. Taking part in hackathons is another way to boost extra learning, as well as keeping up with technical blogs and podcasts.

    Great developers also follow other passions outside of coding. For example, the logical nature of software development allows coders to excel at learning other skills, such as languages, playing an instrument, martial arts or even flying a plane. It enables them to exercise the same part of their brain while enjoying something fun and non-work related.

    Personal Projects Show Dedication and Independent Thinking

    Coders know that the best way to learn how to build great products is through practice. Even if the project ultimately fails, building a product will always provide important lessons to apply the next time.

    Side projects that a developer might work on include personal tools, open-source libraries, a startup idea or a freelance project. These personal projects allow programmers to be in the driving seat: They are forced to solve problems independently instead of asking for help, equipping them with skills that might otherwise take longer to gain.

    Engaging in independent work also allows developers to explore and utilize the new languages and frameworks that they gain in their personal education efforts. When developers that have spent time working on their own projects try to prove themselves in the job market, they will stand out against those that have remained largely within the confines of their professional role.

    Ultimately, the vast majority of developers are in the game because they have a passion for building exciting and useful products. This makes it easier to find those who go the extra mile to really hone their existing skills and learn new ones. But, like in any profession, there will always be a certain percentage that remains a cut above the rest. Take a holistic approach to your career in software development with this advice and raise your game, and chances of landing that dream job.

    — Phil Alves

  • The Role of Soft Skills in Building Strong DevOps Leads

    The Role of Soft Skills in Building Strong DevOps Leads

    As an industry, we spend a lot of time talking about the process and technology that make up a good DevOps practice. We have a strong focus on the development, IT operations, QA” and security roles. We debate tools and automation strategies. We wax philosophical about DevOps culture.

    What is either lacking entirely or simply glossed over in that conversation is what I would consider the backbone of any good DevOps team–the people. 

    You might assume by “people” I mean their skills with the technology or their expertise with a certain process. Those two things are important, but all things being equal, the people aspect of DevOps I am referring to is really more simple–or even more basic–than that. It all starts with the culture that is defined by the lead.

    As with any cross-functional discipline, teamwork is essential to the adoption and success of your DevOps practice. At its core, DevOps is about collaboration among people from a variety of teams and departments. It brings together multiple disciplines, people and processes with the common goal of high quality and high efficiency output. DevOps relies so heavily on teamwork that without strong leadership, your DevOps culture and the success of your practice are destined for a rocky road at best.

    A strong DevOps leader will need to bring together people in roles that have either been traditionally siloed or are now being done by fewer people. This is no easy feat, however building trust, earning respect, communicating effectively and motivating everyone toward the common goal is paramount to the success of the DevOps team.

    These traits–trust and respect, communication and the ability to motivate–are not unique to DevOps leads, rather they are the key characteristics that make up any strong leader. By putting them in the context of DevOps, the importance of each in the process and culture is irrefutable. 

    Trust and Respect

    Paul Zak, the founding director of the Center for Neuroeconomics Studies and a professor of economics, psychology and management at Claremont University, led a study to better understand the neuroscience of trust. His team found that the effect of trust on work performance, engagement and loyalty were huge. Respondents indicated that employees with high trust had 106% more energy, were 76% more engaged and 88% said they would recommend their company as a place to work to family and friends. 

    The numbers might not come as a surprise, but how you achieve high trust might. First and foremost, be vulnerable. Do not be afraid to ask for help. This not only exhibits the trust you have in the people on the team, it also demonstrates the sign that you are secure in yourself as a leader. 

    The trust factor for a DevOps lead is multifaceted. The team must trust the lead enough to also trust his/her vision for the process. By showing vulnerability and leaning of the subject matter experts from each discipline for input, you start to build rapport with the team and the process becomes owned by the different functions involved. By asking for help, you invoke the natural tendency to cooperate. That cooperation leads to mutual trust. And by earning trust, you also earn their respect. 

    Communication

    As with any cross-functional team, communication should be viewed as critical an element as your DevOps tools. A successful DevOps lead will be able to understand and speak the languages unique to each discipline. By understanding the nuance and meanings of the words used by the IT operations teams, QA, security and development, the lead can easily help communicate goals, set expectations and establish rules of engagement. Through daily communication, the team will be able to reduce friction and become far more effective as a group. 

    Motivating Toward a Common Goal

    Former Boston Bruins coach Harry Sinden said it best, “Putting on the same jersey doesn’t make a team. You’re still a collection of individuals until you find a common goal.”

    The DevOps lead who motivates the team toward that common goal will find success. But how do you do that? To find out what motivates the people on your team you need to talk to them and get to know them. Involve them in developing the overall strategy. Seek their input and make sure they feel they have ownership of the outcome. 

    Set milestones and celebrate accomplishments. Reward success. Provide feedback and coaching in the moment–both good and bad. 

    The team that feels like they are part of something are no longer a collection of individuals.

    In the end, when you are assessing your DevOps practice and culture, make sure you take a long hard look at the people. They are truly the backbone of any DevOps practice. The need to technical prowess and experience should not be underscored, however, make sure you look for someone who has those skills plus all of the necessary attributes of a true leader. The success of your DevOps practice may depend on it.

    — Sara Faatz

  • How to Overcome Resistance to DevOps Implementation

    How to Overcome Resistance to DevOps Implementation

    The number of businesses adopting DevOps to make software releases happen faster without compromising on software quality continues to grow. Within the next five years, the DevOps market is expected to reach almost $13 billion. If you are among those who’ve decided to make a shift to DevOps, you are likely to experience resistance coming from the departments involved in a software development life cycle (SDLC), and even from end users, at the start of your DevOps journey.

    In this article, we will outline the reasons why your employees may resist the DevOps approach and show how to overcome their resistance.

    About DevOps Approach Implementation

    Among the benefits DevOps brings are the fast provision of new infrastructure, quick and reliable delivery of software updates, fewer post-release errors due to the implementation of continuous testing and the alignment of testing and production environments, etc. DevOps implementation requires efforts in establishing tight collaboration between the development, QA and operations teams, as well as adopting new tools and methodologies, such as containerization, IT infrastructure automation, continuous integration and continuous delivery (CI/CD) tools.

    A new approach calls for project managers, developers, infrastructure management, QA and operations teams to leave their comfort zones and get used to new working conditions. However, each stakeholder has reasons to resist DevOps implementation and requires a tailored approach to overcome them.

    The Resistance of Project Managers

    Why They May Resist

    Project managers (PMs) are the first to face the changes when the DevOps approach comes into force. Their resistance originates from a range of new duties, new responsibility and knowledge they need to add to their playbook, such as:

    • Persuading development, QA and operations teams involved in SDLC in the DevOps necessity.
    • Establishing constant collaboration between developers, the QA team and the operations team.
    • Getting familiar with DevOps-specific tools and techniques (CI/CD, continuous monitoring, version control tools, etc.) as well as cloud computing technologies like AWS, Azure, Google Cloud Provider (GCP).

    How to Overcome Resistance

    PMs should become DevOps evangelists as they will be the ones who will contribute the most to overcome the resistance of other parties involved. A CIO should provide a PM with sufficient training on all DevOps-related aspects. Such training should include the management of the development, the QA team and the operations team in the context of close collaboration between them. It should also provide the PM with the understanding of DevOps methodologies and tools–containerization, infrastructure as code (IaC), continuous integration and continuous delivery (CI/CD), cloud technologies, etc.

    The Resistance of Developers

    Why They May Resist

    Developers may resist DevOps adoption due to the following reasons:

    • They are not excited by the necessity to work with infrastructure engineers closer and deal with operational issues if the operations team is not competent enough to address them on their own.
    • They are comfortable with the technology stack they’ve chosen for a particular project and not accustomed to caring about how familiar the other project team members are with these tools and technologies.

    How to Overcome Resistance

    PMs should embrace their soft skills to establish a mutual understanding between developers and infrastructure engineers. They should also make sure infrastructure engineers can work with the tools and technologies developers may use within the DevOps approach, e.g., Docker, Jenkins, by providing them with relevant training.

    The Resistance of a QA Team

    Why They May Resist

    A QA team may feel concerned about a faster SDLC DevOps implementation, since it entails less time for testing. Test engineers now need to acquire new skills prescribed by automation across the entire SDLC. In particular, they face the need to learn new tools for automated testing (Selenium, Appium, fMBT) and API testing (JMeter, Postman).

    How to Overcome Resistance

    To make QA engineers less risk-averse, QA managers in cooperation with PMs, should provide them with appropriate training (tools for automated testing and API testing) and show the advantages DevOps may bring. An opportunity to increase test engineers’ qualification level, less effort on testing activities than required with manual testing are among such benefits.

    The Resistance of an Infrastructure Department Manager

    Why They May Resist

    In the pre-DevOps times, an infrastructure department manager was responsible for controlling the design, configuration and delivery of infrastructure for development, testing and production. With DevOps on board and the IaC approach implemented, the infrastructure manager may feel as if they lose control over the IT infrastructure provisioning and management. What’s more, the scope of the infrastructure manager’s responsibilities extends greatly since they’ll need to run the infrastructure department as a competency center.

    How to Overcome Resistance

    A company’s CIO should explain the infrastructure manager their new responsibilities upfront. The infrastructure manager should stay assured that they change the area of control, not lose it. Within DevOps, the infrastructure department manager has to transform their approach to work. They must be able to help a PM correctly arrange the development, QA and operations team for each particular project taking into account project complexity and size. The infrastructure manager must be able to proactively deal with the cases when the team members involved in software development lack qualification for a project, and not wait until the lack in teams’ competencies results in the project prolongation, for example.

    The Resistance of Operations Engineers

    Why They May Resist

    With DevOps in place, the operations team will have to coordinate their efforts with developers and the QA team from the very beginning of the project, as well as regularly report to the PM on the tasks completed, which is not the usual work approach. To be able to work in the DevOps environment, operations engineers will also have to get familiar with a range of IT automation, version control and other tools. What’s more, the operations staff’s responsibilities will now include the provision of the information on the IT infrastructure functioning to business and technical stakeholders.

    How to Overcome Resistance

    To help an operations team adapt to the DevOps culture, the infrastructure department manager should deliver training to make operations engineers familiar with new tools and technologies they will need to use, e.g., version control systems (Git, Team Foundation Server), software deployment automation tools (Chef, Puppet), etc. A PM, in their turn, will need their soft skills to increase the operations team’s willingness to work in close alignment with development and QA teams.

    The Resistance of End Users

    Why They May Resist

    It may sound surprising, but even the primary beneficiaries of the DevOps approach implementation may resist the changes DevOps brings. There are two reasons for it:

    • The time available for software acceptance testing gets reduced due to a faster SDLC.
    • Acceptance testing becomes automated, and end users hardly trust automated tests.

    How to Overcome Resistance

    To dispel end users’ DevOps-related doubts, PMs must do their best to earn their trust by establishing strong communication with end users. If, for example, end users know software testing covers critical software functionality and the probability of post-release errors is minimized, their confidence in software reliability and the overall trust in the DevOps approach rises.

    In a Nutshell

    Each party involved in software development has its reasons to be suspicious when the DevOps approach is coming on board. New duties, close collaboration, the necessity to apply new tools and other DevOps-related changes may make project managers, developers, QA engineers, IT infrastructure managers, an operations team and even end users resist the new approach.

    To overcome the resistance, a company’s CIO should maintain open communication with each party involved in SDLC, explain their new duties and listen to their concerns. It’s essential to make sure each team member realizes what changes and advantages DevOps brings into SDLC. To ensure they have the necessary knowledge and skills, appropriate training should be provided to project managers, developers, QA team, IT infrastructure manager and the operations team.

    — Andrei Lipnitski