Throw Some Googles on It

AWS, IBM and % of Developers at the Big Companies
This week we look at the number of developers that company's employ. You may think that number is predictive of corporate success. We’re not trying to do that. Nor do we show a direct link between profits and open source adoption, data-driven decision making or DevOps practices. Despite efforts by many others, we’re skeptical of studies that show a direct, causal relationship between these factors and actual company revenue. There are just too many other factors to account for. Instead, The New Stack has analyzed some data and will let you draw your own conclusions.

Using LinkedIn, 12 of the largest tech companies’ workforces were profiled to determine how many developers they deploy. IBM’s 40,946 developers, software engineers and programmers dwarf the competitors, with Google coming closest with 25,070. However, people in these job role only account for 9 percent of IBM employees versus 32 percent at Google. Not all STEM workers are developers though. Looking at job roles, Amazon Web Services is the leader with 53 percent of its employees in engineering or information technology.

Last week’s post noted that – based on the number of developers using a corporate email address — IBM and AWS badly trailed Microsoft and Google in terms of employees contributing to a GitHub hosted projects. Others noted that this data also appeared to under-represent Red Hat and Pivotal’s place in the open source community. So, we decided to use the LinkedIn data to get a different perspective: The number of GitHub contributors identified accounts for 25 percent of all of Red Hat’s developers, as compared to seven percent at Microsoft. Lower on that list is Amazon.com at two percent, with Intel, IBM and Oracle even lower. For Intel, IBM and Oracle, we believe that many of their developers are working on proprietary projects or are hands-on helping their clients’ customized deployments. Note that we did not mention AWS because we can’t distinguish between their developers and those working for the larger company.

The LinkedIn data clearly delineates between people working for AWS and the rest of the company, showing that 11 percent of the company’s employees work for the cloud provider. This aligns closely to the 10 percent of total sales it accounted for in the latest quarterly report. Of course, AWS employees generate a much greater percentage of the Amazon’s profits, but that is another story. As stated above, AWS has the greatest percentage of engineers and IT workers. Interestingly, Amazon.com has the lowest. This makes sense because the latter is a retail and logistics company. Yet, just based on job title, the percentage of developers at AWS and Amazon are similar — 4.8 vs 4.3 percent. We believe this is because AWS job titles are more associated with their business-related function.

The data referenced above can be found in this spreadsheet.

Throw Some Googles on It

There's an acronym we quite like at TNS: GIFEE, short for "Google Infrastructure for Everyone Else." The idea behind GIFEE is, in short, that Google engineers have done some serious thinking about how to manage infrastructure at scale, ensuring that any increase in the number of servers that an organization run shouldn't be accompanied by a corresponding increase in admins to manage said servers. In theory, the lessons it has learned should help the enterprise and rapidly growing start-up as well.

Years before anyone else, for instance, Google was hip to the idea of using containers to manage services. This is how the open source Kubernetes project came about. It was based on Google's internal Borg software for orchestrating container operations. It was the only effective way to manage a vast sprawling service such as Gmail. More recently, the company has been pioneering site reliability engineering (SRE) to manage large-scale projects without corresponding large-scale headaches.

At the O'Reilly Security Conference this week in New York City, company engineers revealed its thinking about managing security at scale. Making all of its internal applications available over the internet, for remote and mobile employees, Google actually ditched the virtual private network (VPN) in favor of granular authentication at the device and user level. The engineers claimed it's much easier this way than the guarded castle approach of maintaining a VPN, which will probably be compromised anyway.

We're writing up a post on that talk now so keep an eye out for all the juicy deets in the next week or so. But in the meantime let us know, does GIFEE work for your organization? Or is it overkill? As always, your opinion keeps us informed — and honest!

How SigOpt Wants to Optimize Your Machine Learning Algorithms

Now that many companies are starting to use machine learning in their daily operations, the next question inevitably arises: How do we make ML work as smoothly (and cheaply) as possible. Now, a San Francisco-based startup SigOpt offers an Optimization-as-a-Service API that allows users to seamlessly tune the configuration parameters in artificial intelligence and machine learning models to save money and speed results.

How to Overcome Stuck EBS Volumes When Running Stateful Containers on AWS

While Amazon Web Services is a great place to run containers, you should avoid relying solely on AWS’ Elastic Block Storage (EBS) for persistent storage, argues Portworx CTO Gou Rao. In this contributed piece, he offers a few solutions to this issue, including, yes, the Portworx software suite. Worth a read.

IBM Cloud Private Introduces Enterprise Java to the Cloud Native World

IBM has introduced a new service, called the IBM Cloud Private, that will allow organizations to run cloud-native workloads in their own data centers, using the Kubernetes container orchestration engine, HashiCorp’s Terraform infrastructure management software, and eventually, the Istio service mesh. It’ll be perfect, the company maintains, for moving legacy enterprise Java apps into the cloud.

ISSUE 89: Throw Some Googles on It

“You have a huge problem on your hands… You bear this responsibility. You’ve created these platforms. And now they are being misused. And you have to be the ones to do something about it, or we will.”