devopsy.kinsta.cloud

Tag: developers

What Children Can Teach Us About Coding

Redgate’s Code Club for kids ended up teaching their parents to love coding again

Like lots of people in IT and other office-based jobs, I’ve been working from home since the pandemic started to hit in March 2020. In some ways it’s been hard because I’m the technical lead on a software engineering team, and continuing to work in an agile, collaborative way can be difficult via Zoom. In other ways, it’s been interesting because we’ve demonstrated it can work, often remarkably well.

But I’m not just a technical lead, I’m also a father. And for my 8-year-old son, Dougie, things have been tougher. Here in the UK, schools were forced to close for a long time and one of the things he really missed was the lunchtime Code Club classes he’d been taking. Run by teachers, parents and volunteers and supported by Code Club UK, part of the Raspberry Pi Foundation, Code Club is a great initiative to help children to code with a range of really well-planned and thought-out projects.

So naturally, being a software engineer myself, I thought, How hard would it be to organize an online code club for the children of people at Redgate Software? I mentioned it to a few people at work and when someone suggested maybe we should see if parents beyond Redgate would be interested, I thought, No problem at all. Redgate has quite a few followers on Twitter, so we put out a tweet.

What could possibly go wrong?

Panic Stations

What started as an idea to help maybe 10 or so children of the people at Redgate went crazy. By the next morning we had 1,000 sign-ups from kids from all over the world. Not just the U.S. and Europe, but India, Nigeria and Sri Lanka as well. And the sign-ups kept coming in by the hundreds.

Fortunately, the Raspberry Pi Foundation had already done a lot of the hard work for us by creating a series of Code Club class projects for beginners, intermediate and more advanced coders. They were delighted at our suggestion of using them in our online classes, and recording them so that they could be watched later as well.

Redgate also actively encourages staff to give back to the community and when I gave a shout-out for volunteers to help run the classes, there was a huge response with 50 people raising their hands. Within a couple of weeks, we had the sessions planned, with the beginner and intermediate ones using Scratch and a more advanced session learning Python.

There was quite a lot of safeguarding we had to think about as well around talking to other people’s children over Zoom, and we had conversations with the director of Code Club UK and her team to get their input. We wanted to make sure people weren’t sharing their videos and sound and that kind of stuff, but we managed to work our way through it and ensure we were protecting children while sharing some really cool stuff with them.

All Systems Go

On Friday, April 3, Redgate’s Kids Coding Club opened its doors online to hundreds of children aged between 6 and 14, as well as their parents. I wanted the kids themselves to run the sessions for other kids, so they were the presenters and their parents were co-presenters. In the sessions hosted by my son Dougie, he would talk about what we were going to do in the session and explain what things like sprites are. We then worked through the module as a group and if anyone got stuck, they could raise their hands virtually using the Zoom tool and a volunteer would step in to help.

We ended up running six coding club sessions every Friday for 17 weeks while schools were closed. During that time, we taught nearly 800 children from 20 countries how to code, delivered 1,572 hours of learning, and recordings of the classes on YouTube have racked up thousands more views.

What We Learned

What I love about the coding club is that while we were delivering learning, we were learning, too. There were three big lessons for me.

Children love to code

A lot of people think children just want to sit down and play Minecraft or Fortnite, but if you give them the right tools, they absolutely love coding. Scratch, for example, is a block-based visual programming language that’s really easy for children to pick up and start coding with, particularly when you give them fun stuff to do.

Sixty percent of the children we taught were between the ages of 6 and 8 and they loved using Scratch on projects such as Rock Band, Cats, Clone Wars and Boat Race. They coded their own musical instruments, stopped cats falling into holes, saved the Earth from space monsters and navigated a boat to an island. What’s not to love?

Parents love coding, too

Around 40% of the kids who signed up had parents who had never done any programming either, so they were both starting together in front of the computer, which was great. Typical feedback from the parents was that they were surprised that beginning to code isn’t hard, it’s really fun. A lot of them sat with their children for an hour after the lesson and continued to just play about with things and change stuff.

Children can help us be better at coding

There’s this preconception with coding that you have to get it exactly right for it to work, but what’s great about Scratch and other tools is how much freedom the kids had to change the project they were working on. They’d rather use a parrot than a polar bear. They didn’t want it to jump 10 pixels high, but a hundred pixels high. What happened if they asked it to jump minus 10 pixels? They could just poke the thing and play with it, and it was fun to see the little light bulbs going on in the face of the kids—and their parents.

That can teach us about coding, too, because we often go down tramlines and do things the same way, every time, even when we say we’re taking a test-driven development approach to coding. Teaching children how to code was a nice reminder that we should be thinking more like them, poking and pushing things to the limit and doing the unexpected. We’ll end up with better code, and we’ll have more fun, too.

November 25, 2020
Two-Part Training Required for Developers to Slay the Security Beast

Developers’ defensive qualities are only as good as the training they receive

The playing field between the heroes and villains in cybersecurity is notoriously unfair. Sensitive data is the new gold, and attackers adapt quickly to circumvent defenses, exploiting security bugs large and small for potential paydirt.

The volume of code being produced is too great for security experts—who are becoming increasingly scarce—to contend with, and the rising cost of data breaches is proof that something has got to give. Fortunately, for the sake of our digital safety and the sanity of CISOs everywhere, the DevSecOps movement is helping to bring developers on the security journey from the beginning of the software development process. They are being recognized as the first line of defense against cyberattackers, with the power to eliminate common vulnerabilities at their fingertips.

However, their defensive capabilities are only as good as the training they receive, and that is yet another gauntlet for security teams to run. For many developers receiving on-the-job training in secure coding, their key challenge is staying awake during mind-numbing, hands-off activities that are neither effective nor inspiring them to keep security front of mind. Soulless video courses aren’t getting us there, token annual ‘tick-the-box’ events are a waste of time, and nobody is winning against the potential malicious threat actor waiting to jump on a small window of opportunity.

At this stage in our industry, we have worked out that contextual, hands-on education that is delivered in relevant programming languages and frameworks, with challenges that mimic those a developer might come across in the real world, is a far more engaging approach.

This is phase one of a developer’s quest to help AppSec gurus slay common vulnerabilities, but phase two is where scenarios must get real for a supercharged, security-aware defensive force.

Scaffolded Learning Is Critical in Adult Education

When it comes to extracurricular courses or on-the-job training, it is often overlooked that adults bring with them a certain level of experience and existing knowledge. Good training adds to this foundation and is structured in a way that allows for deeper understanding and faster autonomy in the learning process.

Scaffolded education is a potent, positive method of learning that seeks to activate and enhance prior experience while continuing to build new skills—in manageable chunks—that allow the learner to tackle increasingly difficult tasks with more confidence. Typically, it is a methodology best served with healthy portions of demonstration, visual aids and student-led exploration.

If we tie this approach back to developer security training, it comes as no surprise that the dynamic, learn-by-doing method has long been preferred over the drudgery that is theory-based static learning. They are free to be the masters of their domain and should see that their time is being well-spent.

In that sense, learning to code securely in a hyper-relevant, contextual environment is key, but the ‘level up’ from this step is to see an exploit of vulnerable code in action. With the context of front-end and back-end views side-by-side, there is a tangible link between actions taken during the coding process and what an attacker can potentially do with cut corners, misconfigurations or accidents that are not caught and remedied.

Move From Recall to Application for a Truly Preventative Security Approach

Experiencing the impact of security vulnerabilities firsthand is a vital piece of the education puzzle, and it’s a fairly rare beast, even with the most modern security training options for developers. The foundational work spent on honing skills in spotting and remediating vulnerabilities and recalling that experience to eliminate the same bugs in code as it is being written is extremely important, but it’s not the whole picture. Seeing how vulnerable code is exploited by a malicious actor adds a powerful layer of context, one that really drives home the importance of securing code and applying hard-earned security knowledge to close every window of opportunity.

It is generally accepted that developers don’t love security, and they have even less affection for security training. Their experiences with AppSec specialists can be very frosty, and the rework caused by the security team bouncing vulnerable code back to developers for remediation is the bane of their existence. To an engineering team that is already spread thin, security is someone else’s problem, not their priority, and a hindrance to their natural creativity and primary objective of building features. However, there is simply too much code, too many breaches and too much risk to the world’s data for this mindset to continue.

A functional DevSecOps process has developers working in harmony with security teams right at the beginning of the software delivery life cycle (SDLC). Likewise, the opportunity for applied learning, where they can interact with a simulated exploit and see the impact of poorly secured code, goes a long way in getting developers on the same page as those pesky AppSec people (who aren’t so bad after all).

Interactive Learning Prepares Developers for the Boss Fight

At the time of writing, there were two major breaches reported in a seven-day period: Razer announced that more than 100,000 sensitive data records had been exposed, while office supplies retailer Staples also reported a similar data leak. More than a billion sensitive records have been exposed so far in 2020, and this worrying trend shows no signs of slowing down. Simply put, malicious actors have the upper hand and security-aware developers are sorely needed to serve as the front line of defense.

Interactive challenges that focus on simulating such breaches move developers from passive recall, to applying skills that have an impact on the real boss fight: stopping attackers in their tracks.

November 13, 2020
Survey Sees Long DevSecOps Ahead

A survey of 250 developers working at leading technology companies paints a bleak picture of the current state of application security with 85% admitting applications on average have 10 or more vulnerabilities, with nearly half saying they have on average more than 20 per application.

Conducted by Contrast Security, a provider of an observability platform for security, the survey also finds nearly 50% of application security tools are not integrated into the continuous integration/continuous delivery (CI/CD) pipelines.

Contrast Security CTO Jeff Williams said it’s clear most organizations have a long way to go before best DevSecOps practices become commonplace. In the meantime, the level of disruption being caused by the need to remediate vulnerabilities remains high. The survey finds 88% of respondents need to stop development work to remediate vulnerabilities at least once a week, with nearly 80% spending too much time triaging and diagnosing application security alerts.

Nearly three-quarters of respondents also noted their organizations cannot find highly specialized application security experts.

On the plus side, more than one-third of respondents (36%) said at least one application security metric is among their top four performance measurements. Most (63%) have also deployed an interactive application security testing (IAST) solution.

Most importantly, 77% of respondents said they want more application security training.

Williams said ultimately DevSecOps will require an observability platform capable of capturing metrics that are meaningful to developers. Contrast has launched an observability platform for IT security teams that borrows DevOps principles to streamline the management of cybersecurity.

Achieving and maintaining security is complex because application data flows in and out of disparate systems running in the cloud and on-premises IT environments. IT security teams are forced to navigate a multitude of application programming interfaces (APIs) that have varying degrees of dependencies to ascertain what’s actually occurring in their extended IT environments.

Contrast enables DevOps teams to instrument their applications with security sensors, which Williams said enables the Contrast Application Security Platform to aggregate data flows spanning multiple applications. That approach also eliminates silos spanning application security testing (AST), software composition analysis (SCA) and runtime application self-protection (RASP) tools installed across an enterprise, said Williams.

It’s not clear to what degree DevOps teams will add agents specifically to instrument applications to gather security data. However, as more responsibility for application security is shifted left toward developers, it’s apparent legacy approaches to securing applications are being found wanting.

In the meantime, it’s still early days as far as DevSecOps is concerned even for technology companies, much less the average enterprise. Most IT organizations are just getting started down this path. The issue most of them are coming to terms with is the degree to which they need their DevOps and cybersecurity teams to collaborate. While there may be a need for a lot of interaction between these two teams early on, there may come a day soon when DevOps teams eventually reach a level of proficiency that makes security a natural extension of any quality assurance process.

November 9, 2020
Survey Sees Faster Shift to Open Source Software

A survey of 638 IT professionals finds the economic downturn brought on by the COVID-19 pandemic is, like other slumps, driving increased adoption of open source software.

Conducted by Tidelift, a provider of commercial support and maintenance for open source projects, the survey finds 44% of respondents reporting their organizations are now more likely to use more open source. The survey also finds 42% of organizations have cut their application development budgets this year, with only 10% seeing an increase.

More than two-thirds said saving time and money is the top reason to use more open source for application development during the downturn (68%) while increasing efficiency of application development and maintenance was cited by almost half of respondents (48%).

However, reliance on open source software comes at a cost. The top two open source challenges cited are making good decisions about which components and versions to employ and making good decisions about when to upgrade components and frameworks, at 62% each. The third top challenge is identifying security vulnerabilities (49%).

Only a small fraction (18%) of organizations are extremely confident that their open source components are secure, up-to-date and well-maintained, and slightly fewer (17%) have a formal process for managing open source.

Tidelift CEO Donald Fischer said the current downturn is not all that much from previous economic slumps that lead to many organizations adopting an “open source first” approach to software. The challenge is many of those organizations don’t always appreciate the total cost of employing open source software. With each new open source project that gets added to the enterprise IT portfolio, the need to rely on external support services becomes more pressing, he said.

One thing that has changed over the years is more end user organizations are contributing to open source projects, with 83% of respondents reporting their organization contributes to open source projects. Almost half (49%) of organizations now have policies governing employee contributions to open source.

While many organizations initially view open source software as a way to reduce costs the days when the open source community was primarily focused on providing free alternatives to commercial operating systems and databases are long over. Innovations today are most often driven by open source consortiums such as the Linux Foundation, the Eclipse Foundation, the Apache Software Foundation and the Open Infrastructure Foundation, formerly known as the OpenStack Foundation. The rate at which software can be developed by teams of contributors working on an open source project makes it difficult for an IT vendor working on a single project to keep pace.

There will, of course, always be some form of commercial software consumed by enterprise IT organizations. However, the percentage of open source software continues to rise with each passing year. The latest economic downturn is only accelerating a trend that was occurring long before the COVID-19 pandemic arrived. The challenge now is finding the best way to manage all that open source software at a time when IT environments are also becoming more complex.

November 3, 2020
Engaging Developers in a Post-COVID-19 World

The time for platforms to rethink how they engage developers is now

How we communicate, socialize, look up information, work, shop and travel have all been transformed by platform companies. COVID-19 has only increased our reliance on these platforms, as people spend more time on the internet and businesses migrate from offline to online offerings.

These shifts present challenges to the platforms themselves. With people increasingly using low-latency applications such as teleconferencing and video streaming, there’s much more demand for data to be delivered without noticeable delays. As more and more varied businesses migrate their services online, it creates additional burdens on platform infrastructure and stretches the limits of their functionality.

It’s a challenging environment for platform companies. But disruption also presents opportunities. The question becomes, “What do platform companies need to do to remain relevant and to improve their products and services?“

The Importance of Developers

There are some obvious starting points. Platform companies will need to rapidly adapt their offerings according to their evolving user base. They’ll also need to plan for commercial sustainability and make sure that they balance short-term expenditure with longer-term profitability.

But they will not be able to do these things alone. With almost 24 million developers in the world today, external developers are central to any platform’s effort to adapt their products and expand commercial sustainability. As the technology industry continues to be subject to disruption, the developer ecosystem is ideally placed to drive expansion at a sustainable scale, enable product differentiation, reduce time-to-market and ensure relevance through product-driven growth.

Those platforms that can successfully engage developers will stand out from the crowd and win the increasingly competitive fight for developer loyalty. Similarly, as developer ecosystems increasingly become a key differentiator, the platforms that fail to engage developers may also fail to keep up with the rapidly changing technology landscape.

Developing Developer Partnerships

It’s clear that platforms will need to make engaging developers a priority moving forward. The question is, how?

For a start, organizations need to have a clear sense of which parts of their ecosystem can be opened up quickly and which integrations need to be built into the platform. With these established, the next step is to engage the developers that are best placed to help.

At the core of engaging developers successfully is the recognition that different developers will have different priorities, needs and core skillsets. All developers need to secure ROI by engaging with the platform and its ecosystem. But their perception of value will differ. Enterprise developers, for example, rate ease of use, peer perception, strong developer tools, accurate content and enterprise-level support. Independent software vendors (ISVs), however, care most about revenue, lead generation and being pulled into deals.

Segmentation, Segmentation, Segmentation

Investing in areas that will attract the right developers is key to long-term sustainability. And there are a few key areas that will require especially close attention. First and foremost, developer segmentation will be absolutely vital for every platform. As the product landscape expands, platforms need to be clear which new developers may want to engage with their platform.

By revisiting developer segmentation, new product use-cases can be included to ensure that content, support and messaging match what developers need. For example, if low-code/no-code developers are a new demographic, platforms need to extend content the scope of their help materials to include more basic explanations (including generic technology terms) and extra links to FAQs.

On the other end, platforms also will need to invest in tools that match the needs of different developer groups. Experienced, full-stack developers using the latest languages and patterns will expect sophisticated tooling, services and frameworks as well as DevOps tools.

Either way, continued focus on self-service will ensure cost-effectiveness by allowing platforms to manage extra usage without the need to apply extra resources.

Scaling New Heights With the Cloud

If transitioning critical services to the cloud isn’t already on the agenda for every platform business, it should be. A seamless service transition to cloud, with future-proofed expansion capabilities, is imperative for any platform that wants to engage developers. Why? Because as well as supporting service-based pricing, transitioning to the cloud facilitates scale and allows developers to access the platform securely from any location. Above anything else, a robust cloud infrastructure makes platforms more flexible, facilitates collaboration between platforms and developers and enhances the platform’s overall performance.

Thriving With Developers in a Post-COVID World

The time for platforms to rethink how they engage developers is now. Building a developer ecosystem will be vital for any platform wanting to scale at speed. If equipped with powerful tools, enabled through self-service and supported through effective educational resources, developers can be the difference between platforms that struggle in a post-COVID-19 world and those that thrive.

November 3, 2020
How to Secure Fintech Applications and Protect Customer Data
All industries are feeling the pain of preventing rising risks to their applications, private information and customers’ data, and it is not surprising that this is especially true in the financial services sector. In fact, fintech companies on average spent more than $18 million in 2019 battling cybercrime, while other markets’ companies spend an average of $13 million addressing cybersecurity concerns each year.

While these numbers can be depressing, a recent virtual roundtable we hosted with some of the best AppSec brains in fintech uncovered three steps organizations can take to secure their fintech applications and protect their customer data. The panel included Erick Lee, director of Security at Intuit; Jeremiah Kung, first vice president and global head of digital cybersecurity at East West Bank; and Karthik Rangarajan, security lead at Robinhood.

The panel discussed AppSec trends, best practices for what is working in their organizations and recommendations for security leader peers who are tasked with addressing application security at their organizations. The group agreed that there’s a lot of creative thinking and exciting work happening around AppSec, and that includes across all of DevOps and engineering, not just those charged with application security. These notions can’t help but leave one feeling optimistic.

While the spirited discussion covered a variety of topics and trends, here are the three high-level recommendations organizations should follow to best secure their fintech applications.
1. 1. Make sure AppSec teams are hiring software engineers. The panelists agreed that security and engineering functions should not operate as separate entities. One participant described why he hires software engineers instead of security engineers. He explained that software engineers know how to create fixes and operate at scale, which is critical for his organization, which manages 1.5 million requests per second. Since many organizations do not have the resources to hire a security engineer, particularly smaller and growing groups, it is especially important to build security into the engineering team.Organizations tend to discover scalable methods of solving problems and accelerating the development process when engineers are engaged with security. Take for example a security concern that delayed an application release. The panelists agreed that unless the issue is a show stopper, security should not delay a release, unless of course there is a compliance concern or potential violation. They recommended for developers do their thing, and let security work hard and try to keep up.
    The panelists explained this is because companies need to keep pace and release products and triage at scale. This is especially true in the fintech space, where winning business is about application features and capabilities. As an example, one panelist illustrated how his company’s focus is trying to ensure developers have paved roads so they can get “speed to benefit to customers.”
    
    To make this happen, his company deployed tools for automation, such as solutions that scan GitHub code for potential issues. They are also leveraging automation to monitor for security problems all through production. The punch line for them is to make security complementary and seamlessly woven into the workflow, it cannot be a secondary process slowing development.
    
    Compliance should be approached as an engineering problem. A significant challenge for financial services companies and fintech continues to be adhering to governance and compliance requirements. One of the reasons is a lack of automation and solutions that scale, which come at significant costs. In fact, one-third of global financial services companies spend more than 5% of their budget just on addressing compliance.Many financial services organizations rely on spreadsheets, PDFs, paper files and email chains to address and prove compliance. Fintech companies continue to address compliance questions using paper documentation and manual work. These methods are clearly not scalable and not sustainable for growing organizations to meet their expanding compliance demands.
    Fortunately, as the panelists uncovered, compliance and governance can be viewed through an engineering lens, as they have seen happen at some of the best fintech companies. One panelist illustrated that at his company he met with compliance experts to learn precisely about their problems, so his team could engineer solutions. After discovering the issues and metrics needed to prove compliance effectiveness, his team introduced automation and new tools to address the issues. His company knows the compliance methods are working if the metrics are being met, he said.
    
    Another panelist added that meeting regulatory compliance within a global organization like his introduces additional challenges of meeting compliance requirements in multiple jurisdictions. But the need to understand where data is and how it is being kept safe is common across the board. If you can address those questions, he said, then proving that the data is safe becomes the main task.
    
    For development and application security to remain sustainable, compliance cannot remain manual and human based. The panelists agreed that it’s unlikely to be able to fully automate all of the reporting and processes needed, but with a goal of 80% automation and 20% manual methods, organizations will be in a much better position.
    
    Security must be proactive. This is a common theme in our industry these days, and it certainly was popular thought the entire roundtable discussion. The panelists highlighted that fintech engineering teams are thinking about compliance and security in a variety of proactive ways. One panelist recalled that he asks his teams to “lean into security and do right by the customer before the company is asked to do so.”
  The areas addressed throughout the discussion ranged to a variety of topics, including how these days security is kept top of mind for engineering leaders during the hiring process. Participants agreed that hiring an AppSec developer is like finding a unicorn. The trick they said is to be more proactive and nurture your own unicorns internally. This can be accomplished by focusing on hiring top security developers and growing them into security roles. The result has significant benefits on all sides. The company will build its AppSec resources and expertise, and employees can value the opportunity to grow and expand their experiences into new areas they may not have known before.
  
  The panelists highlighted that exploring ways to ensure and accelerate approval for security features is a good way to ensure proactive security. One approach is to connect compliance issues that need addressing with security advancements. For example, if the goal to help prevent customer data loss is to add two-factor authentication, one should link a compliance issue that can also be solved by the requested security solution. Decision-makers may look to save budget and pass on simply adding security features, but it will be more difficult to say no to a compliance request. This kind of creative strategic thinking has a way of being a win-win for the company as well as its customers.
  
  The success of AppSec among financial services organizations depends on more than just effective security protocols that secure companies and protect customers. It needs creative, innovative and strategic ideas to enable organizations to have efficient, economical and scalable security. If that sounds like something your organization is seeking, then according to our roundtable panelists our industry has a very bright future.
November 2, 2020
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

October 28, 2020
Help Developers Thrive by Finding the Right Platform
If our developers have what they need to create the best possible applications, they—and our customers—benefit

Goji Investments was founded on the principle of democratizing access to real estate, business lending, renewables and other alternative investments. The idea is to allow financial service organizations to provide traditionally unavailable investment opportunities to private investors on a global scale. A critical component of the Goji plan for success is the investment platform. Not only do we make the application available as a white-label solution, it can easily integrate into other platforms via APIs. We wanted to create a modular platform that we could update in pieces when needed and easily scale up as clients came online.

High-Performance Development Teams

A major reason for Goji Investments‘ success in these first few years is our high-performance development organization, which is instrumental in building and delivering the vision of the investment products needed to generate new business. As we’ve moved from simply building our applications into making them more scalable, we’ve focused on getting the right tools in place for Ops and Dev. Of course, bonus—it makes developers happier if they have cool tools to use.

One of the things we try to do is keep our application/platform deployment process as agile as the applications themselves—constantly looking to improve and making updates whenever necessary, whether needed to deploy new technologies and applications or based on feedback from the team. The idea is to keep our DevOps pipeline operating smoothly and efficiently.

One of our key operational strategies is that if we make our developers happy at work, they will deliver better quality applications, which results in happier end users. Of course, developers like to create to come up with innovative ways to deliver great features. One roadblock to coding innovation is performing repetitive low-level tasks, so we’ve actually gone out of our way to automate whatever we can and free up Dev resources for more value-specific application development.

Automating Deployments is a Start, but Just a Start

We automate the deployment process through GitHub. Each developer pushes their own services into GitHub themselves, where it goes through a quick review process. After review (if it passes), it’s merged into the master. Any master merge triggers build pipeline execution (which is using ThoughtWorks GoCD), and this automation includes several rounds of testing: unit test and integration test followed by an automated acceptance test. Developers have the option of executing additional tests themselves when desired.

Any new master is promoted into pre-prod, which mirrors production. When changes are finally rolled into production, we use HashiCorp Nomad’s blue-green deployment capabilities—if a problem were to occur (which means it was missed in official testing), Nomad takes care of any rollback needs.

The stack is fairly straightforward: The applications are written in Java and run on a DropWizard framework in containers. Nomad is our orchestration platform. One of our foundational principles when selecting application and infrastructure technologies is the ability to automate our deployment processes. We’ve done a fairly good job of automating anything we possibly could, but automating monitoring was more difficult. Our traditional APM tool was fine for alerting us to issues such as an EC2 crash or a resource availability issue for a reboot, but if we wanted to actually troubleshoot the issue we essentially just had to examine logs and hope we could see something out of the ordinary.

As much as everyone is excited about writing data into logs, combing through those logs to troubleshoot application issues is a waste of time and valuable developer resources. After all, operating 20 different microservices that cover everything from taxes and payments to customer notification required optimization of each element of the DevOps pipelines. The last piece we added was performance monitoring.

The Value of End-to-End Distributed Tracing

There’s a great line from Jurassic Park: “T-Rex doesn’t want to be fed. T-Rex wants to hunt.” Well, developers don’t want to be analyzing log files; they want to code. In fact, they want to be creating the next great feature. To get our dev team out of the weeds, we began thinking about a different way to get—and analyze—application performance data.

We wanted a system that added observability, monitored performance, managed service levels and included visibility from our end user requests all the way into our back-end systems. Oh yeah, we also wanted all of that to happen automatically so that our developers never had to worry about anything other than their own features. Installation, agent setup, discovery, mapping, alert configuration and reporting—as much as possible without requiring human setup.

We knew tracing was critical—so much so that we avoided missing any problems by specifying a 100% solution, wanting a complete trace of every request to the application.

Troubleshooting Application Performance Problems

The real reason you buy application monitoring software is to solve problems, so optimizing our ability to find bottlenecks and eliminate them is a key component of our monitoring solution. First, like the other aspects of monitoring, we didn’t want to have to spend time configuring thresholds for warning and danger alerts. Our need was for automatic anomaly detection with event analysis. Every little bit helps keep our dev team focused on dev, not analyzing data—especially in logs.

Of course, sometimes, you can’t help it; you have to look at log data, but we wanted to be smarter about that, too. We wanted our application monitoring tool to automatically integrate log analysis tools so that all data could be analyzed at the appropriate level whenever needed.

Don’t Forget Testing

Sometimes, testing gets lost in the value of a good monitoring solution. While we weren’t necessarily looking for a testing tool, we knew if a monitoring solution could also operate effectively in test (that’s not just the ability to run in test; rather, I mean the ability to add value in the testing process), well, so much the better.

It turns out that our applications are quite complex, and that complexity can create lengthier test cycles—commonly in this scenario:

We recently released a new feature for distributing dividends. As you can imagine, this is a fairly important feature, so we wanted to ensure that it operated as desired and expected. We were especially concerned with being able to scale the feature appropriately. We set up a stress scalability test that took 20+ hours to run (essentially processing hundreds of thousands of payments).

What we didn’t count on was having to stop some way into the test for someone to either submit an optimization update or actually fix a bottleneck—getting 10-12 hours into the test, then having to halt it and restart it—over and over and over again. We started thinking we might never finish.

This is one of the pain points we hoped to solve with an automated way of monitoring. By pointing the automatic APM solution at our test environment, not only did we not have to configure anything (or even set up a special start command) but we also got almost immediate feedback on any change (both positive and negative). It also pinpointed the exact location in the code where the problem occurred, so the developer could almost immediately update their code and initiate a restart of the test. Finally, we could pick any two runs and compare their execution and performance to identify the real problem.

Two things happened:
- We were able to iterate different runs ~5 times faster.
- We got such great bottleneck and debugging data from our solution that we cut the runtime of the test from 20 hours to less than one hour.
Give Developers the Tools to Shine

While all employees like to succeed, developers especially love when they can rise above their challenges and deliver high-performance code. We like to give our dev team the best possible tools to help them achieve this excellence. Approaching the decision process for selecting a tool for them should be handled no differently than thinking about your end users:
- Identify pain points.
- Find a resolution.
- Execute the solution.
For our development team, that meant relieving them of low-thought repetitive tasks that we could automate and stop making them spend their time culling through performance logs.

Making the Right Choice??

The long and short of it is that we replaced our legacy APM tool with a solution that delivers the automation we crave and eliminates the need for log deep-dive analysis to solve any problem. It also supports log analysis with various integrations, which was important to us.

We get a trace of every single call, which is important to the Ops and customer support teams—and they profile every production process automatically, which gives our developers more than enough information to take action.

Ultimately, we’ve accelerated our application delivery and update processes, streamlined testing and monitoring. And our developers are super happy that we give them the tools they need and then challenge them to make the best possible applications using those tools.
October 27, 2020
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.
October 22, 2020
The Low-Code/No-Code Revolution: Join the Conversation
Make plans to take part in the low-code/no-code conversation at an upcoming daylong virtual conference

MediaOps, the company behind devopsy.kinsta.cloud, is excited to announce it will be producing Low Code Today, a new live virtual event taking place Nov. 19. The call for speakers is now open and actively accepting submissions.

The low-code/no-code market has been growing and evolving for a number of years. With the onset of the COVID-19 pandemic and the need to bring applications to use faster than ever, as well as the increased capabilities of building complex applications with low-code/no-code tools, this area is becoming increasingly important.

We want to hear your stories: How have the economic conditions during COVID-19 accelerated your digital transformation efforts? What tools are you using to work smarter and faster in a world where building cloud-native applications is quickly becoming a necessity?

We’re inviting all professional developers, citizen developers, business executives and creators of low-code/no-code technologies to submit their abstracts before the deadline, Oct. 31.

Low Code Today is a free, multi-track virtual event focused on the low-code/no-code market that’s been developing over the past few years but has seen exponential growth in the past six months. We invite those who are interested in speaking to submit their abstracts for one of the following topics:
- Steering the Charge: Hear directly from CIOs, business leaders and IT managers on their approaches to adopting low-code/no-code from a high-level, organizational perspective. What are the strategic approaches, considerations and challenges with bringing low-code/no-code tools to an organization? How is low-code/no-code revolutionizing businesses? What will the future of app development look like?
- Learning by Doing: The best way to learn is by doing. Tune in to hear experiences and case studies from customers who have brought low-code/no-code technologies to their organizations. You’ll discover answers to questions such as, How has your company used low-code/no-code tools? What was the impact? What lessons were learned?
- Enabling the Citizen Developer: Low-code/no-code technologies have given rise to the “Citizen Developer.” These demonstrations, workshops and how-to tutorials will share how low-code/no-code tools can help business users improve processes and increase productivity.
Whether you’re currently using low-code/no-code technologies or creating tools that can support complex business processes, we encourage you to tell your story with an individual presentation, panel discussion, customer case study, fireside chat or live Q&A session.

For more information, please contact inaara@mediaops.com. Sponsorship opportunities are available. Sponsors to date include ServiceNow, Outsystems and Prodly. Click here to submit your session.
October 19, 2020