Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Will Automation Fill Gaps Left by the ‘Great Resignation’?

    Will Automation Fill Gaps Left by the ‘Great Resignation’?

    Between burnout, job-hopping and the ongoing pandemic, labor shortages will surely get worse before they get better, and automation is increasingly sought after as a way to mitigate the ripple effects of understaffed IT departments.

    For DevOps, automation has several benefits, from freeing up employees to work on more constructive tasks to minimizing software bugs and technical debt.

    However, starting off slow and learning how automation will help address staff shortages without complicating processes is a critical factor.

    “There’s still a lot of teams that are struggling with far too many manual or repetitive tasks,” said Rich Lane, chief strategy officer at Netenrich, a digital IT and security operations company. “Obviously, trying to do your day job of delivering features and functionality into the wild can be challenging with the speed that business needs demand.”

    Lane, a former senior research analyst at Forrester Research, pointed out that slowing down in the present to do foundational work that can lead to higher levels of automation in the future can be hard to sell to digital services stakeholders.

    “And yet, without doing so, it becomes increasingly difficult to meet commitments in the event a team becomes shorthanded or delivery requirements increase,” he said.

    Generalist or Specialist?

    Cody Michaels, application security consultant at nVisium, said when it comes to hiring people for a DevOps environment, you have one of two options: You can hire someone with a wide range of knowledge that spans the entire process or you can hire someone with expertise in one core area like programming or deployment.

    “At an individual level, a generalist will be better than an expert, however, a team of experts will outperform a team of generalists,” he said. “Not only can automation fill in gaps between an expert’s area of influence, but it can also serve as a permanent fixture on the team. As a result, the turnover rate won’t affect any automation so long as it’s implemented properly.”

    From Lane’s perspective, the main areas DevOps teams should be looking to automate are continuous integration and continuous delivery (CI/CD), IaC and AIOps-enabled incident management platforms.

    “By taking the manual nature of day-to-day work off of DevOps engineers’ plates, they are freed to focus on digital transformation,” he said. “The number-one stumbling block is not starting with process.”

    Lane noted unless you understand all the steps in a procedure that you’re trying to automate, it is very difficult to maximize the power of automation tools.

    “Much of the process that is still adhered to today is outdated for the digital age,” he said. “Spend the time up front to map out what you hope to achieve with an automation project, what all the touchpoints are and how one can measure the quality of automation when it’s implemented.”

    Michaels added that while the internet is flooded by companies shouting they have the “best” tools, that proclamation of “best” is going to be determined by budget and known languages.

    “The top tools that I would recommend are Jenkins, Docker, Git and Jira, since these four play very well together with regard to automation,” he said.

    Git, for example, has hooks that can trigger upon performing certain actions, like freshly submitted code, while Jenkins has automation as its middle name and it’s used in building, testing and deploying, which in turn facilitates CI/CD.

    Meanwhile, Docker provides virtualization of operating systems and running applications in a secure manner in conjunction with containers.

    “Lastly, Jira is one most don’t think about, but the platform has a lot of macros and filtering functionality that can update the work process automatically from events like code passing a test before it’s deployed, for instance,” he said.

    Michaels said a couple of core considerations organizations need to make when approaching the idea of automation and AI are time as well as safety nets in place.

    “Automation will take time to set up before you can benefit from it, but in the case of smaller teams, it won’t be too time-consuming to configure it all in one fell swoop,” he said. “But if you’re working with a lot of technical debt, unfortunately, it’s going to be payback time. If this is the case, my best advice would be to start small and not overhaul everything at once.”

    Minor Automation Improvements Have Major Benefits

    He said he thinks incremental improvement will be the best route for most organizations, and that even minor improvements will compound far faster than waiting a year to see if a redesign will work for you.

    “As I mentioned previously, it’s imperative to have safety nets in place,” Michaels said. “Make sure you have a contingency plan if something goes wrong in the process to recover back to a working state. However, strictly speaking, everyone should make it a practice to have a recovery plan in their software development life cycle (SDLC).”

    As the DevOps world moves into 2022, organizations choosing to embrace automation could find themselves in a win-win situation—for both developers and operations.

    “The more automation takes over the ‘housekeeping’ items of the process, the more time will be freed up to improve the process as a whole,” Michaels said. “As a result, taking time to go back and clean up technical debt can now be set aside between sprints and maintenance.”

    He pointed out that senior roles can tackle optimizing the architecture, which will ensure fewer bugs and a healthier work-life balance for all: Just imagine a world where developers can focus on perfecting their craft—instead of waiting hours or days for server reboots or disrupting their flow to update a ticket status.

    “It really comes down to the fact that organizations can no longer make automation an afterthought,” Lane added.

    He pointed out that given the difficulties in recruiting and retaining staff today, DevOps leaders must make their teams as efficient as possible—and automation can help achieve that goal.

    “The number-one way to achieve this is applying as much intelligent automation throughout the IT environment as possible so that the highly-skilled engineers can focus on transforming the business,” Lane said.

  • WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Working from home is de rigueur, JEDI redux, and more about Nvidia/Arm.

    Survey Says: Devs Stay Out of Office

    First up this week: GitHub’s annual survey of developers has some fascinating data on the workplace (ahem) “new normal.” The pandemic has radically changed devs’ expectations of where they can do their jobs.

    Analysis: WFH is SOP

    As with other roles, Dev people want to continue to work from home. But does this pose a threat to your DevOps culture? Make sure you can do Ops with equal flexibility.

    Paul Krill: Dev productivity is back to pre-pandemic levels

    GitHub’s “2021 State of the Octoverse” research … sees signs that work rhythm is returning to pre-pandemic levels. GitHub also found that 46 percent of developers who worked co-located with teammates now expect to work fully remotely or in a hybrid environment.
    …
    Based on data culled from more than four million repositories and surveys of more than 12,000 developers … JavaScript and Python remain the top languages, followed by Java and TypeScript. [And] GitHub found that development team performance can increase as much as 87 percent when reusing code and as much as 43 percent when using … CI/CD.


    Zeroing in on the WFH angle, it’s Richard Speed:

    Respondents who were in the office either full or part-time dropped from 42 percent before the pandemic to a mere 10.7 percent now. … That’s a lot of empty desks.
    …
    Fans of the ctrl-c, ctrl-v combo will be delighted to note that GitHub found that when code reuse was made “frictionless” at work, developer’s performance increased by up to 87 percent. … It’s all splendid stuff.


    But beware of statistical fallacies, thinks Henrik Ingo—@h_ingo:

    #WorkFromHome may have been more common than anyone realized. [But] is the population of GitHub users/respondents somehow skewed toward pioneers/early adopters? … This might be a case of correlation is not causation.


    Defense Dept. Orders New Clouds

    The DoD issued its latest cloud contract opportunity notice, with the snappy title of “Joint Warfighting Cloud Capability” (JWCC). Reading between the lines of the notice, it all sounds very DevOps-cum-Agile.

    The Pentagon has backed away from its previous insistence on a single supplier, and now wants at least two cloud providers.

    Analysis: JEDI redux, because AWS wants a do-over

    JWCC is the follow-on from the aborted JEDI procurement. Amazon Web Services was “disappointed” to have been passed over in favor of Microsoft. Now it appears the DoD wants them to share.

    What can you learn from such a multi-vendor DevOps strategy?

    Jordan Novet: Pentagon asks Amazon, Google, Microsoft and Oracle for bids

    Amazon and Microsoft were the finalists for a single Joint Enterprise Defense Infrastructure. … Microsoft won it in 2019, Amazon filed a protest and the Pentagon canceled the contract in July.
    …
    The new effort [is] known as Joint Warfighting Cloud Capability. … JWCC differs from JEDI because it allows the Pentagon to rely on multiple cloud providers.
    …
    The U.S. General Services Administration … said only two U.S. cloud infrastructure providers, Amazon and Microsoft, appear able to comply with all of the Pentagon’s requirements. … The value of the new contracts is not known, but the Defense Department estimates it could run into the multiple billions of dollars.


    In summary, heed this Anonymous Coward:

    Competing suppliers will try harder than one non-competing supplier. The DoD has had a lot of problems with One-Ring-to-rule-them-all systems like the F-35. … JEDI would have been the same.
    …
    Smaller steps with upgrades while testing/using offers better returns. Done right they can get a better deal by making the companies compete against each other in making sure the products are actually useful.


    But look carefully at the DoD contract opportunity, says bustinbrains:

    They’ll all get contracts. Then DoD will simply use the one that they actually like the best. No one can complain because it’s open-ended with no guarantees.


    Arm/Nvidia Deal on FTC’s Radar

    Last week, we talked about Nvidia’s goal to acquire Arm Ltd from SoftBank, and the regulatory challenges it poses—notably in the UK, home of the chip architect. After we went to press, the other shoe dropped.

    Analysis: Just Give Up Already

    As we said last week, Nvidia can’t be allowed to do this. Not only are ARM chips found in 99% of smartphones, but they’re an increasing fixture in the datacenter—especially places that value “performance per Watt.”

    Richard Waters: What’s next for the tumultuous takeover of Arm?

    Nvidia’s acquisition of UK chip design company Arm from SoftBank has provoked serious opposition on both sides of the Atlantic. … The US Federal Trade Commission had its own worries. China, meanwhile, is waiting in the wings.
    …
    The deal has shone a spotlight on the unique position Arm plays in the chip industry. [Nvidia] offered a guarantee that it won’t block any other companies from licensing Arm’s designs. The offer has fallen on deaf ears, with both the EU and UK ruling it inadequate. … Post-Brexit politics have also come into play.
    …
    At what point might Nvidia and SoftBank call it a day? … A stock market listing [is] the most likely alternative, with the UK a favoured venue.


    How’s it viewed from the inside? Here’s a hint from fivemack:

    I was at ARM when Softbank bought them; it came as a surprise to everybody, because we were absolutely confident that we were unbuyable because anyone interested in us would want to use differential licensing as a weapon against their competitors, and we … were confident that regulators wouldn’t accept that.
    …
    Lots of people went home with a year’s pay check in free money. And not a few people … went home with a decade’s pay check in free money.


    More and more DevOps workloads are running on ARM silicon. Here’s Biophoton:

    The low power expertise of ARM has to be an advantage in the data centre (DC) market. … Plus Linux is available on ARM so architectural lock-in of Intel could be eroded in the DC market.


    The Moral of the Story: You are known by the company you keep


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Lukas Mann (via Unsplash)

  • Digital Transformation Driving VSM Adoption

    Digital Transformation Driving VSM Adoption

    The number of organizations using value stream management (VSM) to bridge the divide between DevOps and the rest of the business is expected to dramatically increase over the next two years. The shift is due, in part, to investments in digital business transformation initiatives.

    A survey of more than 500 executives, IT and business leaders conducted by Dimensional Research on behalf of Broadcom, a VSM platform provider, finds the percentage of organizations employing VSM will rise from 42% today to 70% in the next two years. Nearly three-quarters of organizations (72%) that are not currently using VSM plan to do so in the next 18 months or more.

    The survey also finds that 85% of organizations are collecting some subset of value stream metrics today as part of an effort to deliver solutions faster (56%), improve decision making (55%) and increase transparency (54%).

    Laureen Knudsen, chief transformation officer at Broadcom, said that as organizations embrace DevOps best practices more broadly to drive digital business transformation initiatives, they need more visibility into the application development process. VSM surfaces the insights required to not only identify bottlenecks but also track how changes in application delivery timetables will impact key performance indicators (KPIs).

    VSM traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to an automated process using DevOps best practices—and as organizations realize just how dependent they are on software—an appreciation for the value of monitoring the impact of missed software development deadlines on the business is growing steadily. VSM platforms automatically collect technical metrics from DevOps tools that are then correlated against the KPIs the organization decides to track.

    The Broadcom survey found more than 96% of respondents’ companies are already in the process of adopting digital transformation. Strategic objectives include increasing efficiencies (70%), improving product quality (67%) and improving customer value (63%).

    Most respondents (92%), however, are anticipating product development challenges for 2022. The biggest product development challenge cited is a lack of visibility throughout the product life cycle (45%) followed by inefficient processes (44%), lack of resources (42%) and enterprise-wide lack of understanding of how products deliver customer value (42%). A full 89% of the business leaders surveyed also noted they continue to struggle with organizational silos between strategic development and operations; 93% noted that better alignment between teams would improve their organization’s overall return on investment (ROI) in software development. A total of 95% said they believed VSM would optimize their product life cycle processes.

    Knudsen said that, in time, artificial intelligence (AI) technologies will increasingly be infused into VSM platforms to enable automated feedback loops between the business and DevOps teams. In the meantime, DevOps teams should be prepared to adjust project priorities based on the needs of the business and to endure a higher level of scrutiny as business stakeholders become more involved in setting the software development agenda.

  • WhiteSource Adds SBOM Tool That Lists Vulnerabilities

    WhiteSource Adds SBOM Tool That Lists Vulnerabilities

    WhiteSource has added a software bill of materials (SBOM) tool to its portfolio that, in addition to capturing the components of an application, also surfaces vulnerabilities that should be addressed.

    Many organizations are becoming more rigorous about making sure SBOM are attached to every software development initiative in the wake of an executive order issued by the Biden administration that requires federal agencies to employ them. While not every organization builds applications for federal agencies, the fact that the federal government is requiring them in the wake of a series of high-profile breaches has led other organizations to review their software supply chain processes.

    An SBOM facilitates those reviews by making available a formal, machine-readable inventory of software components and dependencies that can be used to track their supply chain relationships and identify dependencies and hierarchical relationships.

    Ori Bach, executive vice president for product at WhiteSource, said WhiteSource SBOM takes the concept a step further by also identifying open source libraries. It will also automatically update the SBOM when changes are made to make it easier to identify unintentional or malicious content being installed during application builds.

    Finally, WhiteSource SBOM also provides remediation guidance that ensures updates won’t break the build.

    Bach said it’s already apparent cybercriminals have significantly increased their effort to compromise supply chains as part of an effort to compromise as many downstream applications as possible. In many cases, cybercriminals are now specifically targeting open source projects that create software that tends to be employed across a wide range of use cases.

    An SBOM in and of itself doesn’t make applications more secure. However, it can provide visibility into the components of an application that can then be used to inform DevSecOps best practices, which organizations are implementing more broadly as responsibility for application security continues to shift left toward developers.

    There are two primary specifications that organizations can use to create an SBOM. The Software Package Data Exchange (SPDX) specification is an open standard for communicating SBOM information including components, licenses, copyrights, and security references. Defined by the Linux Foundation, SPDX is now recognized as the ISO/IEC 5962:2021 international standard. The second is the Software Identification (SWID) format that is today widely used by publishers of commercial software.

    Regardless of the format used to construct the SBOM, Bach said there’s an opportunity to more closely align the increased visibility it enables with the application security goals of the organization building the application.

    The primary reason SBOMs are not as widely used as they might be by now has as much to do with inertia as it does with technology. However, as organizations start to expect an SBOM to be made available, it’s clear application developers and builders will need to find a way to automate the SBOM process as applications are continuously updated. The challenge, of course, is that applications are now being updated with greater frequency—thanks mainly to widespread adoption of DevOps best practices—that now need to be integrated with any tool for creating and maintaining an SBOM.

  • DevOps Teams Struggling to Keep Secrets

    DevOps Teams Struggling to Keep Secrets

    A growing number of organizations are suffering security incidents related to exposed secrets in DevOps CI/CD pipelines, according to a recent ThycoticCentrify report.

    The study paints a troubling picture: Only 5% of survey respondents said most of their development teams use the same secrets management processes and tools.

    The incidents run the gamut, from secrets published in the clear in public cloud code repositories to insecure third-party code to vulnerabilities in the organization’s own code or configurations.

    The problem is often made worse by security teams not knowing what to protect because development teams have their own cloud infrastructure or the ability to create internet-facing applications directly without security teams’ knowledge.

    “The reason why we see so many security incidents related to exposed secrets in DevOps is that using hardcoded passwords and keys is the easy path to getting things to work,” said Joseph Carson, chief security scientist and Advisory CISO at ThycoticCentrify. “We need to make it just as easy for DevOps to use secrets vaults so even when secrets get compromised they are no longer usable, valid or expired.”

    Carson said moving away from persistent privileges to just-in-time, on-demand privileges will reduce these types of misconfigurations and attacks.

    “Unfortunately, many developers continue to use hardcoded passwords or static keys that, when compromised, allow an attacker to gain control of the application resulting in either data exposure, ability to change the application configuration or move laterally around the network,” he added.

    John Bambenek, principal threat hunter at Netenrich, said the fundamental problem is that when organizations go to agile and DevOps, they remove all friction to moving code quickly—and that almost always includes removing security.

    “That means security is inherently reactive instead of being embedded into engineering, and that’s assuming security even knows what to protect in the first place,” he said. “It’s the natural consequence of removing security from the equation and expecting that it’ll just work on the backend. That approach hasn’t worked for decades; a JIRA board isn’t going to suddenly fix that problem.”

    From Carson’s perspective, secrets management is the ability to move away from hardcoded passwords or static keys to just-in-time privileges or one-time-use passwords so even when comprised they cannot be used.

    “Many privileged access management solutions that protected privileged access for years have extended functionality to developers to help move the value into DevOps so they can manage credentials for applications, databases, CI/CD tools and services without causing friction in the development process,” he said.

    Approaches like privileged access security helps enable API-as-a-service and provides instant availability of secrets, SSH keys, certificates, API keys and tokens.

    Secrets Management

    Bambenek added the problem isn’t choosing a secrets management process or tool, but rather that they aren’t in place at all.

    “Pick something that will keep keys and secrets out of public cloud repositories that developers will use that allows for quick and easy rotation of keys as the need arises,” he said. “The most important thing is that it’s the same tool everywhere that operates in a near-invisible process for developers. Four decades of software vulnerabilities have taught me that if you rely on the developers to do the secure thing, you’ll consistently be disappointed.”

    One Wrong Step

    Davis McCarthy, principal security researcher at Valtix, pointed out developers are not security practitioners by trade.
    “Developers are building new ideas, and no good idea comes without experimentation,” he said. “Experimenting with a new technology stack may lead to misconfigurations that unintentionally expose data.”

    McCarthy said shared SSH keys between users create a larger attack surface, and users will store secrets differently creating multiple attack vectors.

    If one user’s endpoint becomes compromised and their SSH keys are exfiltrated, it’s difficult to know what the first mitigation steps are. Between insider threats and malware, the wrong step could lead to a breach.

    “Whereas a software engineer may hold great knowledge of secure coding methodologies, web application attacks and encryption, they are still focused on executing their craft,” he said. “Organizations that do not build security into the development life cycle create a systemic risk that leads to failures in best practices.”

    McCarthy added organizations can centralize and embed secrets management into the tools already in use in CI/CD pipelines by creating an inventory, auditing it and frequently rotating secrets to sensitive environments.

    Bambenek said the short answer is to make sure the infrastructure of CI/CD pipelines is centrally managed and controlled without the ability of engineering teams to ‘roll their own.’

    “No security control will remain intact if someone can pick their own tools without any real governance,” he said. “CI/CD processes don’t require engineering teams to manage the backend of the deployment pipeline which means someone can ensure those functions are in place to begin with.”

  • Top 10 DevOps Things to Be Thankful for in 2021

    Top 10 DevOps Things to Be Thankful for in 2021

    Thanksgiving has been observed in the U.S. since 1861 and was officially designated as an official holiday in 1863 by president Lincoln. Of course, the tradition itself traces its lineage to the early days of the Pilgrims.

    This past year, of course, has been one of recovery from a pandemic that caused the deaths of millions of people around the world. Vaccines have saved the lives of countless more, so there is much to be thankful for despite all our recent trials and tribulations. In that spirit, there are more than a few things for DevOps professionals, in particular, to be thankful for this year starting with:

    Digital business transformation: Organizations of all sizes have had to adjust their business models because of both major changes in buyer behavior and an ongoing supply chain crisis. DevOps teams are at the core of any major digital business transformation initiative, so the demand for DevOps expertise continues to outstrip the available supply. Going forward, it’s been predicted we’ll see more digital transformation in the next 10 years than in all the last 40 years combined. The vast majority of those initiatives would never see the light of day if it were not for the expertise of developers and engineers working hand-in-hand to build and deploy applications faster than ever.

    Low-code platforms: As the demand for applications to drive digital workflows spiked in the wake of the pandemic, professional developers relied more on low-code platforms to decrease the time required to build an application. While many complex applications will still be built using procedural code, it’s clear not nearly as many applications could have been deployed without relying on low-code platforms to build them. It remains to be seen how many of the next generations of low-code applications will be built by so-called citizen developers that may soon be flooding DevOps pipelines with application code.

    Microservices: As an architecture for building applications the core concept of employing loosely coupled services together to construct an application goes all the way back to when service-oriented applications (SOA) were expected to be the next big thing in the 1990s. Microservices have, of course, been around for several years themselves. However, with the rise of containers as a software artifact for building microservices, it’s only now becoming apparent that building an application constructed using microservices not only takes less time but is easier to maintain and also more resilient.

    Observability: As a concept, observability traces its lineage to linear dynamic systems. Observability in its most basic form measures how well the internal states of a system can be inferred based on knowledge of its external outputs. In the past year, a wide range of IT vendors introduced various types of observability platforms. These make it easier for DevOps teams to query machine data in a way that enables them to proactively discover the root cause of issues before they cause further disruption. That’s a major advance over monitoring platforms that typically only provide predefined metrics to identify when a specific platform or application is performing within expectations.

    Biden’s executive order: In the wake of a pernicious attack against IT service management software from SolarWinds, the Biden administration published a sweeping executive order that requires federal agencies to implement a wide range of security best practices. Foremost among them is guidance concerning the security of software supply chains; which resulted in many organizations reviewing their entire software supply chain to make sure similar breaches will not occur.

    DevSecOps: As an extension of any DevOps best practice, DevSecOps generally describes an overall shift left in terms of making developers more responsible for application security. While still in its relative infancy, DevSecOps is starting to gain traction as DevOps and cybersecurity teams look to bridge a cultural divide that is as wide as any in IT. The ultimate goal is to deliver more secure applications without reducing the speed at which they are being built and deployed.

    GitOps: At its core, GitOps is an operational framework that takes DevOps best practices used to automate application development and extends them to infrastructure. The basic idea is that the configuration software created to manage infrastructure-as-code is just another software artifact to be stored in a Git repository. The approach provides a means for IT teams to achieve a continuous delivery goal that, more than a decade after DevOps best practices were defined, remains elusive. It’s still early days as far as GitOps best practices are concerned, but this has been the year when GitOps become part of the mainstream DevOps conversation.

    Kubernetes: Simultaneously one the most powerful and most complex IT platforms ever to come down the proverbial enterprise IT pike, Kubernetes has emerged as a de facto standard for building and deploying container applications that can more efficiently scale up and down as required to consume IT infrastructure. The challenge (and the opportunity) now is to make Kubernetes much more accessible to mere mortal IT administrators that typically don’t have the programming skills of a site reliability engineer (SRE) and which are both hard to find and retain.

    GraphQL: Employed as a query language for application programming interfaces (APIs), GraphQL provides a more efficient means of accessing data than the REST APIs that have been employed by developers in the past. Originally developed by Facebook, GraphQL adoption is still in its infancy but it’s clear APIs based on GrapQL will one day be as plentiful as REST APIs. That’s especially critical for microservices-based applications that rely on APIs to access data across a highly distributed computing environment that requires a more efficient means for transferring data.

    Venture and Wall Street capital investments: Investment firms are helping fuel DevOps advances as they continue to make capital available for companies vying for their share of a market that is expected to see compound annual growth rates of 24.7% through 2026. There will, of course, eventually be a wave of consolidation as merger and acquisition activity inevitably ensues. In the meantime, however, there is a wide range of DevOps technologies that might not otherwise be as broadly adopted if it were not for all the cash being poured into DevOps companies.

    The most important thing, of course, is that so many DevOps professionals are still here to build and deploy applications. It’s been a trying year for all concerned; however, as the pandemic crisis continues to recede, we can all be thankful for the opportunities that lie ahead.

  • Rethinking Programmer Education for Today’s Coders

    Rethinking Programmer Education for Today’s Coders

    The proliferation of low-code and no-code applications are changing the landscape for software. In the past decade, growth in these areas has empowered employees to generate solutions at the speed of a digital world, regardless of their technical background.

    This raises several questions: What kind of programmers do businesses really need? Should they still rely on programmers formally trained at four-year universities—what you might call “white-collar” programmers? Or, instead, are blue-collar programmers with self-taught skills or those who learned from a bootcamp more valuable? What will get organizations the right mix of programming skills?

    The short answer is that all programmers can be of great value. In general, blue-collar programmers, after all, connect things within the computing environment, while white-collar programmers create the things that are connected. The essence of low-code is that it allows more people to connect things and use their creativity to become more productive. But it doesn’t eliminate the need for professional programming and tools at its foundation.

    At their core, low-code and no-code are about democratization. They allow people without technical skills to work creatively in ways that essentially make everyone a programmer. A parallel from an earlier computing generation is the Excel spreadsheet, which lets people with no programming background perform computational tasks and eventually work their way up from simple formatting to full-fledged programming. But at some point, polished programming skills are still necessary, no matter how easy no-code or low-code can make some of those elements.

    In the breakneck pace of cloud-based computing environments with new services constantly being developed and deployed to the edge, it’s worth considering the distinctions between the white- and blue-collar programmers and what kinds of education are appropriate for each.

    Four-Year Colleges Vs. Boot Camps

    A career as a programmer can seem intimidating for onlookers. This is particularly true when these jobs involve complex languages such as C++ and Java, which are often used in large projects that can take years to develop and involve millions of lines of code. Some of that is still true, but the evolution of programming over the years toward languages that require less code, such as Python, and to domain-specific languages (DSLs), has also started to lower the barriers to entry for programming.

    It’s true that you’ve never needed a four-year computer science degree to be a programmer. In fact, many that have dropped out of college—or never attended at all—have made significant contributions to the industry. However, universities do provide a foundation in theory and algorithms that have always served programmers well and enable them to branch out into new areas, such as artificial intelligence or other disciplines, such as bioinformatics. Coding bootcamps, for their part, can provide intensive training on DSLs or frameworks like Rails or React.js that can benefit companies’ plans, giving blue-collar programmers the practical skills that white-collar programmers may not have. They also attract career-changing attendees with four-year degrees in other subjects, including the humanities and the sciences, which brings badly needed new ways of thinking into the profession.

    While each method is valid, both four-year institutions and bootcamps also have their shortcomings. Universities delve deep into software development theory but often don’t emphasize critical aspects of doing the job, such as teamwork, testing and agile processes. Nor do they focus much on core areas of businesses today, like cloud computing. Boot camps, by targeting specific areas and emerging technologies and languages, can help people get internships or entry-level jobs, but don’t provide a broader theoretical knowledge of programming. And they can be hit-or-miss, with some of them using sketchy practices for payments and job placement.

    The inherent weaknesses in both white- and blue-collar training can be addressed through apprenticeships and internships, but only to a point. The question remains: Who will train low-code programmers on modern development and coding practices? A lot of companies throw around terms like Agile and CI/CD, but they’re often just new labels on old, inefficient practices. Companies will need white-collar programmers to bring blue-collar programmers up to speed.

    Programming for the Masses

    No-code software is a great enabler, allowing people with no formal education or experience to become proficient in a programming environment. On the other hand, for people who do have formal training—whether a formal education or boot camp experience—low-code simplifies their work, leaving time to focus on more complex projects. But programmer or not, users of no-code and low-code solutions need to understand more than just deployment and testing if they want their software to be reliable and useful.

    Professional developers can make a difference by creating and maintaining the pipelines used to build, test, archive and deploy low-code software; they will need to build new tools to accommodate low-code frameworks. And while familiarizing themselves with current development techniques, they could become the teachers of essential computing practices that don’t involve coding.

    A cooperative, productive relationship between white-collar and blue-collar programmers is essential to moving forward with software development, as it will allow both to continue acquiring new skills and experience outside of low-code, which is only a product of programming, no matter how ubiquitous it may be.

    Making the Connection

    Today, we’re entering a business world where practically everyone will need to code, making low-code and no-code frameworks necessary, especially for users without formal training. However, the importance of professional programmers will remain, too.

    We’re likely to see a proliferation of DSLs created to solve specific problems, which will eventually evolve toward general-purpose programming languages. Programmers will need to build web frameworks, cloud capabilities and more, including everything from web widgets to the high-level tools that let users work. That may be the only way we can begin to meet the demand for more people who can program as more devices come online, more connections are made and the world becomes increasingly reliant on automation.

  • Netlify Acquires OneGraph to Integrate GraphQL APIs

    Netlify Acquires OneGraph to Integrate GraphQL APIs

    Netlify this week announced it has acquired OneGraph, a provider of a platform that simplifies the integration and management of application programming interfaces (APIs) based on the GraphQL query language.

    At the same time, the company is committing $1 million to sponsor open source projects and setting aside $10 million for a Netlify Jamstack Innovation Fund that will help drive the development of emerging technologies. Those technologies will be consumed via the platform the company created based on Javascript, APIs and a markup language (referred to as Jamstack) to accelerate web application and website development. Rather than becoming investors in those companies, Netlify intends to make those funds available to advance the development of technologies that benefit the overall community.

    Fresh from raising an additional $105 million in funding, Netlify CEO Matt Biilmann said Netlify is committed to an ecosystem through which developers will be able to consume a wider range of services via both REST and GraphQL-based APIs. OneGraph will provide the core foundation for adding support for GraphQL to the Netlify platform, he noted.

    Overall, Netlify is trying to reduce the friction that developers encounter building web applications and the sites they run on, added Biilmann. That’s becoming especially critical as developers increasingly build microservices-based applications that invoke APIs to consume backend services that are made available via the Netlify platform, he added.

    Earlier this year, the company made available Netlify Build Plugins that provide DevOps teams with a set of continuous integration/continuous delivery (CI/CD) workflows for building websites and web applications. Designed to be launched from within a Netlify platform, those plugin makes it possible to build a web application or website that can be launched directly from within a Git repository.

    The overall Jamstack philosophy enables DevOps teams to separate the development of frontends and backends of websites and applications. That approach is agnostic as far as any specific JavaScript framework is concerned, but it does define a way to automate the build process for a web application or website.

    A recent survey of more than 3,000 Jamstack developers published by Netlify finds one-third of survey respondents have worked on sites serving millions of users over the last year. Nearly two-thirds of survey respondents (62%) work outside the tech industry, including in advertising and marketing (21%), media and publishing (14%), education (14%), financial services (13%) and business support and logistics (13%). Well over a third (38%) work for a technology company. About a quarter (26%) have more than 10 years of experience. Top Jamstack benefits cited by all types of developers are performance, uptime, speed of development, security, compliance and avoiding vendor lock-in, the survey found.

    Jamstack is, of course, not the only framework for building web applications and the sites they run on. DevOps teams are increasingly being tasked with building a much wider range of external applications to drive digital transformation initiatives that are typically built using some type of JavaScript framework. The next big DevOps challenge, of course, is that as the number of applications being built continues to increase, so does the number of applications that need to be maintained and continuously updated.

  • Kyndryl Aligns with Microsoft in the Cloud

    Kyndryl Aligns with Microsoft in the Cloud

    Following its spinout from IBM, Kyndryl has allied with Microsoft to increase the scope of IT services it provides on the Azure public cloud.

    Stephen Leonard, leader of global alliances and partnerships for Kyndryl, said that as part of this initiative, Kyndryl will be expanding the scope of the services it provides to both organizations building and deploying applications as well as those looking to migrate existing applications to the Microsoft Azure cloud.

    Over time, Kyndryl will expand its cloud services to include additional public clouds as part of a larger effort to enable organizations to embrace a hybrid cloud approach to enterprise IT that spans multiple on-premises and cloud computing environments.

    In the meantime, as part of the first partnership established by Kyndryl, the two companies are committing to providing services to address data modernization and governance, security and application workloads infused with artificial intelligence (AI) capabilities. The two companies also plan to establish a co-innovation lab. Microsoft is also committing to establishing a Kyndryl University for Microsoft.

    Leonard said given the overall shortage of IT expertise, more organizations than ever are relying on external IT services to, for example, accelerate application development. Kyndryl plans to work with those organizations to best evaluate where specific classes of application workloads might best be deployed, he noted.

    It’s become increasingly clear that more organizations are attempting to integrate third-party IT services within DevOps workflows. In some cases, that means standardizing on an opinionated DevOps workflow defined by the IT services provider. In other cases, the IT services provider is focused on a specific task such as securely provisioning infrastructure on behalf of developers.

    Regardless of the approach, however, DevOps workflows are evolving into a team sport made up of both internal and external IT professionals that are trying to bridge the cultural divide that always exists between different organizations. Which IT services provider organizations ultimately select often has as much to do with how flexible they are from a cultural perspective as much as it does their technical expertise.

    For its part, Microsoft is counting on IT services providers such as Kyndryl to increase the total number of workloads running on its cloud. Now that Kyndryl is independent of IBM, it is free to establish partnerships that previously would have been more complex to navigate.

    Of course, it’s up to each organization to determine the degree to which they prefer to work with a larger IT services provider versus a smaller rival that may specialize in one specific area or that is simply a better fit for a smaller company. The one thing that is certain is that as IT continues to become more complex, it’s not feasible for organizations to hire all the IT talent they require on a full-time basis. Organizations will need to carefully evaluate when it makes more sense to consume certain IT services as a function provided by someone else versus attempting to hire and retain talent to maintain that service themselves.

  • Cortex Expands Microservices Catalog to Improve Collaboration

    Cortex Expands Microservices Catalog to Improve Collaboration

    Cortex, a provider of a catalog for tracking the ownership of microservices, today announced it has added a service creation capability that enables developers to use templates to scaffold new services in five minutes.

    In addition, the company has added a Cortex Teams offering that improves collaboration across teams of developers working on interdependent microservices.

    Fresh from raising an additional $2.5 million in funding, Cortex claimed it has increased its customer base by a factor of 10 since initially launching last May. Those customers include Rappi, Grammarly and 8×8.

    Cortex CTO Ganesh Datta said the company’s microservices catalog makes it simpler for teams of developers, DevOps engineers and security professionals to collaborate at a time when software development is becoming more complex. While microservices-based applications are easier to update and generally more resilient than monolithic applications, composing an application based on interdependent microservices created by different development teams can be more challenging to build and maintain.

    In some cases, organizations can even discover that different teams within their organization have built redundant microservices. Part of the reason that occurs is many IT teams still rely on spreadsheets to keep track of what microservices are being built and which ones are already deployed in a production environment.

    Cortex, in contrast, automatically imports data residing in developer tools to surface who within an organization is responsible for maintaining which microservices. A Cortex dashboard also enables DevOps teams to see which developers are on-call in the event of an unexpected incident as well as monitor and track the latency rate microservices are experiencing and which vulnerabilities have yet to be remediated.

    At the core of the platform is Cortex Query Language (CQL), a domain-specific language that allows DevOps teams to define granular rules that can be applied to, for example, on-call rotations, security vulnerabilities, package versions, service level objectives (SLOs) and the overall health of the microservice. Engineers can employ code in the form of YAML files to set reliability standards across teams and types of services.

    Grades can also be assigned to specific microservices based on associated metrics. That approach allows DevOps teams to apply gamification techniques using a scorecard to encourage developers to continuously improve their microservices. That capability makes it apparent to other developers which microservices can be most reliably employed.

    It may be a while before microservices-based applications dominate the enterprise landscape. Monolithic applications will be running in production environments well into the next decade. However, many of those monolithic applications are essentially being converted into a larger microservice that other applications can invoke via application programming interfaces (APIs) before being eventually being re-engineered into a set of logically connected microservices.

    The one thing that is clear, however, is that as the number of microservices expands, it becomes more difficult to determine precisely what capabilities are already available to highly distributed application development teams.