staging-devopsy.kinsta.cloud

Category: Features

  • Low-Code: An Oasis During Developer Drought

    Low-Code: An Oasis During Developer Drought

    Key insights from Mendix’s 2020 Developer Drought Index

    You may have heard that Silicon Valley is in the midst of a developer drought. But the Valley is not alone; developer talent across the U.S. heartland has dried up. In fact, the top 10 U.S. counties with the highest developer demand per capita aren’t even in California.

    A recent report by Mendix identified new hiring hotspots and a changing U.S. map for tech talent. States in the U.S. heartland are actively seeking developer talent, though some are slow to adopt 100% remote work. In the wake of COVID–19, many are reassessing work-life opportunities, leaving densely populated cities to work and live in more rural areas.

    I recently had a great discussion with Sheryl Koenigsberg, head of global product marketing at Mendix, to make sense of the “Developer Demand Index” findings. Below we speculate on the future of developer work, and how low-code platforms may be the oasis many talent-thirsty companies seek.

    ‘Developer Demand Index’ Study

    The “Developer Demand Index” sought to identify locations where developer talent is needed the most. The process involved a geographic analysis of 2,000 of July 2020’s job ads for U.S. software developers.

    The study found high developer demand and short supply in middle America; South Dakota, Nebraska and Utah were among the top states with the lowest supply to demand.

    At a county level, the highest developer demand was in Cumberland County, New Jersey; Minnehaha County, South Dakota; and Pontotoc County, Mississippi.

    The study demonstrated how more established tech hubs—Silicon Valley and Austin, for example—have a better balance of talent demand and supply.

    “The study confirmed unpopular theories that I had,” said Koenigsberg. “Developer drought is not a Silicon Valley or coastal-only problem; smaller metros throughout the country are experiencing the same problem.”

    Conditions for a Drought

    Why do states in the nation’s heartland have a developer drought to begin with? I assumed that a lower average salary in middle America would deter developers, but Koenigsberg said the conditions are more complex.

    “I don’t necessarily see a correlation between average salary and developer drought,” she said. Rather, new tech hubs continue to form wherever larger enterprises can get tax breaks. Other regional perks could include local government startup incentives or university partnerships.

    Tech certainly has a history of revitalizing less dense areas with new hubs. Take Google’s expansion into Austin, Amazon’s takeover of Seattle’s South Lake Union neighborhood or SpaceX’s remote Starship site in Boca Chica, Texas. Naturally, these areas attract the requisite talent and encourage other companies into the fold as well.

    For example, the report speculates South Dakota state could be a new Silicon Prairie hotspot. “A vibrant tech & startup scene, local talent, and the lowest COVID–19 rates are all driving the economic surge in this state,” read the report.

    With remote work and social distancing brought on by COVID–19, technology companies are adapting and the urgency to cluster in certain locales may dissipate.

    COVID–19 and Remote Work

    Software was already eating the world. But with COVID–19, it’s eating physical reality itself.

    With COVID–19 forcing many companies 100% online, the need for new software is skyrocketing like never before. Google, Facebook and many others have enacted stay-at-home plans for most of 2021. After the crisis, remote work will be a more permanent reality for many.

    While COVID–19 benefited tech, many brick-and-mortar businesses were less prepared. We’re now seeing the frailties of old systems, described Koenigsberg, and the need to replace paper-based or manual operations with digitized versions. Consumer-facing companies that did not vigorously embrace digital transformation before COIVD–19 are now in a tight spot.

    Low-Code Waters Fill a Developer Drought

    According to Derek Roos, CEO of Mendix, “the ‘Developer Demand Index’ shows that companies need to think differently about how and where to engage skilled tech workers in 2021 and beyond. Traditional development paradigms basically fall apart when you’re dealing with mobile or remote workflows.”

    As I covered recently, COVID–19 is only one of many factors spurring a low-code revolution. By utilizing visual-based models, “citizen developers” can construct applications. This enables a business analyst, for example, to string together an internal application without jumping through the traditional IT hoops. Koenigsberg identifies other low-code benefits:

    • Hire Local: If tools are less impenetrable, companies can retrain local employees, helping recover the developer gap and negating the need to hire externally.
    • Collaboration: Low-code aids remote work, enabling pair programming where teams work on the same model simultaneously.
    • Domain Expertise: Citizen developers with niche domain knowledge can better optimize applications to their industry needs. Knowing a factory production yield, for example, can help better construct a manufacturing application.
    • Women in Tech: Koenigsberg notices significantly more female involvement at low-code themed events. Hopefully, low-code can have a balancing effect on gender participation in tech.

    Final Thoughts

    The Mendix “Developer Drought Index” revealed areas of high demand and short supply throughout the U.S. Interestingly, 92% of the job ads analyzed in the study required a specific location. Regardless, the report concludes there are compelling “opportunities for companies and individuals to decentralize talent away from established tech hubs using virtual teams and cloud technology.”

    Low-code seeks to democratize software development to keep deployments on pace with the intense demand for software. Of course, low-code is no cure-all, and Developer Drought locations will likely still seek external or offshore hiring to supplement. However, low-code may offer the respite needed during uncertain times.

  • DevOps Deeper Dive: Google Roils Open Source Community

    DevOps Deeper Dive: Google Roils Open Source Community

    Google this week agitated the bulk of the open source community by launching the Open Usage Commons consortium to protect the trademarks of open source projects, starting with the Istio, Angular and Gerrit projects it launched.

    Launched in collaboration with SADA Systems and some independent contributors, the stated goal of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing.

    Istio is a service mesh that runs on top of Kubernetes, while Angular is a web application framework. Gerrit is a code collaboration tool.

    Unlike previous open source projects that Google played a major role in developing such as Kubernetes, Google has yet to contribute these three projects to an open source consortium. That decision has members of the open source community now questioning Google’s commitment to open source software.

    In fact, IBM, which launched the Istio project in collaboration with Google, this week said the Open Usage Commons does not meet the level of open source governance IBM expects. Originally, IBM said the expectation was that Istio would be contributed to the CNCF once it achieved a level of maturity. That contribution would include Istio intellectual property and the trademark. Now IBM is encouraging Google to reconsider its Open Usage Commons approach.

    If Google continues to hold on to the intellectual property rights for open source projects such as Istio, those projects will become little more than a community project that Google exercises control over, said Priyanka Sharma, general manager of the Cloud Native Computing Foundation (CNCF), which oversees the ongoing development of Kubernetes, among other open source projects.

    “It’s not in the spirit of open source,” said Sharma. “I don’t think you can even call it open source.”

    Other open source initiatives will be hesitant to build on top of projects such as Istio if the intellectual property belongs to a single vendor, added Chip Childers, executive director of the Cloud Foundry Foundation (CFF). The trademark is never the main issue, he said.

    “The trademark is only part of the consideration,” said Childers.

    In the case of Istio, the decision to launch Open Usage Commons might also draw more attention to a Service Mesh Interface (SMI) project being advanced under the auspices of the CNCF. That interface promises to make it easier to rip and replace one service mesh for another.

    In the meantime, Google may be trying to maximize its investments in open source projects that until now have tended to benefit rivals more. In terms of consumption of cloud services based on Kubernetes, Google is a distant third at best to Amazon Web Services and Microsoft.

    In general, there are more open source projects than ever. However, some of the entities that launch those projects have complained that cloud service providers simply turn those projects into cloud services in a way that consumes most of the revenue opportunities any open source project might generate.

    Google now appears to be exacerbating those tensions further by trying to retain control over the open source project it leads, while selling services based on other open source software projects. It’s not clear to what degree this rift might drive a wedge between multiple open source factions. Google with this move may just drive more members of the open source community into the arms of AWS and Microsoft. However, for the moment at least, none of the projects covered by the Open Usage Commons trademarks are so critical that they could not be replaced by any one of several alternative projects that are truly open source.

  • COVID-19 Long Tail Budget Impact

    COVID-19 Long Tail Budget Impact

    Technology budgets have shifted dramatically since the beginning of the COVID-19 pandemic, according to a recent study from online CIO networking and information hub, Pulse. The pandemic, and its resulting shutdown, will likely continue to have a substantial impact on technology budgets for some time.

    The initial budgetary impact was substantial. When COVID-19 first arrived, many technology budgets were frozen in place. Today, 23% of CIOs report that their budgets are still frozen with 49% reporting a decline in their technology budgets. Seventeen percent said that they expect to decrease their budgets by more than 10% in the next two months.

    Fortunately, it’s not all bad news. Many respondents, 24% of them, predict that within the next two months their budgets will rise, including 9% of respondents who believe their budgets will increase more than 10%. However, most CIOs (27%) say that their IT budget won’t change in the near future.

    “And an additional 6% anticipate their budget will become frozen in the next two months — though, on a positive note, this figure is down from 23% two months ago,” stated the report.

    Surprisingly, there hasn’t been a change in business-technology priorities over the past two months for 79% of respondents, while 21% said that they now have different priorities than from the beginning of the pandemic.

    The priorities of those surveyed include focusing on internal communication and collaboration tools (45%), mobile security (39%), customer communication and collaboration tools (37%), password management tools (28%), virtual private networks (28%), security awareness training (24%), remote desktop tools (23%), encrypted communication tools (23%), and data security tools (15%).

    “Many companies are going to allow (or require) employees to work from home after the pandemic, due to health concerns and reduced overhead. The fact that CIOs are investing in security and end-user technology — even though budgets are decreasing — indicates this,” said Brian Sampietro, CIO at  TGI Office Automation, in the report.

    For those organizations who changed their priorities, the new budget items include virtual private networks (36%), password management (32%), remote desktop tools (30%), data security tools (27%), encrypted communication tools (26%) and mobile security (21%).

    How are CIOs making decisions when it comes to technology purchases? The majority said peer recommendations (69%) and industry analysts (52%). However, social media and email fared poorly as influencers, at 23% and 20% respectively. CIOs are determining needs, according to the survey, based on both executive and end-user requests. Only 10% said they depend upon user requests alone, and only 21% said executives solely drive decisions. Interestingly, 35% of CIOs make decisions quickly: Within one week they said they will decide on the right tool to acquire. The rest said they take more than a month (26%) or within four weeks (39%).

    When it comes to layoffs, there are still rough patches ahead, as a sizable number of organizations still have layoffs on the planning table. While 48% of organizations have maintained their headcount through the COVID-19 crises, 40% do plan to cut staff sizes in the next six months, with 25% not sure if they will cut staffs.

  • Metropolis Now: The Two Worlds of Employment in the Age of Automation

    Metropolis Now: The Two Worlds of Employment in the Age of Automation

    Current events have revealed that there are two worlds in the employment landscape. One is digital, the other analog. For the most part, those in IT—the digital workers—have been unaffected by the spike in unemployment due to the economic side-effects of the COVID-19 pandemic. But, it doesn’t mean they’ll be untouched in the long-term. As current events demonstrate, when it comes to the essentials in life, we’re all connected. Yet, the divide will continue to separate us to the detriment of all unless we do something about it.

    When observing current events, I can’t help but think about Fritz Lang’s 1927 silent movie, Metropolis. It’s a science fiction film that depicts a world in which a small number of people live a privileged life in skyscrapers that tower high above the city. The rest of the population toils away below ground, doing the mundane work required to keep the city running. It’s a stunning piece of cinematography. The sets and special effects are breathtaking. What’s also impressive is that, for better or worse, so much of what Lang presented nearly 100 years ago has come to be.

    You can view the full-length version of Metropolis here.

    metropolis-scenes
    Figure 1: Scenes from the 1927 silent movie, Metropolis by Fritz Lang.

    Lang’s vision of the future has a strange, almost eerie prescience for me, particularly as someone who has spent most of his adult life working in IT. It’s one that’s entirely possible, yet one I hope we avoid.

    Allow me to elaborate.

    Life Is A-OK in the Cloud

    There’s a good argument to be made that today we live in Lang’s Metropolis, a world in which those who are doing really well live in the light of society while those who are just getting by live below ground in darkness.

    The widening gap between prosperity and economic hardship is a trend that’s been unfolding over the last 30 years. We’ve become accustomed to it. Sadly, it’s no longer newsworthy.

    What is newsworthy is the dramatic spike in unemployment due to the business shutdowns caused by the COVID-19 pandemic. The uptick in unemployment reveals a troubling set of circumstances: If you’re a digital worker chances are you’re still working. If you work in the analog world, that place where factories, restaurants, airlines, movie theaters, hotels, cruise ships and warehouses exist, there’s a good chance you or someone you know is out of a job, for now anyway.

    Take a look at the graph from the US Private Sector Job Quality Index, a project from Cornell University Law School and others, by way of vox.com. It lists the jobs that are most vulnerable to layoffs due to the COVID-19 pandemic. IT workers don’t even make the list. It’s as if we live in another world.

    at_risk_jobs_by_industry
    Figure 2: Information workers are absent from the list of jobs at risk due to COVID-19.

    The long and the short of it is that for developers, sysadmins, SREs and all the other people working in information technology, the recent economic downturn is but a blip in the daily news feed. For those manning a cash register, taking a ticket at the local cineplex, cutting hair or driving for a rideshare service, it’s a life-altering event. Or, to put it terms of Lang’s film, those of us who live in the clouds are doing well, and for those on the ground, it’s a different story.

    Now, consider this: What if all the people who are presently laid off from their jobs find out there are no jobs to go back to? What if the economic recovery is slower than anticipated or society gets so accustomed to doing without that consumption doesn’t resume? Is such a scenario possible? Yes. Is it probable? Dunno. Will those of us in IT who work remotely all over the planet, from the comfort of our wired office, suffer? I doubt it. But, as for the rest, what then?

    Let’s go back to the movie.

    A Workforce Divided

    There’s a point in the film when the protagonist, Freder (the son of the industrialist who built Metropolis), goes to his father to inquire about a catastrophic underground explosion shown earlier in the film.

    The son asked, “Your magnificent city, Father, and you, the brain of this city, and all of us in this city’s light … and where are the people, Father, whose hands built your city?”

    The father responded, “Where they belong.”

    The son asked, “Where they belong? In the depths?”

    His father nodded his head yes. (See the scene here).

    There you have it. With that one physical gesture, Lang foreshadows a future which might very well be at our doorstep. As I mentioned earlier, it’s eerie, it’s prescient and it looks as if it’s coming to be.

    What Does This All Have to Do with DevOps?

    Those of us in DevOps have made valuable contributions to the world. We’ve done dramatically more good than harm. We’ve also been well compensated. The average salary for a SRE in the USA is $131,340, with a low of $60K and a high of $192K. Yet, the top salary for grocery clerk at Ralph’s supermarket is $22 an hour, which comes out to $44K a year over a 50 week year.

    Do SREs deserve such a high salary? Of course, they do. Does a grocery clerk deserve only $44K a year in comparison? At the end of 2019, it would have been easy to say, yes. It’s a low skill, low education job. But that was then, and this is now. As of this writing, toilet paper is a premium commodity and the shelves need to be stocked with it. I’ll wager that in some circles, paying someone $50 an hour to get the rolls on the shelf is reasonable compensation. It all depends on how much people want toilet paper.

    Am I being a bit dramatic?  A little, but still, it’s worth thinking about.

    So, what’s the important take away? Let’s go back to Metropolis one last time.

    At the beginning of the film, there’s a scene in which the protagonist, Freder, was frolicking about in a lush arboretum-like greenhouse atop a skyscraper. He was surrounded by pretty maidens dancing. An elevator door opened into the garden. Freder observed as a group of raggedy waifs from beneath the city exited out of the elevator. A woman leading the waifs was at the head of the group. The waifs looked around in amazement at such luxury. Then, Freder’s servants ushered the group back into the elevator to exit. Freder was obviously affected by the waifs. He went into the depths of the city to investigate.

    Shortly thereafter, Freder went to see his father to inquire about the explosion I described earlier. His father asked, “What were you doing in the machine halls, Freder?” 

    The son responded, “I wanted to look into the faces of the people whose little children are my brother, my sisters…”

    It’s a powerful scene. It makes me wonder how many of the faces I’ve seen of those who were working in February are now sitting home, unemployed and unable to pay the rent in April.

    The takeaway is this: We’re all connected at a level much deeper than the trivial interactions of the given social network. Current events have demonstrated the fact in spades. COVID-19 was first reported in China around November 17, 2019. On April 4, 2020, less than six months later, there were 240 cases reported in the state of South Dakota in the United States. If that’s not connection, I don’t know what is.

    Those of us who work in the cloud are doing quite well, despite the setbacks caused by the global pandemic. But, there’s a growing number of us who are not doing so well and won’t be for the foreseeable future. It’s easy when everything is peaches and cream to be unaware of a world in which six-figure salaries are not the norm. But, when things go south and there’s no toilet paper to be had, the realization that we’re all in this together smacks us square in the face, like it or not.

    The question then becomes, given that we’re all connected, what type of world do we want to share, the one in Lang’s Metropolis or something better?

    It’s something worth thinking about. The pandemic will pass, but the underlying disparities will remain unless we do something about them.

     

    The Impact of Automation

    Don’t forget to check out my new, free book, “The Impact of Automation.”

    This book takes a serious examination of the history, impact and results from automation on our society and culture. Hope you enjoy it.

     

  • Digital.ai: The Companies Formerly Known As XebiaLabs and CollabNet Plus

    Digital.ai: The Companies Formerly Known As XebiaLabs and CollabNet Plus

    Another shoe has dropped in the continuing story of TPG Capital‘s foray into DevOps. The company formed by the merger of XebiaLabs and CollabNet VersionOne is now Digital.ai. Additionally, the company has acquired Arxan, a leader in application protection.

    Digital.ai logo

    I had a chance to catch up with Digital.ai’s CEO Ashok Reddy and Arxan COO Mark Lorion, who will be Digital.ai’s COO of Platform going forward. The video of our discussion which is also available on TechStrong.TV, appears below.

    What They Said

    Reddy made it very clear that Digital.ai is not content with simply adding this AppSec company to the mix. It is actively involved in due diligence operations on several other acquisitions. Reddy and the TPG team feel that the current COVID-19 situation affords those with cash to pick up some bargains. That may have been the case with Arxan, which was owned by private equity firm TA Associates, which acquired Arxan in 2013 for $132 million. TA may have decided it was time to get off the merry-go-round, given the unsettled state of things right now.

    In any event, TA’s loss is Digital.ai’s gain. Arxan adds some much-needed security muscle and a blue-chip bank customer list. But, of course, the real play here is building out the end-to-end DevOps company that will compete with GitLab, GitHub, CloudBees, JFrog and others. We detailed this market in an article when the original merger was announced.

    My take is that indeed Digital.ai is not a complete company just yet. It may not even be done in the DevSecOps space, as Arxan is not your typical DevSecOps technology. It may have been more of an opportunistic acquisition.

    Also, in terms of executive team, Reddy has been quietly assembling a team made up of some of the best people he worked with at previous stints at IBM, CA/Broadcom and the executives from the acquired companies.

    Stay tuned for more on Digital.ai’s continued evolution in the months to come.

    — Alan Shimel

  • Coronavirus Economic Shutdown: Analysts Hit the Brakes on Global IT Spending Estimates

    Coronavirus Economic Shutdown: Analysts Hit the Brakes on Global IT Spending Estimates

    By most accounts, 2020 was set to be a pretty good year for U.S. gross domestic product and enterprise IT budgets. That was before the novel coronavirus, and the subsequent economic shutdown that is designed to blunt its spread and avoid overwhelming the nation’s health system. Analysts are now slashing their economic growth rates and enterprise technology spending estimates.

    Previously, research firm IDC estimated that real GDP in the U.S. would reach 2.4%, but downshifted that to a “pessimistic scenario” of 1.4%. While IT spending dropped from an expected 5.1% year over year growth to a pessimistic scenario of 1.3%. The base scenario for GDP growth is now 2.0% and for IT spending 4.3%.

    “The pessimistic scenario is not a worst-case scenario,” said Stephen Minton, vice president in IDC’s Customer Insights & Analysis group. “Things are moving so quickly that we need to constantly recalibrate our assumptions and expectations, but the pessimistic scenario reflects an IT market in which weaker economic growth translates into weaker business and consumer spending across all technologies over the next few quarters. Things could get worse, but hopefully not.”

    Earlier this month, Forrester analyst Andrew Bartels wrote in this post that the U.S. and global technology market spend will slow to 2% this year.

    “That assumes the U.S. and other major economies have declined in the first half of 2020 but manage to recover in the second half. There is also a 50% probability that U.S. and global tech markets will decline by 2% or more in 2020 if a full-fledged recession hits,” Bartels wrote.

    Not all areas in technology will be impacted equally. Forrester expects there will increased demand for cloud infrastructure services, specialized software, communications equipment and telecom services for remote work and education.

    However, Forrester expects computer and communications equipment to potentially decline 5% to 10%, while technology consulting and systems integration services spending could be flat to down 5%, should companies really belt-tighten.

    “Software spending growth will slow to the 2% to 4% range in the best case and will post no growth in the worst case of a recession. Tech outsourcing and telecom services will hold up better, though contract revisions could cause spending to go down, as well,” stated Bartels.

    S&P Global Ratings also predicts slowing IT spend. According to its update, Global IT Spending Set To Slide As Coronavirus Hits Hardware Sales, S&P Global economists cut their global GDP growth rate by more than half to 1% to 1.5% from 2.8%—in just two weeks.

    “We believe the spread of the coronavirus will hurt enterprise and consumer IT spending across the globe with particularly bleak ramifications for the hardware and semiconductor segments. However, we expect some of the deferred spending to return gradually in the latter half of this year through heavy government stimulus in the U.S., China, and elsewhere,” wrote S&P Global Rating Analyst Andrew Chang.

    S&P Global Ratings anticipates IT spending to decline 3% year over year, compared their prior estimate of 2% to 3% growth. S&P Global Ratings expects some of the biggest hits to hardware, with smartphone revenue falling to negative 9% from up to 2% growth, and PCs to negative 9% from a previous range of negative 3% to a positive 4% growth.

    While enterprise technology budgets are being slashed, the need for business-technology isn’t going away. In fact, it’s accelerating as more knowledge workers shift to working from home, more remote collaboration and keeping legacy systems running and moving forward with digital transformation efforts.

    — George V. Hulme

  • Better Apps and Better Security When You Shift Left

    Better Apps and Better Security When You Shift Left

    Tens of thousands of people and hundreds of cybersecurity vendors descended on San Francisco at the end of April. While the RSA Conference was the primary draw, there are a number of peripheral events that go on throughout the week as well, such as the Cloud Security Alliance Summit, the CIO/CISO Interchange, BSides San Francisco and the Qualys Security Conference.

    I was able to attend some of the Qualys Security Conference and I had the opportunity to see Alex Mandernack, security solution architect for product management at Qualys, presenting on the need to shift left when it comes to cybersecurity.

    Mandernack outlined some of the issues organizations face today when it comes to security. Migrating to the cloud and embracing DevOps culture means more ephemeral, elastic environments and compressed development time frames. He pointed out that these trends make security more challenging, but also described the opportunity they present to change our approach to streamline and improve security.

    The Traditional Pipeline is Broken

    The traditional model of application development is much more linear. Each app team builds their own image—often in a silo or vacuum disconnected from other teams. Penetration testing is conducted on a sporadic or infrequent basis, and eventually the app is deployed. Vulnerability scans are run on the app in production, and issues or deficiencies are reported back to the developers to address or incorporate into the next build.

    The process is slow and cumbersome. It also has the potential to introduce redundancies that waste resources and make the organization less efficient. As companies embrace DevOps and move to the cloud, the traditional development pipeline simply doesn’t work—especially not for security.

    DevOps, and Cloud, and Containers — Oh My!

    The cloud and DevOps fundamentally change the development lifecycle. Development time frames are compressed, and the process is a self-feeding, iterative circle rather than a repeating linear approach. The traditional approach of identifying and resolving security issues after an application is deployed won’t work in a DevOps environment because by the time issues are identified and fixed, the app itself may have already moved on to the next version.

    Cybersecurity and the development pipeline have enough challenges with the cloud and DevOps, but there is also a newer technology trend that exacerbates the problem—containers. Containers are designed to get code quickly and to operate fast. They are also built for scalability—spawning and spinning down hundreds or thousands of containers constantly to keep pace with demand.

    There is a diverse array of tools and platforms associated with cloud, DevOps and containers. Organizations often employ a complex collection comprised of some combination of AWS, Azure, Docker, Kubernetes, OpenShift and others. The result can quickly become a black hole when it comes to security—which is why it’s important to push security left into the CI/CD pipeline.

    Shift Left to Help Security Teams Do Better

    In a DevOps culture, developers and security teams need to think about security sooner. It’s important to get the security tools into the process earlier. Thankfully, with the DevOps lifecycle and the tools commonly used within a DevOps environment, it can be done.

    For starters, companies should build a golden image. Developers shouldn’t have to patch and update the base operating system before they even start developing. The golden image takes a baseline operating system such as Ubuntu or CentOS, and completely patches and configures it so everyone has a standard, consistent image to develop on.

    With the golden image in place, the next step in shifting security left is to implement testing and scanning in the CI/CD pipeline. Put vulnerability information at the fingertips of developers as they’re developing and implement vulnerability gates in the pipeline to ensure that applications that don’t comply with policies and meet minimum requirements are not allowed to be deployed.

    New Role of the Security Team

    Part of shifting security left includes providing tools that make security self-service for the DevOps team. Automating actions with scripting, APIs and CI plugins ensures that security is simplified and streamlined to provide value for developers.

    In this shift left scenario, the security team has to redefine its role in the process. The security team is still vital, but rather than being the police or a roadblock in the development process, the role of security focuses on verifying and auditing the process. The security framework should have dashboards and live data that enable the security team to monitor activity and identify trends that may need further attention.

    Better Security, Faster

    There is often conflict between developers and security teams, but there doesn’t need to be. Mandernack stressed that developers don’t want to create insecure apps either.

    Shifting security to the left into the CI/CD pipeline streamlines the whole process. Ultimately, the result is higher quality, more secure applications that are developed faster.

    — Tony Bradley

  • IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    Big news from Big Blue yesterday: IBM CEO Ginni Rometty is stepping down after eight years at the helm. In her stead, IBM is doubling down on the cloud by appointing Arvind Krishna as CEO and member of the board. The real move to watch, though, is the appointment of Jim Whitehurst, Red Hat CEO, as president of IBM and a board member. It’s the first time that someone has held the title of president singularly, and it may portend where the real power will be at Big Blue (and Red).

    Krishna was previously head of the cloud and cognitive software division at IBM. He is an IBM veteran, having been with the company since 1990. His appointment sends a strong signal about how important the cloud is to IBM’s future. In some ways, it is similar to Satya Nadella’s appointment at Microsoft. But perhaps it’s not as strong a signal about the importance of the cloud than the $33 billion IBM spent acquiring Red Hat.

    It is that $33 billion investment and the importance of Red Hat to the new IBM that leads me to believe Krishna may, in fact, be a transitional CEO. The eventual appointment of Whitehurst as CEO and the rise of Red Hat leadership within IBM may in some ways be a reverse-merger type of thing, with Red Hat eventually running the show.

    IBM is a huge beast. A company of Red Hat’s size will find it difficult to change the culture and overcome the inertia at IBM. But frankly, IBM has been transitioning for almost all of Ginni’s time there. While the Enterprise Systems group (Z systems mainframe) is still the cash cow, bringing in a large percentage of revenue, IBM has increasingly tried to be a major cloud player.

    The SoftLayer acquisition didn’t quite give the company what it needed, as it was not a public cloud play. It left IBM unable to compete with Google, Microsoft Azure and AWS in true cloud services. After a few fits and starts, IBM decided that Red Hat, with its open source pedigree and cloud strength in both public and private cloud settings, could be the engine that could as it pertains to cloud.

    The street has not been kind to IBM over the last few years as a result of the botched cloud play, either. At a time when its tech competitors and the market in general have soared, IBM has actually fallen, as has its revenue.

    Mitchell Ashley, founder and managing analyst at Accelerated Strategies Group, agrees with this assessment. “We are seeing a sea change in big tech CEO strategy. Like Microsoft’s elevation of cloud exec Satya Nadella to CEO, IBM is rebuilding its executive ranks from the open source cloud software world with the appointment of Red Hat’s Jim Whitehurst as president and board member,” he said. “How soon the Krishna regime including old-line IBM executives gives way to Whitehurst and other Red Hat executives remains to be seen.”

    IBM CEO Change Elevates Open Source from Digital Anarchist on Vimeo.

    Ashley was not the only analyst to weigh in.

    “IBM bet the farm on cloud with the $34 billion Red Hat acquisition,” said Steve Duplessie, founder and senior analyst at Enterprise Strategy Group (ESG). “It was only a matter of time for the succession. Now the two top dogs running IBM are cloud purists. The old IBM died a while ago and they had to change—I like the move! Their stock lost 26% while the S&P rose over 150%. This lets them remake themselves before it’s too late.”

    Changes at the top don’t always portend success. There is a lot of hard work ahead at IBM as the company continues this journey. Competing with AWS, Google, Microsoft and other players in the cloud space is going to be challenging, given the head starts these players have already. But you really can’t count out IBM, ever.

    One other thing I wanted to mention: With IBM’s appointment of Krishna at IBM, there now are CEOs of Indian descent at Alphabet (Google), Microsoft and IBM. This is very positive for all persons of not only Indian heritage but for all people of color and nationalities. Kudos to these companies and these men for their success. Now, how about some women of color in these roles?

    — Alan Shimel

  • The Foundational Era of Open Source

    The Foundational Era of Open Source

    Contrary to popular belief, software is not eating the world. Open source software is eating the world. This was very apparent at the Linux Foundation’s KubeCon + CloudNativeCon event recently in San Diego. Driving this phenomenon is what I call the Foundational era of Open Source.

    This Foundational era of Open Source has replaced what I call the Big Brother era that came before it. The Big Brother era itself replaced what I call the Cathedral and Bazaar era of open source.

    The Cathedral and Bazaar Era

    I first became involved in open source software in the mid-90s. I might have dabbled and used open source software before that as I searched for free tools using WAIS and Gopher. But I really became aware when I founded TriStar Web, an early hosting company. Back then, web server software came in basically three flavors: 1. Netscape Web Server, from the people who brought us the Netscape browser (it was my choice); 2. Microsoft’s Internet Information Server (ISS), which was that era’s version of the Evil Empire; and 3. Apache (I don’t even think there was an Apache Foundation yet), the open source web server that was taking the web by storm. Besides being free, it was a lot more flexible and capable than the other two.

    During this time there was, of course, another open source software vying for dominance in the market. Something called Linux developed by a guy named Linus Torvalds was taking on all of the giants that had their own flavors of Unix, while Bill Gates’ Windows was fighting it out against IBM’s OS/2, which he also developed.

    Yes, those were heady days for open source software. I call those days the Cathedral and Bazaar days of open source. The Cathedral and Bazaar, of course, refers to the collected essays and then the book of the same name by Eric S Raymond. It, more than anything else, laid out for me the power of open source software and the tensions between the worlds of open source “free as in beer, free as in freedom” versus closed source software.

    Let’s be clear, the open source software world would not exist but for the lessons learned, battles fought and wins and losses of this era.

    Anarchy, Chaos or Freedom?

    In those days you had people such as Dr. Richard Stallman advocating for free, open software that you could use, distribute and modify as you wish. There were intellectual debates over the pros and cons of various open source licenses (Apache, GPL, etc). Most of all, it was very difficult to bring open source software into the enterprise. No support, no training, no SLAs … how was the enterprise to use open source?

    Nevertheless, open source prevailed—sometimes on sheer quality, other times on the love of developers who relished in the freedom of open source. It became a force in the tech world. Companies such as Red Hat, Suse and Canonical capitalized on Linux. Other companies tinkered and experimented with models to try and become commercially successful with other open source tools. By and large, it was a rough go, but some did succeed.

    In my own case in InfoSec, we had great open source tools including Snort, Nmap and Nessus. The folks at Tenable did stop developing an open source version of Nessus, but they still offered a free version of it. Yes, it was a great time in open source—or so I thought.

    The Big Brother Era of Open Source

    Sometime in the early 2000s, we passed into what I call the Big Brother era of open source. This was characterized by almost every open source project having a managing or controlling commercial entity dictating its direction and code. While this didn’t happen with Linux, it became the de facto standard.

    Companies were spun up by the founders of an open source project and while the project itself remained open, it was owned lock, stock and barrel by the commercial entity. The company would sell training and support and in some cases open core versions of the software with “freemium” modules available for a price. Eventually, SaaS-based, hosted versions of the open source software would be another business model companies used to monetize open source.

    Issues regarding who owned the code, who contributed to these projects and where the community fit in often caused conflicts. But by and large, the open source communities counted on the benevolence of the Big Brother to make sure the open source versions of the software remained viable.

    In retrospect, though, this era stifled contribution by other entities: Who would want to contribute code to an open source project for the benefit of the controlling entity? Many companies forked their project so they could control their own versions, resulting in the Balkanization of many of these projects, with the community being the big loser.

    The Foundational Era of Open Source

    Between 2012 and 2015, though, we passed into a new, modern era of open source software that I call the Foundational era of open source. Open source projects were given to community-owned, non-profit foundations to manage and nourish—organizations such as the Linux Foundation, the folks behind Cloud Native Computing Foundation and the Continuous Delivery Foundation; Cloud Foundry Foundation; The Apache Foundation; and the Eclipse Foundation (one of the early entrants, even if IBM did come to dominate it) took over the stewardship of many open source projects.

    This has ushered in a truly golden age of open source software that has seen open source become the dominant form of software in the world. The Foundational era of open source has flourished for several reasons. For one, now multiple commercial entities can contribute code without worrying that it is for the exclusive benefit of just one company. What’s more, these foundations have a mix of vendors, practitioners and large enterprise users that really do allow for the democratization of open source at levels not seen before. Also, there is a process of incubation to graduation that these projects are put through that help them evolve and grow.

    Not to be underestimated is the new generation of developers who have grown up with open source and only want to work in open software. They are putting their influence into practice. Instead of sneaking open source in the back door, they are knocking down the front door with it.

    There are other reasons, but the result is that open source today is now in use at well over 90% of enterprises and it is by far the dominant form of software. It is leading the way in the move to the cloud and in business transformation, and it is literally changing the world.

    Long live open source.

    — Alan Shimel

  • Oracle v. Google and Its Impact on APIs and Code

    Oracle v. Google and Its Impact on APIs and Code

    What, if any, impact will the Supreme Court’s rulings on Oracle v. Google have on the industry at large?

    TL/DR: It is unlikely to impact the vast majority of us, vendor and enterprise developer alike.

    Disclaimer: I am a technologist, not a lawyer. I have done some research, and talked to lawyers, but all that I say here is opinion—even my direct quotes of lawyers are their opinion. The Supreme Court can and has caught people off guard and taken cases in different directions than expected. Though I believe this path is the one it will follow, nothing is assured until the Court rules.

    Throughout this blog, references to The Case are actually using Harvard’s case document.

     

    Background

    On Nov. 15, the U.S. Supreme Court agreed to hear a dispute between Oracle and Google. The Oracle v. Google case has been going on for nearly a decade. And its roots go further back than that.

    The origins of the case go back to 2005, when Google and Sun Microsystems discussed the licensing of Java for Android. This will likely be important because it shows that Google knew it was someone else’s intellectual property (IP). More on this later.

    The crux of the case falls into three parts:

    1. Eight files that were decompiled and used. In one court case, these were found to never have made it into distribution and only used for testing (which limits liability).
    2. Two source files from Java used directly. These were found to be infringing, but damages were set to zero with consent of both legal teams.
    3. The part at issue: the copying of the entirety of Java’s interface from 37 modules. Most tech writers imply this as 37 APIs. It is not—it is hundreds of classes and thousands of methods. The 37 is the number of Java packages.

    The case has been through four court hearings/rulings so far. To sum up the relevant parts of these cases:

    1. The first case (split between a jury and district court, running at the same time) included patent violations. Those were defeated and Oracle has not appealed that defeat. On copyright infringement, the court found that Google did violate copyright on the 37 packages and the directly copied source code, but not on the eight decompiled files. The jury could not settle the issue of “fair use” of the 37 packages.
    2. The district court decided that the eight decompiled files and the copied source code for one function were violations, but remanded the rest back to the jury trial to settle the issue of fair use.
    3. In the end, the district court determined that APIs are not protected by copyright. Their decision involved two parts:
      1. That there is only one way to write a given API.
      2. The interface code and hierarchy can be replicated by third parties without violating copyright because it is an interface and not content.
    4. On appeal, the finding was reversed, and APIs were deemed copyrightable, sending the case back again.
    5. At this point, Google asked the U.S. Supreme Court to intervene. The court chose not to.
    6. Back at jury trial, the court found that while APIs may be copyrightable, Google’s use was fair use in the legal sense. This is the one topic the jury could not originally agree upon.
    7. Oracle appealed this decision, and the District Court ruled that it indeed was not fair use to copy the structure and exact interfaces.
      1. Where the jury and the district court appear to disagree is in the idea of APIs. Calling a publicly documented API is obviously fair use, and the jury latched onto that idea. The District Court appears to acknowledge the difference between calling an API and copying it.
    8. And after some tumultuous hearings and years in the court, the Supreme Court has agreed to weigh in on the issue.

    The real problem here is that copyright law is not a great fit for software. It never has been. If I rewrite your Java application in Python, using the same exact structure and naming, is that protected? All of the “words” have changed. It is akin to rewriting your Hindi book in English without a direct translation  … except that in software there is the added issue of it behaving exactly the same.

    But we can’t fix the misapplication of copyright law to software—only Congress can. So what to expect?

    A fair number of people, from the open source community and from businesses that see opportunity in a ruling that favors their world  view, are advocating that affording copyright protection to APIs is a horrible idea because it would hurt independent developers. This is not quite true. Independent developers are not generally copying Java. While this case does have bearing on coding practices and what developers can do, it does not have a huge impact on innovation, just on copying others’ work and how that is achieved—much like the “reverse engineering” court cases of the ’80s.

    There are good arguments on both sides of this case, but it seems to me that fair use will lose. They are public APIs in the sense that anyone can call them; indeed, some of these packages are so core to the system that you could argue every app must call them. But calling a function is not the same as re-creating it. In that sense, they are not in the public domain. Anyone can read a book, but that does not make it public domain.

    But no matter how this turns out, it is all good for the industry. This uncertainty has hung over the IT sector for nearly a decade. Just like when a new boss comes along and there is uncertainty in the department until everyone adjusts to the new demands/style of the boss, a solid ruling will allow settling to start. The industry can adapt once it knows what the rules are and we can move along.

    The real long-term answer is to have an equivalent to copyright and patent that is designed around the unique parts of computer code. Clearly, software is not the same beast as a book or magazine. The considerations are half-patent and half-copyright, and trying to bend those two to meet the needs of software has created some serious issues. Oracle quoted a 1995 case to showcase this problem—the company is quoting it to win the appeal, but it should be quoted as the reason the protections need to be designed for this medium that is not a publication and yet consists of words whose sequence matters: “Applying copyright law to computer programs is like assembling a jigsaw puzzle whose pieces do not quite fit.” (attributed by Oracle to the concurring opinion of J. Boudin in Lotus Dev. Corp. v. Borland Int’l, Inc., 1995).

    One interesting bit that the courts thus far have ignored, and I would love to see the Supreme Court take up, is this: If Google entered into licensing negotiations, the company knew it was Sun/Oracle’s IP. To then go and copy parts of it without licensing appears wrong on its face. It would be interesting to understand the process that ended in the copying and hear whether that bears upon the legal standing of the case. I can think of both malicious and innocent routes to get there; it would be interesting to hear testimony about motivations and thought processes.

    But even without delving into the licensing negotiations, this case stands to redefine copyright with regards to software. J. Michael Keyes, a partner at the international law firm Dorsey & Whitney, had this (and more) to say:

    “One of the issues that the court may decide is the scope of copyright protection for software. Google had early success below in convincing the trial judge that the snippets of copied code were not copyrightable. Google may urge to have the court take a look at this issue anew. Another huge implication is the scope of fair use. The jury found that Google’s use was “fair” and that it was not liable for infringement. The appellate court overturned that jury conclusion and found that Google’s use was not fair as a matter of law. The Supreme Court will likely wade into this thicket and provide guidance on the scope of fair use in the context of software code and what role an appellate court plays in reviewing jury decisions in that regard.”

    What we (all of us) do not want to do is confuse “good for the industry” with “legal standard.” It is not the court’s job to do what we think is best for the industry; it is the court’s job to determine applicable law and what that implies needs to happen. Presumably, the Supreme Court will do just that. And it may not please any of us. But if we think the current iteration of the law is flawed, that is something to take up with elected representatives, not ask a court to “fix” on the fly.

    For the vast majority of us, though, it impacts our development not at all. Using APIs or forking open source projects are all still perfectly acceptable, and no ruling by the Supreme Court is going to change that—because copying someone’s APIs is the issue here, not using them. And open source licenses allow for copying and improving projects. So carry on. Get the job done. And read about the Supreme Court’s final decision with a smile, because either way, the industry will adapt to the new normal and continue forward.

    — Don Macvittie